11:50 a.m.
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
--
Doug H.
3:36 p.m.
On 27Feb2021 09:50, Doug H. <fedoraproject.org(a)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(a)cskk.id.au>
3:58 p.m.
On Sat, Feb 27, 2021, at 1:36 PM, Cameron Simpson wrote:
On 27Feb2021 09:50, Doug H. <fedoraproject.org(a)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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
4:28 p.m.
On Sat, 27 Feb 2021 at 17:59, Doug H. <fedoraproject.org(a)wombatz.com> wrote:
On Sat, Feb 27, 2021, at 1:36 PM, Cameron Simpson wrote:
> On 27Feb2021 09:50, Doug H. <fedoraproject.org(a)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.
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.
--
George N. White III
4:12 p.m.
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?
4:21 p.m.
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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
4:31 p.m.
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.
5:06 p.m.
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(a)wombatz.com
5:30 p.m.
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(a)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(a)wombatz.com
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
5:56 p.m.
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.
6:24 p.m.
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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
6:36 p.m.
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.
6:56 p.m.
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".
--
Doug Herr
fedoraproject.org(a)wombatz.com
8:36 p.m.
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
8:55 p.m.
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.
7:09 a.m.
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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
10:10 a.m.
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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
2:04 p.m.
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.
11:44 a.m.
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
--
Doug Herr
fedoraproject.org(a)wombatz.com
11:59 a.m.
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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
12:01 p.m.
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).
12:13 p.m.
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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
2:07 p.m.
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.
2:36 p.m.
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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
2:50 p.m.
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.
3:41 p.m.
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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
3:33 p.m.
On 28Feb2021 13:41, Doug H. <fedoraproject.org(a)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(a)cskk.id.au>
10:34 p.m.
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?
--
uname -rsvp
Linux 3.10.0-1160.15.2.el7.x86_64 #1 SMP Wed Feb 3 15:06:38 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
10:12 a.m.
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.
--
Doug Herr
fedoraproject.org(a)wombatz.com
5:48 p.m.
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?
--
People who believe they don't make mistakes have already made one.
1146
days inactive
1152
days old
30 comments
9 participants
participants (9)
-
Cameron Simpson -
Doug H. -
Ed Greshko -
George N. White III -
Joe Zeff -
Roger Heflin -
Samuel Sieb -
Tim -
Tom Horsley