[SOLVED] Unstable LAN wired connection

[Segfault]

BTW, PCI ID is much better identifier when in comes to hardware identification.

MAC address and PCI ID do not have the same purpose at all.
PCI ID is more like a part number.
MAC address is more like a serial number.

I never said they have same purpose. You said it would be nice to have first 3 bytes to see the manufacturer.

I'm going to read up on IPv6 now. Even if you are right I still see no privacy issue.

[andoru]

I must admit I thought OP removed it for privacy reasons but I agree it could be an issue.

That is correct, I redacted the MAC address for privacy concerns

It might be worth getting the latest firmware from the Intel site to see if that works better...

I did that, compiled the driver, removed the one that came with the distro and made sure it was removed from cache too (with update-intramfs -u), made sure the latest version is used with modinfo (it should be 3.4.0.2), and rebooted just in case the old drivers weren't properly flushed. Unfortunately, the connection is just as unstable as before.

Is it the output "as is" or did you hide the MAC address ? Please don't, or at least leave the first 3 bytes (manufacturer's OUI) untouched.

No, as I mentioned above, the MAC address was redacted by me.
Here's the first three bytes of the address: 3c:d9:2b:--:--:--

By the way, has anyone suggested to check related messages in the kernel logs ?

Let me know what you want me to look for, and what commands to use.

BTW, PCI ID is much better identifier when in comes to hardware identification. By PCI ID you can grep the kernel sources or search the kernel driver database at cateee.net.

Here you go:

Code: Select all

# lspci -vvv -n -s 00:19.0
00:19.0 0200: 8086:1502 (rev 04)
	Subsystem: 103c:1494
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 30
	Region 0: Memory at fe400000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at fe428000 (32-bit, non-prefetchable) [size=4K]
	Region 2: I/O ports at f080 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee002f8  Data: 0000
	Capabilities: [e0] PCI Advanced Features
		AFCap: TP+ FLR-
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: e1000e
	Kernel modules: e1000e

[Segfault]

It always pays off to address the problem and use common sense.
Which is not the case here.
We know now the proper driver is loaded, thus all the talk about identifying the hardware and finding correct driver is empty talk.
Then the output of a command was intentionally mangled leading us in wrong direction. There is no privacy issues publishing your MAC address. And even if there was stripping the info should have been mentioned.
Useful info we know:
The cable is proven good.
The connector was inspected, no fault found.
Potentially useful info not seen:
Output of ethtool -S.
Whether the latest firmware has been flashed in or not.

[shep]

I'll mention that your problem could be in router rather than your client.

I had a problem with dropped Static IP/DHCP connections that was actually caused by the router. The connection "leases" are renewed periodically and may fail during renewal. My router was flashed with OpenWRT/LEDE firmware but my understanding is that it was an Atheros/SoC IPV6 issue with the router hardware. My ISP still uses IPV4 and my LAN is IPV4, so I disabled IPV6 in the router and the problem went away.

[andoru]

It always pays off to address the problem and use common sense.
Which is not the case here.

And by that you mean?

And even if there was stripping the info should have been mentioned.

Alright, my bad.

Potentially useful info not seen:
Output of ethtool -S.
Whether the latest firmware has been flashed in or not.

Well, I ran that command, but that only shows the session statistics for the NIC, here you go:

Code: Select all

# ethtool -S eno1
NIC statistics:
     rx_packets: 975
     tx_packets: 1913
     rx_bytes: 198426
     tx_bytes: 799058
     rx_broadcast: 99
     tx_broadcast: 19
     rx_multicast: 42
     tx_multicast: 204
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 42
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_csum_offload_good: 636
     rx_csum_offload_errors: 0
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 1
     rx_smbus: 168
     dropped_smbus: 0
     rx_dma_failed: 0
     tx_dma_failed: 0
     rx_hwtstamp_cleared: 0
     uncorr_ecc_errors: 0
     corr_ecc_errors: 0
     tx_hwtstamp_timeouts: 0
     tx_hwtstamp_skipped: 0

It's weird how it doesn't mention any dropped packets or errors/failures, as I went through a lot of dropped packets and connection timeouts during the session.

I'll assume you meant ethtool -i, since that displays firmware info for the interface:

Code: Select all

# ethtool -i eno1
driver: e1000e
version: 3.4.0.2-NAPI
firmware-version: 0.13-4
expansion-rom-version: 
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

The connection "leases" are renewed periodically and may fail during renewal.

You mean DHCP binding? I do have all the PCs in the network assigned a static LAN IP bound to their MAC addresses in the router. Not sure if this is what you mean.

My ISP still uses IPV4 and my LAN is IPV4, so I disabled IPV6 in the router and the problem went away.

My ISP does use IPv6, and it works on the other PCs on the LAN, so I'm not sure. I also can't seem to find a way of disabling IPv6 in the router settings... :/

[andoru]

Three more things I've tried:

Restored the BIOS settings to factory defaults.
Disabled IPv6 using this article: https://techrepublic.com/article/how-to ... -on-linux/ (which actually didn't do anything)
Disabled IPv6 from within Network Manager (Edit Connections -> (selected the troublesome connection) -> IPv6 Settings -> Selected "Ignore" from the first drop-down menu

All three of those didn't fix the issue...

[shep]

Some routers reserve DHCP addresses for clients w/ static IP's and will renew the clients "Static" connection.

When you test the dropped connection by pinging, it is helpful to ping both http://www.google.com and one of Googles DNS servers:
IPV4 8.8.8.8
IPV6 2001:4860:4860::8888
https://developers.google.com/speed/pub ... docs/using

If pinging http://www.google.com fails and 8.8.8.8 works then you have a problem with DNS resolution. Others have reported DNS isssues with IPV6
https://community.spiceworks.com/topic/ ... -with-ipv6

This was my problem with an LEDE flashed router
https://forum.lede-project.org/t/lan-st ... en/2648/20

[andoru]

It's not that the pinging doesn't work at all, it's that there are a lot of dropped packets (30%-70%), even when pinging to the router, and on some domains/IPs, it takes over 200ms to send a packet.
Before disabling IPv6 in Network-Manager, I would occasionally get "Network is unreachable" errors while pinging, and when looking at the connection info in NM, the IPv4 addresses wouldn't show up.

DNS resolution, AFAIK, works fine, as I have pinged domain names (debian.org) and it has connected (I don't think you can ping something unless the client knows the IP address, whether or not it has to get it through DNS lookup, or you provide the IP)

[4D696B65]

I'll mention that your problem could be in router rather than your client.

Agreed, I have an isp supplied router/modem that needs to be rebooted once or twice a week or I get 40% packet loss.

[andoru]

I've previously tried rebooting the router, and that didn't solve anything either... ugh.
I'd hate to send back this machine, only for them to return it back to me, saying there's nothing wrong with the NIC and asking me to pay for shipping...

[p.H]

I never said (MAC and PCI ID) have same purpose. You said it would be nice to have first 3 bytes to see the manufacturer.

No, I did not say that. I do not care about the manufacturer. Most often the OUI identifies the system manufacturer (HP), not the ethernet controller manufacturer (Intel). Big deal.

FWIW, I just wanted to check that the special bits in the MAC address first byte (unicast/multicast and global/local) were correctly set to 0. Sometimes the MAC address stored in the system NVAM is invalid, or the driver incorrectly reads it, resulting in an invalid MAC address being used, which can cause all kinds of trouble.

Here's the first three bytes of the address: 3c:d9:2b

So the first two bits are 0. Good.

I'm going to read up on IPv6 now.

Check Stateless Address Autoconfiguration (SLAAC), EUI-64 and IPv6 Privacy Extensions.

Let me know what you want me to look for, and what commands to use.

Use dmesg to print the kernel log buffer.
Look for messages containing the driver name (e1000e), the interface name (eno1), or the PCI bus ID (00:19.0).

It's weird how it doesn't mention any dropped packets or errors/failures, as I went through a lot of dropped packets and connection timeouts during the session.

How then did you see there were dropped packets ? With ifconfig or ip -s link ?

DNS resolution, AFAIK, works fine, as I have pinged domain names

You ping an IP address, not a domain name. The destination of an IP packet is an IP address, not a domain name.

A few thoughts.
- There can be variants of a same ethernet controller, and the driver may not work equally with all variants. The situation of Realtek RTL8168 and the kernel driver r8169 comes into mind. However Intel ethernet controllers and drivers have a better status.
- Did you try to disable offload optimizations with ethtool ?
- Did you check the power supply voltages ? An insufficient or flaky voltage could cause erratic behaviour. I think about the +5V stand-by voltage (5VSB) which supplies the ethernet interface for wake-on-LAN. This output is always on even when the system is shut down, so it can wear out faster.
- There can be incompatibilities due to border cases between two ethernet devices. I once used a computer whose ethernet port did not work on one specific wall plug, while it worked on other plugs and other computers worked on this plug. Did you test the computer on another switch port, another switch, another network... ?

[andoru]

How then did you see there were dropped packets ? With ifconfig or ip -s link ?

While pinging the router, and a few domains.

You ping an IP address, not a domain name. The destination of an IP packet is an IP address, not a domain name.

I know that. What I meant to say was that in order to get the (server) IP address of a domain, the ping tool has to do a DNS look up.

A few thoughts.
- There can be variants of a same ethernet controller, and the driver may not work equally with all variants. The situation of Realtek RTL8168 and the kernel driver r8169 comes into mind. However Intel ethernet controllers and drivers have a better status.
- Did you try to disable offload optimizations with ethtool ?
- Did you check the power supply voltages ? An insufficient or flaky voltage could cause erratic behaviour. I think about the +5V stand-by voltage (5VSB) which supplies the ethernet interface for wake-on-LAN. This output is always on even when the system is shut down, so it can wear out faster.
- There can be incompatibilities due to border cases between two ethernet devices. I once used a computer whose ethernet port did not work on one specific wall plug, while it worked on other plugs and other computers worked on this plug. Did you test the computer on another switch port, another switch, another network... ?

The last one has finally elucidated why the connection was unstable: it was the cable. I took the machine to the other room where the router is, and used a shorter cable to connect, and it worked flawlessly. It seems that for whatever reason, this NIC doesn't want to play nice with the cable I was using...
I've also read somewhere that somebody had a similar issue with a similar Intel NIC. The user in question said they bought a CAT6 cable, so I guess I'll be doing that now.
Thank you everyone for the help!

[andoru]

Just to give an update, I replaced the previous Cat 5e cable with a Cat 6a S/FTP cable, and it now works a treat!
I thought I'd write this update in case anyone else faces the same problem as I did.