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

    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:

    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):

    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? :S Might it be possible to disable connman's online check, or what might cause it to not be started at all?

  • Go to Best Answer

    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 !

    • 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.

    Edited 2 times, last by HarryH (August 29, 2024 at 6:22 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... /shrug

    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.

    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... ;)