Wired Ethernet connection on RPi4 stays on "ready" instead of going "online"

yurikill · August 28, 2024 at 3:06 PM

Hi all,

I have an issue where my Raspberry Pi 4 fails to come online via a wired connection. The connection state remains "ready" and never gets itself to "online".

This occurs on the built-in network interface, but also on a USB3.0 network interface that I tested. I suspect for some reason, the 'online-check' of connman does not initiate. In my logs I can also see that the route described in https://wiki.archlinux.org/title/ConnMan#…e_on_connection is never made:

On eth0:

Code

Feb 27 18:26:11.584990 LibreELEC connman-vpnd[454]: eth0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Feb 27 18:26:11.584991 LibreELEC connmand[747]: eth0 {add} route fe80:: gw :: scope 0 <UNIVERSE>
Feb 27 18:26:11.585006 LibreELEC connman-vpnd[454]: eth0 {newlink} index 2 address E4:5F:01:F5:ED:BF mtu 1500
Feb 27 18:26:11.585015 LibreELEC connman-vpnd[454]: eth0 {newlink} index 2 operstate 6 <UP>
Feb 27 18:26:11.585038 LibreELEC connmand[747]: eth0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Feb 27 18:26:11.585050 LibreELEC connmand[747]: eth0 {newlink} index 2 address E4:5F:01:F5:ED:BF mtu 1500
Feb 27 18:26:11.585059 LibreELEC connmand[747]: eth0 {newlink} index 2 operstate 6 <UP>
Feb 27 18:26:11.587914 LibreELEC kernel: bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Feb 27 18:26:11.601832 LibreELEC kernel: 8021q: 802.1Q VLAN Support v1.8
Feb 27 18:26:11.628427 LibreELEC avahi-daemon[769]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.128.69.
Feb 27 18:26:11.628501 LibreELEC avahi-daemon[769]: New relevant interface eth0.IPv4 for mDNS.
Feb 27 18:26:11.628572 LibreELEC avahi-daemon[769]: Registering new address record for 10.0.128.69 on eth0.IPv4.
Feb 27 18:26:11.629049 LibreELEC connmand[747]: Setting domainname to domumadinferos.nl
Feb 27 18:26:11.668026 LibreELEC connmand[747]: eth0 {add} address 10.0.128.69/16 label eth0 family 2
Feb 27 18:26:11.668827 LibreELEC connmand[747]: eth0 {add} route 10.0.0.0 gw 0.0.0.0 scope 253 <LINK>
Feb 27 18:26:11.668865 LibreELEC connmand[747]: eth0 {add} route 10.0.0.1 gw 0.0.0.0 scope 253 <LINK>
Feb 27 18:26:11.668903 LibreELEC connmand[747]: eth0 {add} route 9.9.9.9 gw 10.0.0.1 scope 0 <UNIVERSE>
Feb 27 18:26:11.668939 LibreELEC connmand[747]: eth0 {add} route 1.1.1.1 gw 10.0.0.1 scope 0 <UNIVERSE>
Feb 27 18:26:11.668977 LibreELEC connmand[747]: eth0 {add} route 0.0.0.0 gw 10.0.0.1 scope 0 <UNIVERSE>
.... end for eth0

Display More

When Kodi has booted, I go into the LibreELEC settings to disconnect to the wired network and connect to a wireless network, and the behaviour shows in the logs like this (wlan0):

Code

Feb 27 18:28:16.889749 LibreELEC avahi-daemon[769]: Withdrawing address record for 10.0.128.69 on eth0.
Feb 27 18:28:16.889849 LibreELEC avahi-daemon[769]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.0.128.69.
Feb 27 18:28:16.889907 LibreELEC avahi-daemon[769]: Interface eth0.IPv4 no longer relevant for mDNS.
Feb 27 18:28:16.892001 LibreELEC avahi-daemon[769]: Withdrawing address record for fe80::e65f:1ff:fef5:edbf on eth0.
Feb 27 18:28:16.892083 LibreELEC avahi-daemon[769]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::e65f:1ff:fef5:edbf.
Feb 27 18:28:16.914563 LibreELEC kernel: bcmgenet fd580000.ethernet eth0: Link is Down
Feb 27 18:28:16.964784 LibreELEC connman-vpnd[454]: eth0 {update} flags 36866 <DOWN>
Feb 27 18:28:16.964811 LibreELEC connman-vpnd[454]: eth0 {newlink} index 2 address E4:5F:01:F5:ED:BF mtu 1500
Feb 27 18:28:16.964829 LibreELEC connman-vpnd[454]: eth0 {newlink} index 2 operstate 2 <DOWN>
Feb 27 18:28:16.966014 LibreELEC avahi-daemon[769]: Interface eth0.IPv6 no longer relevant for mDNS.
Feb 27 18:28:16.972738 LibreELEC connmand[747]: eth0 {del} address 10.0.128.69/16 label eth0
Feb 27 18:28:16.972829 LibreELEC connmand[747]: eth0 {del} route 10.0.0.0 gw 0.0.0.0 scope 253 <LINK>
Feb 27 18:28:16.972947 LibreELEC connmand[747]: eth0 {del} route fe80:: gw :: scope 0 <UNIVERSE>
Feb 27 18:28:16.973059 LibreELEC connmand[747]: eth0 {add} route fe80:: gw :: scope 0 <UNIVERSE>
Feb 27 18:28:16.973134 LibreELEC connmand[747]: eth0 {RX} 813 packets 162115 bytes
Feb 27 18:28:16.973151 LibreELEC connmand[747]: eth0 {TX} 324 packets 51924 bytes
Feb 27 18:28:16.973172 LibreELEC connmand[747]: eth0 {update} flags 36866 <DOWN>
Feb 27 18:28:16.973194 LibreELEC connmand[747]: eth0 {newlink} index 2 address E4:5F:01:F5:ED:BF mtu 1500
Feb 27 18:28:16.973211 LibreELEC connmand[747]: eth0 {newlink} index 2 operstate 2 <DOWN>
Feb 27 18:28:16.973400 LibreELEC connmand[747]: eth0 {del} route fe80:: gw :: scope 0 <UNIVERSE>
Feb 27 18:28:21.523575 LibreELEC connman-vpnd[454]: wlan0 {update} flags 4099 <UP>
Feb 27 18:28:21.523592 LibreELEC connman-vpnd[454]: wlan0 {newlink} index 3 address E4:5F:01:F5:ED:C1 mtu 1500
Feb 27 18:28:21.523601 LibreELEC connman-vpnd[454]: wlan0 {newlink} index 3 operstate 2 <DOWN>
Feb 27 18:28:21.524549 LibreELEC iwd[476]: event: state, old: disconnected, new: autoconnect_quick
Feb 27 18:28:21.524963 LibreELEC kernel: brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Feb 27 18:28:21.526824 LibreELEC connmand[747]: wlan0 {update} flags 4099 <UP>
Feb 27 18:28:21.526839 LibreELEC connmand[747]: wlan0 {newlink} index 3 address E4:5F:01:F5:ED:C1 mtu 1500
Feb 27 18:28:21.526849 LibreELEC connmand[747]: wlan0 {newlink} index 3 operstate 2 <DOWN>
Feb 27 18:28:21.545542 LibreELEC iwd[476]: Could not register frame watch type 00d0: -114
Feb 27 18:28:25.958421 LibreELEC connmand[747]: ipconfig state 2 ipconfig method 1
Feb 27 18:28:26.024081 LibreELEC iwd[476]: event: connect-info, ssid: home-network-irrelevant-for-this-log, bss: 68:d7:9a:45:d8:53, signal: -52, load: 27/255
Feb 27 18:28:26.024081 LibreELEC iwd[476]: event: state, old: autoconnect_full, new: connecting
Feb 27 18:28:26.024734 LibreELEC iwd[476]: CMD_SET_CQM failed: Operation not supported
Feb 27 18:28:26.057961 LibreELEC connmand[747]: ipconfig state 3 ipconfig method 1
Feb 27 18:28:26.166345 LibreELEC connman-vpnd[454]: wlan0 {update} flags 69635 <UP,LOWER_UP>
Feb 27 18:28:26.166362 LibreELEC connman-vpnd[454]: wlan0 {newlink} index 3 address E4:5F:01:F5:ED:C1 mtu 1500
Feb 27 18:28:26.167153 LibreELEC iwd[476]: event: state, old: connecting, new: connected
Feb 27 18:28:26.166372 LibreELEC connman-vpnd[454]: wlan0 {newlink} index 3 operstate 5 <DORMANT>
Feb 27 18:28:26.166683 LibreELEC connmand[747]: wlan0 {update} flags 69635 <UP,LOWER_UP>
Feb 27 18:28:26.166698 LibreELEC connmand[747]: wlan0 {newlink} index 3 address E4:5F:01:F5:ED:C1 mtu 1500
Feb 27 18:28:26.166708 LibreELEC connmand[747]: wlan0 {newlink} index 3 operstate 5 <DORMANT>
Feb 27 18:28:26.193711 LibreELEC connman-vpnd[454]: wlan0 {update} flags 69699 <UP,RUNNING,LOWER_UP>
Feb 27 18:28:26.193732 LibreELEC connman-vpnd[454]: wlan0 {newlink} index 3 address E4:5F:01:F5:ED:C1 mtu 1500
Feb 27 18:28:26.193740 LibreELEC connmand[747]: wlan0 {update} flags 69699 <UP,RUNNING,LOWER_UP>
Feb 27 18:28:26.193741 LibreELEC connman-vpnd[454]: wlan0 {newlink} index 3 operstate 6 <UP>
Feb 27 18:28:26.193757 LibreELEC connmand[747]: wlan0 {newlink} index 3 address E4:5F:01:F5:ED:C1 mtu 1500
Feb 27 18:28:26.193767 LibreELEC connmand[747]: wlan0 {newlink} index 3 operstate 6 <UP>
Feb 27 18:28:26.194561 LibreELEC kernel: ieee80211 phy0: brcmf_p2p_send_action_frame: Unknown Frame: category 0x5, action 0x4
Feb 27 18:28:32.415153 LibreELEC avahi-daemon[769]: Joining mDNS multicast group on interface wlan0.IPv4 with address 10.0.128.68.
Feb 27 18:28:32.418327 LibreELEC avahi-daemon[769]: New relevant interface wlan0.IPv4 for mDNS.
Feb 27 18:28:32.418515 LibreELEC avahi-daemon[769]: Registering new address record for 10.0.128.68 on wlan0.IPv4.
Feb 27 18:28:32.419372 LibreELEC connmand[747]: Setting domainname to domumadinferos.nl
Feb 27 18:28:32.458275 LibreELEC connmand[747]: wlan0 {add} address 10.0.128.68/16 label wlan0 family 2
Feb 27 18:28:32.460470 LibreELEC connmand[747]: wlan0 {add} route 10.0.0.0 gw 0.0.0.0 scope 253 <LINK>
Feb 27 18:28:32.460546 LibreELEC connmand[747]: wlan0 {add} route 10.0.0.1 gw 0.0.0.0 scope 253 <LINK>
Feb 27 18:28:32.460616 LibreELEC connmand[747]: wlan0 {add} route 9.9.9.9 gw 10.0.0.1 scope 0 <UNIVERSE>
Feb 27 18:28:32.460682 LibreELEC connmand[747]: wlan0 {add} route 1.1.1.1 gw 10.0.0.1 scope 0 <UNIVERSE>
Feb 27 18:28:32.460860 LibreELEC connmand[747]: wlan0 {add} route 0.0.0.0 gw 10.0.0.1 scope 0 <UNIVERSE>
Feb 27 18:28:32.475356 LibreELEC connmand[747]: wlan0 {add} route 82.165.8.211 gw 10.0.0.1 scope 0 <UNIVERSE>
Feb 27 18:28:32.499161 LibreELEC connmand[747]: ntp: adjust (jump): +15797799.355068 sec
Aug 28 15:45:11.873514 LibreELEC connmand[747]: wlan0 {del} route 82.165.8.211 gw 10.0.0.1 scope 0 <UNIVERSE>

Display More

The DHCP server behind both these networks is the same, i.e. there is no difference in issued DNS-servers or time servers for that matter.

I seem to be reaching in the dark as to why the Pi fails to come online through a wired connection, as the documentation of connman and other online resources do not really help me. Anyone willing to take a guess on what kind of behavior is shown here, and maybe help me out? Might it be possible to disable connman's online check, or what might cause it to not be started at all?

HarryH · August 28, 2024 at 7:28 PM

One question: Do you have a managed switch (for example Cisco SG200-08P ) in use for your wired network?

yurikill · August 29, 2024 at 2:57 PM

Yes, and I do make use of VLANs. However, the switch port on which the Pi is connected is untagged, so I naively ruled that out as a cause. What are you thinking HarryH ?

yurikill · August 29, 2024 at 4:24 PM

As it occurs, I was indeed being naive. The switch port was set to "trunk" with a native VLAN ID.

Switching the port on the network switch to completely untagged solves the problem for me. I am still a bit puzzled as to why. Is handling VLANs a common problem for Pis?

For now, solved. Thanks a lot for pointing me in the right direction HarryH !

HarryH · August 29, 2024 at 5:08 PM Best Answer

You are right, my question was not without a troubleshooting background.

In the past, I had a long term NFS troubleshooting with a network newbie as a communication partner. He was using the SG200-08P managed switch, but he didn't mention it. The network had been producing strange problems. NFS connections were not possible between the satellite receiver and the NAS. We spent ages trying out the settings on both the receiver and the NAS. In the end, I was able to convince him to install the latest (also end-of-life for several years) firmware, and voila - the error was gone.

I also know of some old changelogs for enterprise switches that had problems with DHCP relay. So maybe you should look for a changelog for the switch you are using and try to get a newer firmware.

Of course it could also be a problem on the kernel side, but I suspect the number of home users with managed switches is not very large, to get a valid feedback from others.

EDIT:
Depending on the switch vendor you use, "trunk" implies that all traffic at this port is tagged. That means, you must ensure that the client (RPi) know about it and configure the corresponding VLAN ID there too.

yurikill · August 30, 2024 at 12:06 PM

You are right! It is quite a ride debugging these issues without proper logging to point you in the right direction .

Last note from my side is that the switch port operated on "general" mode, not strictly "trunk" mode. In my configuration, that meant on the specific port:

untagged traffic: VLAN 1
tagged traffic: VLAN 10,20,30,... etc.

..., which should have been good in my understanding. DHCP was working fine, as the Pi got an IP address in the expected IP range for that VLAN. But that was it...

The switch in question is a Netgear GC110.

For now, I have no issues changing the switch port to completely untagged, as it solves this case and I have no current use case for handling multiple VLANs on that connection.

HarryH · August 30, 2024 at 4:38 PM

Your configuration looks to me like common practice and in my opinion it normally should work.

I grabbed this from the known issues part of the GC110 firmware changelog:

Loop protection might not work between two Insight-managed switches.
Workaround: Disable IGMP snooping on at last one the switches.
When IGMP snooping or MLD snooping is globally enabled or enabled on a VLAN, unknown multicast packets are dropped for both IPv4 and IPv6 traffic.
Workaround: Disable both IGMP snooping and MLD snooping.

If you doesn't have the DHCP L2 Relay / DHCP snooping enabled and accidentally misconfigured, then there seems to be some other "features" available that can be trigger such issues too...