Why does Intel Meteor Lake Ethernet drop packets?

It looks like 24.04 LTS is now available. I'll download that from this site:
https://ubuntu.com/download/desktop

and give it a try as well.

I just tried Ubuntu 24.04 LTS and I can no longer replicate this bug.

After testing this issue more thoroughly, I still see it with Ubuntu 24.04 LTS.

I also tried the latest mainline kernel (6.9.1-060901-generic) and still have this issue (from here: https://kernel.ubuntu.com/mainline/v6.9.1/).

In general, Ethernet is very unstable on the Dell Latitude 5450 and Dell Latitude 5550 with Ubuntu.

I have not yet tried Windows.

To diagnose and potentially resolve the packet drop issue you're experiencing on your Dell Latitude 5450 and 5550 laptops with Ubuntu 22.04 LTS, we'll need to gather more detailed information about your system and network configuration. Here’s a structured approach to troubleshooting and collecting the necessary details:

1. Verify Ethernet Driver and Network Configuration
Check the Ethernet Driver:

Open a terminal.
Run the following command to identify the network interface and driver:
bash
Copy code
sudo lshw -C network
Look for the driver field under the Ethernet interface section.
Check Network Configuration:

Run the following command to get the IP address, subnet mask, and other details:
bash
Copy code
ip addr show
Note down the Ethernet interface name (e.g., eth0 or enp3s0).
2. Test Network Connectivity
Ping Test:

Perform a continuous ping to a reliable external server to measure packet loss:
bash
Copy code
ping -c 100 google.com
Replace google.com with your preferred external server if needed.
Check dmesg for Errors:

Run the following command to check for kernel-related network errors:
bash
Copy code
dmesg | grep -i eth
This will show any relevant messages related to the Ethernet interface.
3. Update/Modify Driver and Firmware
Update Kernel and Drivers:

Ensure your system is fully updated:
bash
Copy code
sudo apt update && sudo apt upgrade
If the issue persists, consider installing the latest HWE (Hardware Enablement) kernel:
bash
Copy code
sudo apt install linux-generic-hwe-22.04
Reboot after installation.
Check for BIOS/UEFI and Firmware Updates:

Go to Dell's support website and check for any BIOS/UEFI updates for your Latitude models.
Follow the instructions to update if a newer version is available.
4. Additional Diagnostic Tools
ETHTOOL:

Install ethtool if not already installed:
bash
Copy code
sudo apt install ethtool
Run the following command to get detailed information about the Ethernet interface:
bash
Copy code
sudo ethtool <interface>
Replace <interface> with your Ethernet interface name.
MTR (My Traceroute):

Install mtr if not already installed:
bash
Copy code
sudo apt install mtr
Run mtr to analyze network paths and detect packet loss:
bash
Copy code
sudo mtr google.com
5. Collect and Share Information
Gather all the collected data from the above steps and share it for further assistance. This includes:

Output of sudo lshw -C network
Output of ip addr show
Results of the ping test (ping -c 100 google.com)
Relevant dmesg output (dmesg | grep -i eth)
ethtool output for the Ethernet interface
Results from mtr if applicable
6. Alternative Support Channels
If the issue remains unresolved after following these steps, consider reaching out to:

Ubuntu Forums: Ubuntu Forums
Ask Ubuntu: Ask Ubuntu
Dell Support: Especially if you suspect it might be hardware-related.
By providing detailed diagnostic information, you'll enable others to better understand and help troubleshoot your specific issue.

The driver is e1000e and the driver version is 6.9.1-060901-generic. The firmware is 1.1-4.

user@Latitude-5450:~$ sudo lshw -C network
  *-network
       description: Ethernet interface
       product: Intel Corporation
       vendor: Intel Corporation
       physical id: 1f.6
       bus info: pci@0000:00:1f.6
       logical name: enp0s31f6
       version: 20
       serial: <removed>
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=6.9.1-060901-generic duplex=full firmware=1.1-4 ip=100.1.1.1 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:140 memory:7c100000-7c11ffff

user@Latitude-5450:~$ ip addr show
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 4c:d7:17:d0:61:85 brd ff:ff:ff:ff:ff:ff
    inet 100.1.1.1/24 brd 100.1.1.255 scope global enp0s31f6
       valid_lft forever preferred_lft forever

The Ethernet NIC does not have Internet connectivity. It is connected to another computer directly (crossover cable) to access local internal software.
Currently the ping rate is 100% success when it's working and 100% failure when it goes down. It goes down randomly.
When it goes down, I can either wait 1-2 minutes or so for it to automatically come back up, or I can manually enable the NIC to bring it back up within Ubuntu.
Previously the packet loss rate was 6%.

I don't see any errors in dmesg output when the NIC is dropped.

After the NIC went down and then back up, I see only the following in dmesg when grepping for -i eth:
user@Latitude-5450:~$ sudo dmesg | grep -i eth
[ 0.715601] wmi_bus wmi_bus-PNP0C14:02: [Firmware Bug]: WQBC data block query control method not found
[ 0.871187] e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) 4c:d7:17:d0:61:85
[ 0.871190] e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
[ 0.871297] e1000e 0000:00:1f.6 eth0: MAC: 16, PHY: 12, PBA No: FFFFFF-0FF
[ 1.006096] e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0

Everything is up-to-date:
sudo apt update && sudo apt upgrade
results in:
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

How can I install the latest HWE (Hardware Enablement) kernel?

I tried the following but it failed:
user@Latitude-5450:~$ sudo apt install linux-generic-hwe-22.04
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package linux-generic-hwe-22.04
E: Couldn't find any package by glob 'linux-generic-hwe-22.04'

I then tried the following but it looks like it's already the latest:
user@Latitude-5450:~$ sudo apt install linux-generic-hwe-24.04
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
linux-generic-hwe-24.04 is already the newest version (6.8.0-31.31).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I've already applied the latest Dell UEFI Firmware:
user@Latitude-5450:~$ sudo dmidecode | grep -i "bios revision"
        BIOS Revision: 1.3
From the Dell site, it shows the latest is 1.3.0:
https://www.dell.com/support/home/en-ca/product-support/product/latitude-14-5450-laptop/drivers

ethtool output is as follows:
user@Latitude-5450:~$ sudo ethtool enp0s31f6
Settings for enp0s31f6:
        Supported ports: [ TP ]
        Supported link modes: 10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes: 10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes: 10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

Currently, MTR (My Traceroute) works fine while the NIC is up. Then when the NIC goes down it loses all packets (same as ping result) until the NIC goes back up again.

I've reached out to our Dell sales representatives. Dell support was not helpful because I'm not running Windows on the laptop (what they were shipped with).
We've been told we would have to buy it with Linux pre-installed in order to get support from Dell.
This laptop is available with Ubuntu Linux so I may need to pursue that option.

I've left MTR running and the Loss is currently at 61.0% and rising. So it seems like it is down more than it is up.

Is there a log in Ubuntu that has more details about why the NIC is being brought back down (and later back up)? I'm wondering if this is an issue with the network manager.

I see the following popup on Ubuntu when there's issues:
"Connection Failed. Activation of network connection failed."

I just tested a custom buildroot install with a 6.1.64 based kernel and I haven't seen any dropped packets yet (over the course of about 20 minutes). I'll see if I can downgrade Ubuntu to a 6.1.64 based kernel in case there was some regression in the e1000e driver since that kernel.

I started poking around and it looks like NetworkManager logs to /var/log/syslog.

The following is interesting as I just cleared the /var/log/syslog and then saw 6 lost ping requests and then networking came back up. I captured the syslog below.

Here's what happened
- cleared /var/log/syslog
- networking went down on its own
- lost 6 ping requests during this time
- network came back up on its own
- captured /var/log/syslog when this happened

The log is as follows:
--------------------------------------------------------------------------------------------
2024-05-22T08:33:34.840416-04:00 Latitude-5450 systemd[1]: Started anacron.service - Run anacron jobs.
2024-05-22T08:33:34.841381-04:00 Latitude-5450 anacron[3781]: Anacron 2.3 started on 2024-05-22
2024-05-22T08:33:34.841453-04:00 Latitude-5450 anacron[3781]: Normal exit (0 jobs run)
2024-05-22T08:33:34.841985-04:00 Latitude-5450 systemd[1]: anacron.service: Deactivated successfully.
2024-05-22T08:33:42.001783-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381222.0014] device (enp0s31f6): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
2024-05-22T08:33:42.002079-04:00 Latitude-5450 NetworkManager[896]: <warn> [1716381222.0019] device (enp0s31f6): Activation: failed for connection 'netplan-enp0s31f6'
2024-05-22T08:33:42.002340-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381222.0022] device (enp0s31f6): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
2024-05-22T08:33:42.019944-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381222.0198] dhcp4 (enp0s31f6): canceled DHCP transaction
2024-05-22T08:33:42.020006-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381222.0199] dhcp4 (enp0s31f6): activation: beginning transaction (timeout in 45 seconds)
2024-05-22T08:33:42.020024-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381222.0199] dhcp4 (enp0s31f6): state changed no lease
2024-05-22T08:33:42.020398-04:00 Latitude-5450 avahi-daemon[841]: Withdrawing address record for 100.1.1.1 on enp0s31f6.
2024-05-22T08:33:42.020423-04:00 Latitude-5450 avahi-daemon[841]: Leaving mDNS multicast group on interface enp0s31f6.IPv4 with address 100.1.1.1.
2024-05-22T08:33:42.020434-04:00 Latitude-5450 avahi-daemon[841]: Interface enp0s31f6.IPv4 no longer relevant for mDNS.

2024-05-22T08:34:08.999343-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381248.9989] policy: auto-activating connection 'netplan-enp0s31f6' (d4735e4b-9bfa-3052-b1c4-ef3302803c9a)
2024-05-22T08:34:08.999689-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381248.9994] device (enp0s31f6): Activation: starting connection 'netplan-enp0s31f6' (d4735e4b-9bfa-3052-b1c4-ef3302803c9a)
2024-05-22T08:34:08.999741-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381248.9994] device (enp0s31f6): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
2024-05-22T08:34:09.000450-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381249.0002] device (enp0s31f6): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
2024-05-22T08:34:09.001083-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381249.0009] device (enp0s31f6): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
2024-05-22T08:34:09.001423-04:00 Latitude-5450 NetworkManager[896]: <info> [1716381249.0011] dhcp4 (enp0s31f6): activation: beginning transaction (timeout in 45 seconds)
2024-05-22T08:34:09.133719-04:00 Latitude-5450 avahi-daemon[841]: Joining mDNS multicast group on interface enp0s31f6.IPv4 with address 100.1.1.1.
2024-05-22T08:34:09.133908-04:00 Latitude-5450 avahi-daemon[841]: New relevant interface enp0s31f6.IPv4 for mDNS.
2024-05-22T08:34:09.133973-04:00 Latitude-5450 avahi-daemon[841]: Registering new address record for 100.1.1.1 on enp0s31f6.IPv4.
--------------------------------------------------------------------------------------------

I might have solved this issue.

I believe the first issue with a 6% packet loss after reboot was fixed by upgrading from Ubuntu 22.04 to Ubuntu 24.04.

Then the second issue with long period of dropped Ethernet packets seems to be caused by Ubuntu randomly switching from static to dynamic IP (and trying to use DHCP to get a new IP). I found Settings -> Network -> Wired -> Details -> Connect automatically was checked. I just unchecked that and ran 10 minutes with no ping requests dropped.

I couldn't find any documentation explaining what that option does. Is it expected to behave like this? I would think that going to IPv4 field and checking Manual under IPv4 Method would force Ubuntu to use a static IP indefinitely. Why would Ubuntu randomly change it back to Automatic (DHCP)?

What's even more weird, is that now that "Connect automatically" is unchecked, the ping requests are now stable. It still shows the static IP I entered previously in the Details as 100.1.1.1. However, under the IPv4 tab it now shows DHCP instead of Manual.

However, if I reboot the laptop, the NIC doesn't come up with the 100.1.1.1 automatically now. I need to go into settings and toggle the option to bring it up.

I guess for starters, what is the proper method in Ubuntu 24.04 to assign a static IP to a NIC?

Whenever I set Manual in the IPv4 under Settings, click Apply, and then go back to check it, it's reverted back to Automatic (DHCP).

However, if I reboot the laptop, the NIC doesn't come up with the 100.1.1.1 automatically now. I need to go into settings and toggle the option to bring it up.

I guess for starters, what is the proper method in Ubuntu 24.04 to assign a static IP to a NIC?

Whenever I set Manual in the IPv4 under Settings, click Apply, and then go back to check it, it's reverted back to Automatic (DHCP).

However, if I reboot the laptop, the NIC doesn't come up with the 100.1.1.1 automatically now. I need to go into settings and toggle the option to bring it up.

I guess for starters, what is the proper method in Ubuntu 24.04 to assign a static IP to a NIC?

Whenever I set Manual in the IPv4 under Settings, click Apply, and then go back to check it, it's reverted back to Automatic (DHCP).

Does there need to be a Gateway value set in order to prevent Ubuntu from switching back to Automatic (DHCP)?

It seems like if I enter an IP address and Netmask but leave the Gateway field blank then the setting reverts to Automatic (DHCP). However, if I fill in some IP for the gateway (even one that doesn't exist) then it stays with Manual.

Is this expected behaviour?

I want to use the NIC without Internet access and to be connected directly to another PC with a crossover cable that does not act as a gateway.

For now, I'll try testing with "Connect automatically" and a bogus IP for the Gateway to see if that gives me stable Ethernet connectivity.

Unfortunately, the ~6% packet loss is still an issue for me. I just retested Ubuntu 24.04 LTS with the 6.9.1 kernel and it failed on the second iteration.

I also raised the following kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=218869

From the previous test, you can see that on the second reboot 4 of the 60 packets were dropped (icmp_seq=9, 23, 33, 44).
----------------------------------------------------------
./test_reboot_connectivity.sh
Test iteration 1
Waiting for host reboot
Host responded to ping after reboot
Success! No ping requests lost.

Test iteration 2
Waiting for host reboot
Host responded to ping after reboot
Ping failed
PING 100.1.1.1 (100.1.1.1) 56(84) bytes of data.
64 bytes from 100.1.1.1: icmp_seq=1 ttl=63 time=0.301 ms
64 bytes from 100.1.1.1: icmp_seq=2 ttl=63 time=1.31 ms
64 bytes from 100.1.1.1: icmp_seq=3 ttl=63 time=2.06 ms
64 bytes from 100.1.1.1: icmp_seq=4 ttl=63 time=1.76 ms
64 bytes from 100.1.1.1: icmp_seq=5 ttl=63 time=1.30 ms
64 bytes from 100.1.1.1: icmp_seq=6 ttl=63 time=1.89 ms
64 bytes from 100.1.1.1: icmp_seq=7 ttl=63 time=1.99 ms
64 bytes from 100.1.1.1: icmp_seq=8 ttl=63 time=1.50 ms
64 bytes from 100.1.1.1: icmp_seq=10 ttl=63 time=1.50 ms
64 bytes from 100.1.1.1: icmp_seq=11 ttl=63 time=2.21 ms
64 bytes from 100.1.1.1: icmp_seq=12 ttl=63 time=1.65 ms
64 bytes from 100.1.1.1: icmp_seq=13 ttl=63 time=1.75 ms
64 bytes from 100.1.1.1: icmp_seq=14 ttl=63 time=1.81 ms
64 bytes from 100.1.1.1: icmp_seq=15 ttl=63 time=1.61 ms
64 bytes from 100.1.1.1: icmp_seq=16 ttl=63 time=1.71 ms
64 bytes from 100.1.1.1: icmp_seq=17 ttl=63 time=1.84 ms
64 bytes from 100.1.1.1: icmp_seq=18 ttl=63 time=1.31 ms
64 bytes from 100.1.1.1: icmp_seq=19 ttl=63 time=1.53 ms
64 bytes from 100.1.1.1: icmp_seq=20 ttl=63 time=1.91 ms
64 bytes from 100.1.1.1: icmp_seq=21 ttl=63 time=0.966 ms
64 bytes from 100.1.1.1: icmp_seq=22 ttl=63 time=1.59 ms
64 bytes from 100.1.1.1: icmp_seq=24 ttl=63 time=1.72 ms
64 bytes from 100.1.1.1: icmp_seq=25 ttl=63 time=1.87 ms
64 bytes from 100.1.1.1: icmp_seq=26 ttl=63 time=1.55 ms
64 bytes from 100.1.1.1: icmp_seq=27 ttl=63 time=1.51 ms
64 bytes from 100.1.1.1: icmp_seq=28 ttl=63 time=0.830 ms
64 bytes from 100.1.1.1: icmp_seq=29 ttl=63 time=1.36 ms
64 bytes from 100.1.1.1: icmp_seq=30 ttl=63 time=1.83 ms
64 bytes from 100.1.1.1: icmp_seq=31 ttl=63 time=1.98 ms
64 bytes from 100.1.1.1: icmp_seq=32 ttl=63 time=1.73 ms
64 bytes from 100.1.1.1: icmp_seq=34 ttl=63 time=1.27 ms
64 bytes from 100.1.1.1: icmp_seq=35 ttl=63 time=1.83 ms
64 bytes from 100.1.1.1: icmp_seq=36 ttl=63 time=1.42 ms
64 bytes from 100.1.1.1: icmp_seq=37 ttl=63 time=1.66 ms
64 bytes from 100.1.1.1: icmp_seq=38 ttl=63 time=1.51 ms
64 bytes from 100.1.1.1: icmp_seq=39 ttl=63 time=1.73 ms
64 bytes from 100.1.1.1: icmp_seq=40 ttl=63 time=1.56 ms
64 bytes from 100.1.1.1: icmp_seq=41 ttl=63 time=1.39 ms
64 bytes from 100.1.1.1: icmp_seq=42 ttl=63 time=1.65 ms
64 bytes from 100.1.1.1: icmp_seq=43 ttl=63 time=1.43 ms
64 bytes from 100.1.1.1: icmp_seq=45 ttl=63 time=1.40 ms
64 bytes from 100.1.1.1: icmp_seq=46 ttl=63 time=1.15 ms
64 bytes from 100.1.1.1: icmp_seq=47 ttl=63 time=1.19 ms
64 bytes from 100.1.1.1: icmp_seq=48 ttl=63 time=1.93 ms
64 bytes from 100.1.1.1: icmp_seq=49 ttl=63 time=1.87 ms
64 bytes from 100.1.1.1: icmp_seq=50 ttl=63 time=1.53 ms
64 bytes from 100.1.1.1: icmp_seq=51 ttl=63 time=0.798 ms
64 bytes from 100.1.1.1: icmp_seq=52 ttl=63 time=1.59 ms
64 bytes from 100.1.1.1: icmp_seq=53 ttl=63 time=1.58 ms
64 bytes from 100.1.1.1: icmp_seq=54 ttl=63 time=1.26 ms
64 bytes from 100.1.1.1: icmp_seq=55 ttl=63 time=1.80 ms
64 bytes from 100.1.1.1: icmp_seq=56 ttl=63 time=1.43 ms
64 bytes from 100.1.1.1: icmp_seq=57 ttl=63 time=1.43 ms
64 bytes from 100.1.1.1: icmp_seq=58 ttl=63 time=1.49 ms
64 bytes from 100.1.1.1: icmp_seq=59 ttl=63 time=1.88 ms
64 bytes from 100.1.1.1: icmp_seq=60 ttl=63 time=1.71 ms

--- 100.1.1.1 ping statistics ---
60 packets transmitted, 56 received, 6.66667% packet loss, time 59347ms
rtt min/avg/max/mdev = 0.301/1.559/2.205/0.332 ms
----------------------------------------------------------

May want to reboot the router as well. May help

There is no router involved. The Latitude 5450 is connected directly to my Windows computer with a crossover cable.

Is the cable OK? Have you tried a different cable? Do you have the latest driver in the windows OS?

actionparsnip, your responses are not helpful. Did you read what I wrote previously?

The cable is fine. I get the same problem even when I use Linux on both PCs.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

I performed a Dell OS Restore on this laptop to revert to the original Operating System (Windows 11). I applied all Dell, Windows, and BIOS updates to the laptop. The laptop still drops packets.

Since then, I got a Dell Latitude 5450 with Ubuntu Linux preinstalled on it. This laptop does not have the random dropped packets issue. I updated the BIOS on this laptop and it still doesn't drop packets.

For now, I can only assume that this is a hardware issue. I'll raise a case with Dell and look into getting this specific laptop fixed.