I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
The trouble is that the ethernet port will not come out of the "no- carrier" state no matter how much I mess with the various commands that are supposed to effect it.
The simple fix is to physically unplug and replug the cable. When it is not working (each reboot) there are not lights on. The physical "bounce" lights up the LEDs and it comes right up.
So, I am asking for something to add to rc.local that does the same thing.
I use a wifi adapter for my main/Internet connection. This port is just used for a wired link to my Raspberry Pi.
The command that seems like it *should* work: sudo mii-tool --reset enp5s0
But that does not fix it.
Info:
The below is taken while it is working...
sudo lspci -v 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02) Subsystem: ASUSTeK Computer Inc. M3A78 Series Motherboard Flags: bus master, fast devsel, latency 0, IRQ 18 I/O ports at e800 [size=256] Memory at faeff000 (64-bit, prefetchable) [size=4K] Memory at faee0000 (64-bit, prefetchable) [size=64K] Expansion ROM at fbef0000 [disabled] [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/2 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable+ Count=2 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00- 00 Kernel driver in use: r8169 Kernel modules: r8169
nmcli enp5s0: connected to Ether link to Pi "Realtek RTL8111/8168/8411" ethernet (r8169), 00:26:18:3A:2A:1B, hw, mtu 1500 inet4 192.168.11.4/24 route4 192.168.11.0/24 inet6 fe80::226:18ff:fe3a:2a1b/64 route6 fe80::/64
This does kill and then fix it when working, thus proving that this module is being used: sudo rmmod r8169 sudo modprobe r8169
ip link 4: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 00:26:18:3a:2a:1b brd ff:ff:ff:ff:ff:ff
On 27Feb2021 09:50, Doug H. fedoraproject.org@wombatz.com wrote:
I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
[...]
The simple fix is to physically unplug and replug the cable. When it is not working (each reboot) there are not lights on. The physical "bounce" lights up the LEDs and it comes right up.
So, I am asking for something to add to rc.local that does the same thing.
Have you tried something as simple as:
ifconfig enp5s0 down sleep 2 ifconfig enp5s0 up
?
Cheers, Cameron Simpson cs@cskk.id.au
On Sat, Feb 27, 2021, at 1:36 PM, Cameron Simpson wrote:
On 27Feb2021 09:50, Doug H. fedoraproject.org@wombatz.com wrote:
I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
[...]
The simple fix is to physically unplug and replug the cable. When it is not working (each reboot) there are not lights on. The physical "bounce" lights up the LEDs and it comes right up.
So, I am asking for something to add to rc.local that does the same thing.
Have you tried something as simple as:
ifconfig enp5s0 down sleep 2 ifconfig enp5s0 up
Yup, I should have noted the various stuff I have tried. A couple of times now I have rebooted to create the issue and then pounded on the interface with no luck. I then just unclip/pull/push the cord and it comes up like magic.
After posting this I installed an old PCI ether card to get around the issue. The only trouble there is that the card does not seem to support "Wake on LAN" which is annoying but I think I can live with that.
Another note that I should have included is that this *is* a very old box. It will be 12 years old sometime this year (October I think). And this is the onboard LAN, so maybe it *is* something physical. It just seems odd that it works without issue once it is "bounced" to the working state.
On 2/27/21 9:50 AM, Doug H. wrote:
I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
Given that an older kernel doesn't fix it, that suggests it might not be software. How does it get in this state? Is it random? Does it stop working after a reboot or does it keep working after a reboot if it was working before? What about a power cycle?
On Sat, Feb 27, 2021, at 2:12 PM, Samuel Sieb wrote:
On 2/27/21 9:50 AM, Doug H. wrote:
I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
Given that an older kernel doesn't fix it, that suggests it might not be software. How does it get in this state? Is it random? Does it stop working after a reboot or does it keep working after a reboot if it was working before? What about a power cycle?
It does not seem random and it does not stop working while the OS is running except that it does not work after boot/reboot until the first unclip/pull/push. Oh, and it does stay up/working on resume from suspend (should have noted that one, seems important).
I did verify this morning that a cold boot does cause the problem. A reboot (warm) will also cause it. Note that the NIC lights do come on when the computer is turned on but then the lights go out at some point after the kernel is selected by grub. So it does seem that linux is doing it...
Hey, I should cold boot to a Ventoy boot stick to see what happens.
On Sat, 27 Feb 2021 at 17:59, Doug H. fedoraproject.org@wombatz.com wrote:
On Sat, Feb 27, 2021, at 1:36 PM, Cameron Simpson wrote:
On 27Feb2021 09:50, Doug H. fedoraproject.org@wombatz.com wrote:
I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
[...]
The simple fix is to physically unplug and replug the cable. When it is not working (each reboot) there are not lights on. The physical "bounce" lights up the LEDs and it comes right up.
So, I am asking for something to add to rc.local that does the same thing.
Have you tried something as simple as:
ifconfig enp5s0 down sleep 2 ifconfig enp5s0 upYup, I should have noted the various stuff I have tried. A couple of times now I have rebooted to create the issue and then pounded on the interface with no luck. I then just unclip/pull/push the cord and it comes up like magic.
Have you inspected the jack (uses a magnifier in good light) and tried a different cable? Once corrosion starts connections can go bad but will start to work after a replug cycle. You can buy contact enhancer that can often help in such cases.
After posting this I installed an old PCI ether card to get around the issue. The only trouble there is that the card does not seem to support "Wake on LAN" which is annoying but I think I can live with that.
Another note that I should have included is that this *is* a very old box. It will be 12 years old sometime this year (October I think). And this is the onboard LAN, so maybe it *is* something physical. It just seems odd that it works without issue once it is "bounced" to the working state.
At my work we once had a PC whose networking seemed fine until we needed
PCNFS, which refused to work. The vendor's diagnostics didn't indicate any problem, but when I pulled the card there were obvious burned components. Your time might be better spent getting a modern replacement, but I realize there are use cases where a modern replacement can be difficult.
On 2/27/21 2:21 PM, Doug H. wrote:
On Sat, Feb 27, 2021, at 2:12 PM, Samuel Sieb wrote:
On 2/27/21 9:50 AM, Doug H. wrote:
I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
Given that an older kernel doesn't fix it, that suggests it might not be software. How does it get in this state? Is it random? Does it stop working after a reboot or does it keep working after a reboot if it was working before? What about a power cycle?
It does not seem random and it does not stop working while the OS is running except that it does not work after boot/reboot until the first unclip/pull/push. Oh, and it does stay up/working on resume from suspend (should have noted that one, seems important).
I did verify this morning that a cold boot does cause the problem. A reboot (warm) will also cause it. Note that the NIC lights do come on when the computer is turned on but then the lights go out at some point after the kernel is selected by grub. So it does seem that linux is doing it...
Run "sudo journalctl -b" to see if there are any relevant logs. Also, "sudo journalctl -fa" before replugging to see what happens.
On Sat, Feb 27, 2021, at 2:31 PM, Samuel Sieb wrote:
On 2/27/21 2:21 PM, Doug H. wrote:
On Sat, Feb 27, 2021, at 2:12 PM, Samuel Sieb wrote:
On 2/27/21 9:50 AM, Doug H. wrote:
I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
Given that an older kernel doesn't fix it, that suggests it might not be software. How does it get in this state? Is it random? Does it stop working after a reboot or does it keep working after a reboot if it was working before? What about a power cycle?
It does not seem random and it does not stop working while the OS is running except that it does not work after boot/reboot until the first unclip/pull/push. Oh, and it does stay up/working on resume from suspend (should have noted that one, seems important).
I did verify this morning that a cold boot does cause the problem. A reboot (warm) will also cause it. Note that the NIC lights do come on when the computer is turned on but then the lights go out at some point after the kernel is selected by grub. So it does seem that linux is doing it...
Run "sudo journalctl -b" to see if there are any relevant logs. Also, "sudo journalctl -fa" before replugging to see what happens.
In reply to the question about wire corrosion: I have pulled/pushed the cable a *lot* in working with this and it works very well when it is working. The same cable works great with the alternate NIC. And I did boot to "sysrescue" and found the NIC with good carrier.
On to answering the question from Samuel: I am not seeing much help in the "while bad" journal:
# grep enp5s0 journalctl-b.while_not_working.txt Feb 27 14:52:58 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: renamed from eth0 Feb 27 14:53:07 wombat.wombatz.com NetworkManager[1316]: <info> [1614466387.7201] manager: (enp5s0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2) Feb 27 14:53:07 wombat.wombatz.com NetworkManager[1316]: <info> [1614466387.7216] device (enp5s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') Feb 27 14:53:07 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: Link is Down
Here is what happened when I did the pull/push of the cable (I marked the spot where the pull and push happened...
# journalctl -fa -- Logs begin at Thu 2020-10-01 08:01:38 PDT. -- Feb 27 14:53:55 wombat.wombatz.com systemd[1]: dnfdaemon.service: Consumed 4.964s CPU time. Feb 27 14:53:58 wombat.wombatz.com chronyd[1331]: Selected source 212.26.18.43 (2.fedora.pool.ntp.org) Feb 27 14:53:58 wombat.wombatz.com chronyd[1331]: System clock TAI offset set to 37 seconds Feb 27 14:53:59 wombat.wombatz.com chronyd[1331]: Selected source 217.198.219.102 (2.fedora.pool.ntp.org) Feb 27 14:54:05 wombat.wombatz.com systemd[1]: NetworkManager-dispatcher.service: Succeeded. Feb 27 14:54:05 wombat.wombatz.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 27 14:54:10 wombat.wombatz.com systemd[1]: pcscd.service: Succeeded. Feb 27 14:54:10 wombat.wombatz.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=pcscd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 27 14:55:03 wombat.wombatz.com chronyd[1331]: Source 84.16.73.33 replaced with 2607:5300:201:3100::345c (2.fedora.pool.ntp.org) Feb 27 14:55:03 wombat.wombatz.com chronyd[1331]: Selected source 184.105.182.7 (2.fedora.pool.ntp.org) Feb 27 14:56:12 wombat.wombatz.com systemd[1636]: Starting Mark boot as successful... Feb 27 14:56:12 wombat.wombatz.com systemd[1636]: grub-boot-success.service: Succeeded. Feb 27 14:56:12 wombat.wombatz.com systemd[1636]: Finished Mark boot as successful.
Here is the wire pull/push:
Feb 27 14:56:28 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: Link is Up - 100Mbps/Full - flow control off Feb 27 14:56:28 wombat.wombatz.com kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5430] device (enp5s0): carrier: link connected Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5436] device (enp5s0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5451] policy: auto-activating connection 'Ether link to Pi' (837b199c-531d-3727-a66f-12a8096b570d) Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5460] device (enp5s0): Activation: starting connection 'Ether link to Pi' (837b199c-531d-3727-a66f-12a8096b570d) Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5463] device (enp5s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5482] device (enp5s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5493] device (enp5s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com avahi-daemon[1321]: Joining mDNS multicast group on interface enp5s0.IPv4 with address 192.168.11.4. Feb 27 14:56:28 wombat.wombatz.com avahi-daemon[1321]: New relevant interface enp5s0.IPv4 for mDNS. Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5519] device (enp5s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com avahi-daemon[1321]: Registering new address record for 192.168.11.4 on enp5s0.IPv4. Feb 27 14:56:28 wombat.wombatz.com systemd[1]: Starting Network Manager Script Dispatcher Service... Feb 27 14:56:28 wombat.wombatz.com systemd[1]: Started Network Manager Script Dispatcher Service. Feb 27 14:56:28 wombat.wombatz.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5799] device (enp5s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5803] device (enp5s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5823] device (enp5s0): Activation: successful, device activated. Feb 27 14:56:28 wombat.wombatz.com systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive. Feb 27 14:56:28 wombat.wombatz.com systemd[1]: squid.service: Unit cannot be reloaded because it is inactive. Feb 27 14:56:30 wombat.wombatz.com avahi-daemon[1321]: Joining mDNS multicast group on interface enp5s0.IPv6 with address fe80::226:18ff:fe3a:2a1b. Feb 27 14:56:30 wombat.wombatz.com avahi-daemon[1321]: New relevant interface enp5s0.IPv6 for mDNS. Feb 27 14:56:30 wombat.wombatz.com avahi-daemon[1321]: Registering new address record for fe80::226:18ff:fe3a:2a1b on enp5s0.*. Feb 27 14:56:39 wombat.wombatz.com systemd[1]: NetworkManager-dispatcher.service: Succeeded. Feb 27 14:56:39 wombat.wombatz.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
You might try ethtool commands it will have an option to "test" and reset options. these options may or may not be the exact same code as the older mii-tool. It is also possible that not all of the possible options in mii-tool and/or ethtool are actually implemented in the driver, so one may work and another may not.
I have had luck getting the test to reset the nic on enterprise grade nic's, not sure if they work on the cheaper ones.
On Sat, Feb 27, 2021 at 5:09 PM Doug H. fedoraproject.org@wombatz.com wrote:
On Sat, Feb 27, 2021, at 2:31 PM, Samuel Sieb wrote:
On 2/27/21 2:21 PM, Doug H. wrote:
On Sat, Feb 27, 2021, at 2:12 PM, Samuel Sieb wrote:
On 2/27/21 9:50 AM, Doug H. wrote:
I am having an odd problem with my ethernet port. I assume this came with a dnf update but that was some weeks ago so I can't help figure out what update might have done it. When first discovered I think I found that booting from an older kernel did not fix it. I assume that the physical interface is not the problem since a physical "bounce" always fixes it and it shows no other problems. To explain that...
Given that an older kernel doesn't fix it, that suggests it might not be software. How does it get in this state? Is it random? Does it stop working after a reboot or does it keep working after a reboot if it was working before? What about a power cycle?
It does not seem random and it does not stop working while the OS is running except that it does not work after boot/reboot until the first unclip/pull/push. Oh, and it does stay up/working on resume from suspend (should have noted that one, seems important).
I did verify this morning that a cold boot does cause the problem. A reboot (warm) will also cause it. Note that the NIC lights do come on when the computer is turned on but then the lights go out at some point after the kernel is selected by grub. So it does seem that linux is doing it...
Run "sudo journalctl -b" to see if there are any relevant logs. Also, "sudo journalctl -fa" before replugging to see what happens.
In reply to the question about wire corrosion: I have pulled/pushed the cable a *lot* in working with this and it works very well when it is working. The same cable works great with the alternate NIC. And I did boot to "sysrescue" and found the NIC with good carrier.
On to answering the question from Samuel: I am not seeing much help in the "while bad" journal:
# grep enp5s0 journalctl-b.while_not_working.txt Feb 27 14:52:58 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: renamed from eth0 Feb 27 14:53:07 wombat.wombatz.com NetworkManager[1316]: <info> [1614466387.7201] manager: (enp5s0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2) Feb 27 14:53:07 wombat.wombatz.com NetworkManager[1316]: <info> [1614466387.7216] device (enp5s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') Feb 27 14:53:07 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: Link is Down
Here is what happened when I did the pull/push of the cable (I marked the spot where the pull and push happened...
# journalctl -fa -- Logs begin at Thu 2020-10-01 08:01:38 PDT. -- Feb 27 14:53:55 wombat.wombatz.com systemd[1]: dnfdaemon.service: Consumed 4.964s CPU time. Feb 27 14:53:58 wombat.wombatz.com chronyd[1331]: Selected source 212.26.18.43 (2.fedora.pool.ntp.org) Feb 27 14:53:58 wombat.wombatz.com chronyd[1331]: System clock TAI offset set to 37 seconds Feb 27 14:53:59 wombat.wombatz.com chronyd[1331]: Selected source 217.198.219.102 (2.fedora.pool.ntp.org) Feb 27 14:54:05 wombat.wombatz.com systemd[1]: NetworkManager-dispatcher.service: Succeeded. Feb 27 14:54:05 wombat.wombatz.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 27 14:54:10 wombat.wombatz.com systemd[1]: pcscd.service: Succeeded. Feb 27 14:54:10 wombat.wombatz.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=pcscd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 27 14:55:03 wombat.wombatz.com chronyd[1331]: Source 84.16.73.33 replaced with 2607:5300:201:3100::345c (2.fedora.pool.ntp.org) Feb 27 14:55:03 wombat.wombatz.com chronyd[1331]: Selected source 184.105.182.7 (2.fedora.pool.ntp.org) Feb 27 14:56:12 wombat.wombatz.com systemd[1636]: Starting Mark boot as successful... Feb 27 14:56:12 wombat.wombatz.com systemd[1636]: grub-boot-success.service: Succeeded. Feb 27 14:56:12 wombat.wombatz.com systemd[1636]: Finished Mark boot as successful.
Here is the wire pull/push:
Feb 27 14:56:28 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: Link is Up - 100Mbps/Full - flow control off Feb 27 14:56:28 wombat.wombatz.com kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5430] device (enp5s0): carrier: link connected Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5436] device (enp5s0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5451] policy: auto-activating connection 'Ether link to Pi' (837b199c-531d-3727-a66f-12a8096b570d) Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5460] device (enp5s0): Activation: starting connection 'Ether link to Pi' (837b199c-531d-3727-a66f-12a8096b570d) Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5463] device (enp5s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5482] device (enp5s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5493] device (enp5s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com avahi-daemon[1321]: Joining mDNS multicast group on interface enp5s0.IPv4 with address 192.168.11.4. Feb 27 14:56:28 wombat.wombatz.com avahi-daemon[1321]: New relevant interface enp5s0.IPv4 for mDNS. Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5519] device (enp5s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com avahi-daemon[1321]: Registering new address record for 192.168.11.4 on enp5s0.IPv4. Feb 27 14:56:28 wombat.wombatz.com systemd[1]: Starting Network Manager Script Dispatcher Service... Feb 27 14:56:28 wombat.wombatz.com systemd[1]: Started Network Manager Script Dispatcher Service. Feb 27 14:56:28 wombat.wombatz.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5799] device (enp5s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5803] device (enp5s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed') Feb 27 14:56:28 wombat.wombatz.com NetworkManager[1316]: <info> [1614466588.5823] device (enp5s0): Activation: successful, device activated. Feb 27 14:56:28 wombat.wombatz.com systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive. Feb 27 14:56:28 wombat.wombatz.com systemd[1]: squid.service: Unit cannot be reloaded because it is inactive. Feb 27 14:56:30 wombat.wombatz.com avahi-daemon[1321]: Joining mDNS multicast group on interface enp5s0.IPv6 with address fe80::226:18ff:fe3a:2a1b. Feb 27 14:56:30 wombat.wombatz.com avahi-daemon[1321]: New relevant interface enp5s0.IPv6 for mDNS. Feb 27 14:56:30 wombat.wombatz.com avahi-daemon[1321]: Registering new address record for fe80::226:18ff:fe3a:2a1b on enp5s0.*. Feb 27 14:56:39 wombat.wombatz.com systemd[1]: NetworkManager-dispatcher.service: Succeeded. Feb 27 14:56:39 wombat.wombatz.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
-- Doug Herr fedoraproject.org@wombatz.com _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 28/02/2021 01:50, Doug H. wrote:
The simple fix is to physically unplug and replug the cable. When it is not working (each reboot) there are not lights on. The physical "bounce" lights up the LEDs and it comes right up.
When you boot the system and get to the kernel selection menu can you stop the process by moving the cursor to a different kernel or by using "e" to edit the selected kernel? No drivers will be loaded at that point.
At that stage, so you see any LED's light or blink on the interface?
If "no", does that change if you unplug/plug the cable?
I use a wifi adapter for my main/Internet connection. This port is just used for a wired link to my Raspberry Pi.
Is it directly connected to the Pi?
On 2/27/21 3:06 PM, Doug H. wrote:
On to answering the question from Samuel: I am not seeing much help in the "while bad" journal:
# grep enp5s0 journalctl-b.while_not_working.txt Feb 27 14:52:58 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: renamed from eth0
That grep isn't going to help much given that line. Try searching for "r8169" instead.
Feb 27 14:53:07 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: Link is Down
So for whatever reason, the kernel driver thinks the link is down.
Here is the wire pull/push:
Feb 27 14:56:28 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: Link is Up - 100Mbps/Full - flow control off
And here the link comes up.
On Sat, Feb 27, 2021, at 3:56 PM, Samuel Sieb wrote:
On 2/27/21 3:06 PM, Doug H. wrote:
On to answering the question from Samuel: I am not seeing much help in the "while bad" journal:
# grep enp5s0 journalctl-b.while_not_working.txt Feb 27 14:52:58 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: renamed from eth0
That grep isn't going to help much given that line. Try searching for "r8169" instead.
Gives...
grep r8169 journalctl-b.while_not_working.txt
Feb 27 14:52:58 wombat.wombatz.com kernel: r8169 0000:05:00.0: can't disable ASPM; OS doesn't have ASPM control Feb 27 14:52:58 wombat.wombatz.com kernel: libphy: r8169: probed Feb 27 14:52:58 wombat.wombatz.com kernel: r8169 0000:05:00.0 eth0: RTL8168c/8111c, 00:26:18:3a:2a:1b, XID 3c4, IRQ 31 Feb 27 14:52:58 wombat.wombatz.com kernel: r8169 0000:05:00.0 eth0: jumbo features [frames: 6122 bytes, tx checksumming: ko] Feb 27 14:52:58 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: renamed from eth0 Feb 27 14:53:07 wombat.wombatz.com kernel: RTL8211B Gigabit Ethernet r8169-500:00: attached PHY driver [RTL8211B Gigabit Ethernet] (mii_bus:phy_addr=r8169-500:00, irq=IGNORE) Feb 27 14:53:07 wombat.wombatz.com kernel: r8169 0000:05:00.0 enp5s0: Link is Down
Roger: I tried everything I could with ethtool and it would not "bounce". It does not support the reset stuff so I guess that is the biggest issue there.
Ed:
When you boot the system and get to the kernel selection menu can you stop the process by moving the cursor to a different kernel or by using "e" to edit the selected kernel? No drivers will be loaded at that point.
At that stage, so you see any LED's light or blink on the interface?
Yes, the lights are happy/flashy up until a couple of seconds after the kernel starts, I.E. after the grub selection has been made.
Is it directly connected to the Pi?
Yup, it is CAT5 from port to port. I set it up to get better speeds when transferring files for the Plex player on the Pi. I then started to use it for the ability to "wake on LAN" since the Pi runs all time and this system is often suspended. This is why I waited to fix it. The system runs without this link but I *like* having it so finally sat down and started hammering at it.
On 2/27/21 4:24 PM, Doug H. wrote:
Is it directly connected to the Pi?
Yup, it is CAT5 from port to port. I set it up to get better speeds when transferring files for the Plex player on the Pi. I then started to use it for the ability to "wake on LAN" since the Pi runs all time and this system is often suspended. This is why I waited to fix it. The system runs without this link but I *like* having it so finally sat down and started hammering at it.
Do you have a network switch of some kind around? If so, try putting that in between and see if it makes any difference. It it does, then there might be something to try with ethtool.
On Sat, Feb 27, 2021, at 4:36 PM, Samuel Sieb wrote:
On 2/27/21 4:24 PM, Doug H. wrote:
Is it directly connected to the Pi?
Yup, it is CAT5 from port to port. I set it up to get better speeds when transferring files for the Plex player on the Pi. I then started to use it for the ability to "wake on LAN" since the Pi runs all time and this system is often suspended. This is why I waited to fix it. The system runs without this link but I *like* having it so finally sat down and started hammering at it.
Do you have a network switch of some kind around? If so, try putting that in between and see if it makes any difference. It it does, then there might be something to try with ethtool.
I do. Netgear FS116 Fast Ether switch.
This will also help to flesh out what Ed was asking about...
While up and working I added the switch in the middle. Worked fine, the connection came right back up once both hosts were plugged in.
This also gave me better visibility to the state during boot (the Ed questions). While booting the 10M light was on and this is the light that remained on all the way to the grub menu. I did hold there to make sure it was stable and then set a timer to see how long before the lights go out once I hit <enter> to select the kernel. That was 8 seconds.
But then comes the kicker...
This time the link came back up (as it used to, working at 100M) and it was working fine by the time Xfce was up I was able to check. So this issue does not seem to effect my setup if passing thru a switch.
I did/do still find ethtool to not want to do much:
# ethtool --test enp5s0 Cannot test: Operation not supported
# ethtool --reset enp5s0 all ETHTOOL_RESET 0xffffffff Cannot issue ETHTOOL_RESET: Operation not supported
So the good news is that this presents a fully automated (no pull/push) fix. The bad news is that I would have to live with 24x7 power drain of the switch since I can't tell it to suspend with my host. I will check the power draw with my "KillaWatt".
On 2/27/21 4:56 PM, Doug H. wrote:
On Sat, Feb 27, 2021, at 4:36 PM, Samuel Sieb wrote:
Do you have a network switch of some kind around? If so, try putting that in between and see if it makes any difference. It it does, then there might be something to try with ethtool.
I do. Netgear FS116 Fast Ether switch.
This will also help to flesh out what Ed was asking about...
While up and working I added the switch in the middle. Worked fine, the connection came right back up once both hosts were plugged in.
This also gave me better visibility to the state during boot (the Ed questions). While booting the 10M light was on and this is the light that remained on all the way to the grub menu. I did hold there to make sure it was stable and then set a timer to see how long before the lights go out once I hit <enter> to select the kernel. That was 8 seconds.
But then comes the kicker...
This time the link came back up (as it used to, working at 100M) and it was working fine by the time Xfce was up I was able to check. So this issue does not seem to effect my setup if passing thru a switch.
So this confirms what I was suspecting. The 10M you see at first is the "default" state of the ethernet card where it's watching for the wake-on-lan signal. Once the kernel boots and initializes the card, the card tries to auto-negotiate. This seems to be failing due to some interaction between the pi's network device and this one.
One thing to try if you can is to use a cross-over network cable.
It would have been helpful to see what the output of ethtool is when it's working, but when it's not working, try the following:
ethtool -s enp5s0 mdix on
Give it a few seconds, see if it comes on. If not, then try:
ethtool -s enp5s0 mdix off
On 28/02/2021 10:36, Samuel Sieb wrote:
So this confirms what I was suspecting. The 10M you see at first is the "default" state of the ethernet card where it's watching for the wake-on-lan signal. Once the kernel boots and initializes the card, the card tries to auto-negotiate. This seems to be failing due to some interaction between the pi's network device and this one.
If it is an issue of auto negotiation one could also try using nmcli to set
802-3-ethernet.auto-negotiate: to no and as well as the appropriate settings for
802-3-ethernet.speed: 802-3-ethernet.duplex:
in the connection settings.
Or use the appropriate GUI if more comfortable with that. :-)
Make sure to set the PI end to match. The 100Mbit/full auto-neg failure default is 10mbit/half and works badly with the other end running 100/full.
As someone also said you might want to try a 100Mbit crossover cable. The gig port would need to figure out correctly that it needs to have 2 pairs swapped and also apply the auto-neg process to the swapped pairs. It may be that forcing 100/full simplifies this process or it may be that a crossover cable with the correct pairs swapped removes the steps that don't happen right all of the time.
On Sat, Feb 27, 2021 at 8:55 PM Ed Greshko ed.greshko@greshko.com wrote:
On 28/02/2021 10:36, Samuel Sieb wrote:
So this confirms what I was suspecting. The 10M you see at first is the "default" state of the ethernet card where it's watching for the wake-on-lan signal. Once the kernel boots and initializes the card, the card tries to auto-negotiate. This seems to be failing due to some interaction between the pi's network device and this one.
If it is an issue of auto negotiation one could also try using nmcli to set
802-3-ethernet.auto-negotiate: to no and as well as the appropriate settings for
802-3-ethernet.speed: 802-3-ethernet.duplex:
in the connection settings.
Or use the appropriate GUI if more comfortable with that. :-)
-- People who believe they don't make mistakes have already made one. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sun, Feb 28, 2021, at 5:09 AM, Roger Heflin wrote:
Make sure to set the PI end to match.
Ah, good point. It should have been obvious but I have not even looked at the Pi end yet, other than `dmesg` and seeing the renewed connection:
$ dmesg |tail -2 [1932715.302313] smsc95xx 1-1.1:1.0 eth0: Link is Down [1932732.252198] smsc95xx 1-1.1:1.0 eth0: Link is Up - 100Mbps/Full - flow control off
I will check to see how that is set. Maybe just forced 100 full on both ends will solve this.
But I do have an old bin with Ethernet stuff, so maybe I still have an old cross over cable.
On Sat, Feb 27, 2021, at 6:36 PM, Samuel Sieb wrote:
On 2/27/21 4:56 PM, Doug H. wrote:
On Sat, Feb 27, 2021, at 4:36 PM, Samuel Sieb wrote:
Do you have a network switch of some kind around? If so, try putting that in between and see if it makes any difference. It it does, then there might be something to try with ethtool.
I do. Netgear FS116 Fast Ether switch.
This will also help to flesh out what Ed was asking about...
While up and working I added the switch in the middle. Worked fine, the connection came right back up once both hosts were plugged in.
This also gave me better visibility to the state during boot (the Ed questions). While booting the 10M light was on and this is the light that remained on all the way to the grub menu. I did hold there to make sure it was stable and then set a timer to see how long before the lights go out once I hit <enter> to select the kernel. That was 8 seconds.
But then comes the kicker...
This time the link came back up (as it used to, working at 100M) and it was working fine by the time Xfce was up I was able to check. So this issue does not seem to effect my setup if passing thru a switch.
So this confirms what I was suspecting. The 10M you see at first is the "default" state of the ethernet card where it's watching for the wake-on-lan signal. Once the kernel boots and initializes the card, the card tries to auto-negotiate. This seems to be failing due to some interaction between the pi's network device and this one.
One thing to try if you can is to use a cross-over network cable.
It would have been helpful to see what the output of ethtool is when it's working, but when it's not working, try the following:
ethtool -s enp5s0 mdix on
Give it a few seconds, see if it comes on. If not, then try:
ethtool -s enp5s0 mdix off
I did try this. Those commands do execute without giving an error but it does not then turn on any lights.
I did look thru my old cable box and found a D8CM and a GS8E so tried those. Not help.
Not yet sure of the difference but maybe... D8CM = Cat6 GS8E = GigaSPEED XL
But some good news, mostly...
While testing on the Pi end I found out that I can get the card to light up (and work) by resetting from the Pi side. Not sure why I had not tried that before.
Once the WiFi is up I can connect to the Pi that way and issue `sudo mii-tool --reset eth0`.
This wakes up lights on the Pi and then quickly does the same on my host.
I will need to write a script to run at boot time that waits for the WiFi to connect and then ssh over to wake up the Ethernet. Silly, but I just want to be able to stop doing the cable pull/push at reboot.
And you did ask for ethtool output while working:
Fedora side:
s ethtool enp5s0
Settings for enp5s0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 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/Half 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 Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: MII PHYAD: 0 Transceiver: external Supports Wake-on: pumbg Wake-on: g Link detected: yes
Pi side: $ s ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbag Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: yes
On Sun, Feb 28, 2021, at 9:44 AM, Doug H. wrote:
And you did ask for ethtool output while working:
I just realized that the ethtool output from the Pi side had only the single 100Full as advertised. It still needed a reboot after some tests to lock them both to 100Full. I ended up rolling that back but the Pi still needed a reboot to fully change, so the post reboot output is:
$ s ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/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 Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbag Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: yes
Since this is a change, I will go ahead and reboot to make sure the issue is still there and that the new kludge/fix still works.
For what it is worth, I had a smoothieboard I was trying to connect directly to my computer, and no power on earth seemed to be able to make it work reliably with DHCP. I statically configured the IP, and it connects every time with a direct connection. Never did figure out that issue, just leaving it static now that it works.
(It would talk via DHCP about one in 10 times I powered it up).
On Sun, Feb 28, 2021, at 10:01 AM, Tom Horsley wrote:
For what it is worth, I had a smoothieboard I was trying to connect directly to my computer, and no power on earth seemed to be able to make it work reliably with DHCP. I statically configured the IP, and it connects every time with a direct connection. Never did figure out that issue, just leaving it static now that it works.
(It would talk via DHCP about one in 10 times I powered it up).
This is also a "For what it is worth" addition...
Yup, this connection is static, so clearly not that issue.
On my post Pi reboot test I started by powering off my computer, then "draining it" by turning off the power supply switch then hitting the power button which gives a click from the speaker. Only then do I turn the power supply back on and again hitting the power button to power up. Interestingly this *did* then find the NIC to work fine. Problem solved?, nope. I then rebooted to see the problem still there. This did allow me to test my new desktop icon to run an ssh over to the Pi (once I see WiFi up). The script (ssh pi 'sudo mii-tool --reset eth0') works fine. So I am done with this, I will just watch to see if something mysteriously fixes it eventually. But I will be happy to test anything else people might want me to try.
Thanks all for the help.
On 2/27/21 6:55 PM, Ed Greshko wrote:
On 28/02/2021 10:36, Samuel Sieb wrote:
So this confirms what I was suspecting. The 10M you see at first is the "default" state of the ethernet card where it's watching for the wake-on-lan signal. Once the kernel boots and initializes the card, the card tries to auto-negotiate. This seems to be failing due to some interaction between the pi's network device and this one.
If it is an issue of auto negotiation one could also try using nmcli to set
802-3-ethernet.auto-negotiate: to no and as well as the appropriate settings for
802-3-ethernet.speed: 802-3-ethernet.duplex:
in the connection settings.
I don't think that would work. The problem is most likely the MDI-X negotiation which neither card supports a setting for. I suspect a crossover cable would also resolve the problem.
On 2/28/21 9:44 AM, Doug H. wrote:
On Sat, Feb 27, 2021, at 6:36 PM, Samuel Sieb wrote:
One thing to try if you can is to use a cross-over network cable.
I still think this would be your best option if you can find or make one.
It would have been helpful to see what the output of ethtool is when it's working, but when it's not working, try the following:
ethtool -s enp5s0 mdix on
Give it a few seconds, see if it comes on. If not, then try:
ethtool -s enp5s0 mdix off
I did try this. Those commands do execute without giving an error but it does not then turn on any lights.
Yes, now that I see your ethtool output, neither device supports setting this. I'm somewhat surprised that it doesn't give an error, but maybe by design it doesn't error on unsupported functions.
On Sun, Feb 28, 2021, at 12:07 PM, Samuel Sieb wrote:
On 2/28/21 9:44 AM, Doug H. wrote:
On Sat, Feb 27, 2021, at 6:36 PM, Samuel Sieb wrote:
One thing to try if you can is to use a cross-over network cable.
I still think this would be your best option if you can find or make one.
For just $4.60 delivered: Amphenol MP-5XRJ45UNNB-003 Cat5e UTP Crossover Cable, RJ45,
I am willing, but do wonder why it worked for so long and still works when it does work.
On 2/28/21 12:36 PM, Doug H. wrote:
On Sun, Feb 28, 2021, at 12:07 PM, Samuel Sieb wrote:
On 2/28/21 9:44 AM, Doug H. wrote:
On Sat, Feb 27, 2021, at 6:36 PM, Samuel Sieb wrote:
One thing to try if you can is to use a cross-over network cable.
I still think this would be your best option if you can find or make one.
For just $4.60 delivered: Amphenol MP-5XRJ45UNNB-003 Cat5e UTP Crossover Cable, RJ45,
I am willing, but do wonder why it worked for so long and still works when it does work.
There could be weird timing issues with the auto-negotiation. It's really hard to say. Just for curiosity, what happens if you disable the wake-on-lan option? Was that something you changed recently? Because it does seem possibly related to the transition from that, since you mentioned that it works after a full cold boot where the ethernet is completely off.
On Sun, Feb 28, 2021, at 12:50 PM, Samuel Sieb wrote:
On 2/28/21 12:36 PM, Doug H. wrote:
On Sun, Feb 28, 2021, at 12:07 PM, Samuel Sieb wrote:
On 2/28/21 9:44 AM, Doug H. wrote:
On Sat, Feb 27, 2021, at 6:36 PM, Samuel Sieb wrote:
One thing to try if you can is to use a cross-over network cable.
I still think this would be your best option if you can find or make one.
For just $4.60 delivered: Amphenol MP-5XRJ45UNNB-003 Cat5e UTP Crossover Cable, RJ45,
I am willing, but do wonder why it worked for so long and still works when it does work.
There could be weird timing issues with the auto-negotiation. It's really hard to say. Just for curiosity, what happens if you disable the wake-on-lan option? Was that something you changed recently? Because it does seem possibly related to the transition from that, since you mentioned that it works after a full cold boot where the ethernet is completely off.
1. Turned off my rc.local line of `/sbin/ethtool -s enp5s0 wol g` 2. Powered off, did my "power drain" thing. 3. Booted, finding it working fine (as before). 4. Checked Wake on LAN and it was still on, hmmm... 5. Realized that it was being set by NetworkManager, the rc.local was only needed when I was using network *without* NetworkManager. 6. Set NetworkManager setting to off/default. Verified with `ethtool`. 7. Reboot. Still seeing the issue.
P.S. I found a Belkin cable for $3.99. I like that name better, so ordered it. Belkin 3-Foot CAT5e Crossover Molded Networking Cable (Yellow)
It seems worth the test and worth having such a cable.
On 28Feb2021 13:41, Doug H. fedoraproject.org@wombatz.com wrote:
P.S. I found a Belkin cable for $3.99. I like that name better, so ordered it. Belkin 3-Foot CAT5e Crossover Molded Networking Cable (Yellow)
It seems worth the test and worth having such a cable.
Aye. FWIW, in a former life the place I worked at made all our crossover cables yellow so that we knew what we were looking at.
Cheers, Cameron Simpson cs@cskk.id.au
On Tue, 2021-03-02 at 08:33 +1100, Cameron Simpson wrote:
Aye. FWIW, in a former life the place I worked at made all our crossover cables yellow so that we knew what we were looking at.
I'd always understood that gigabit didn't need crossover cables, though just read that it's in the spec that gigabit can handle peer to peer without a crossover cable, devices don't actually have to incorporate that features into themselves. Argh! Back to square one.
Autocrossover was possible on 10/100 megabit ethernet devices, too, but much more rarely implemented.
The old 10/100 ethernet crossover cable just crosses over two pairs in the cable, and ignores the other two pairs (completely ignores them, they're generally not used at all, and not crossed over). Cheap ethernet cables bundled with some routers didn't even wire up the spare 4 pins.
Gigabit ethernet cable crosses over all four pairs.
So, label your cables (half-crossed, fully-crossed, 2-pairs crossed, 4- pairs crossed, whatever label makes the most sense to you).
Quite a few of us only connect computers together through switches or routers, so don't use crossover cables. But some of us also have connect a switch to a switch, when doing inter-room networking. I wonder how many routers or switches stuff-up auto crossover?
On Sun, Feb 28, 2021, at 12:07 PM, Samuel Sieb wrote:
On 2/28/21 9:44 AM, Doug H. wrote:
On Sat, Feb 27, 2021, at 6:36 PM, Samuel Sieb wrote:
One thing to try if you can is to use a cross-over network cable.
I still think this would be your best option if you can find or make one.
Unfortunately the cross over cable has not solved the issue. It works just the same as a straight cable in this situation. The NIC does say that it supports auto detection, which does seem to be working and not the core of this issue.
It would have been helpful to see what the output of ethtool is when it's working, but when it's not working, try the following:
ethtool -s enp5s0 mdix on
Give it a few seconds, see if it comes on. If not, then try:
ethtool -s enp5s0 mdix off
I did try this. Those commands do execute without giving an error but it does not then turn on any lights.
Yes, now that I see your ethtool output, neither device supports setting this. I'm somewhat surprised that it doesn't give an error, but maybe by design it doesn't error on unsupported functions.
An interesting note is that while testing with the cross over cable I ended up with it hardly working at all. The fix was `ethtool -s enp5s0 mdix on`. So it does seem that these commands were doing something after all.
I did find a 1 Gig switch that has a low power draw, so I can either use that to fully fix the issue or I can use my "bounce it from the Pi side" icon after each reboot.
-
Cameron Simpson -
Doug H. -
Ed Greshko -
George N. White III -
Joe Zeff -
Roger Heflin -
Samuel Sieb -
Tim -
Tom Horsley