1

I've got a powered USB hub with an ethernet port connected to my Pi, but I'm only interested on the USB ports, as it already has on-board ethernet. However, for some reason, when the Pi boots, the hub's ethernet appears to take over and the on-board ethernet is disabled. Meaning its got no internet, because the cable is plugged in to the Pi, not the hub. Once I disconnect the hub, the lights on the on-board ethernet light up and it connects to the internet. If I then reconnect the hub, its interface shows up but the on-board remains default.

I've tried turning on predictable interface names in raspi-config and disabling the interface in /etc/rc.local to no avail. The network settings on the Pi are pretty much stock except for a static IP address for eth0 in /etc/dhcpcd.conf.

How can I permanently disable the hub's network interface, and why would it seemingly override the on-board one?

ip -details link (no hub)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 minmtu 0 maxmtu 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether dc:a6:32:e7:b9:07 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 1500 addrgenmode none numtxqueues 5 numrxqueues 5 gso_max_size 65536 gso_max_segs 65535
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DORMANT group default qlen 1000
    link/ether dc:a6:32:e7:b9:08 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 1500 addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

ip -details link (with hub)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 minmtu 0 maxmtu 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether dc:a6:32:e7:b9:07 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 1500 addrgenmode none numtxqueues 5 numrxqueues 5 gso_max_size 65536 gso_max_segs 65535
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DORMANT group default qlen 1000
    link/ether dc:a6:32:e7:b9:08 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 1500 addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
4: enx2c16dba05ff7: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 2c:16:db:a0:5f:f7 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9194 addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 16354 gso_max_segs 65535

Note that the on-board ethernet worked when these details were taken as the hub was plugged in after boot.

I've also tried adding denyinterfaces enx2c16dba05ff7 to /etc/dhcpcd.conf as suggested by Ingo, but after rebooting I still have no internet until I unplug the hub.

ip -details link for the hub interface after this change:

3: enx2c16dba05ff7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 2c:16:db:a0:5f:f7 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9194 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 16354 gso_max_segs 65535
| improve this question | |
  • What Raspberry Pi version do you use? Please take note that using /etc/rc.local has limitations due to Compatibility with SysV. We have seen many problems here on this site using it. Following the recommendation of the developers from systemd you should avoid using it. Static ip addresses should only be used with some knowledge about networking. – Ingo Aug 7 at 19:01
  • @Ingo I am using a Raspberry Pi 4. The only modification I made to /etc/rc.local was add ip link set $iface down, where $iface is the interface of the USB hub. I'm using a static NAT IP address so that it doesn't change with DHCP. – FailedShack Aug 7 at 19:07
  • The simplest command in /etc/rc.local can fail. Don't use it. Please execute the command ip -details link, one time with connected, one time with disconnected hub. edit your question and add both outputs to it. – Ingo Aug 7 at 19:35
  • @Ingo Added those. – FailedShack Aug 7 at 20:00
3

As you can see the additional ethernet device on the USB hub is detected with interface enx2c16dba05ff7 on the RasPi. Now it is a routing issue what interface is preferred and preference may vary depending on the order the interfaces are detected. On boot up interface enx2c16dba05ff7 is preferred before eth0, when plugged in later, eth0 is already initialized and preferred.

But we need not to fiddle with the routing table. Because we just do not need the hubs interface, we can simply disable it. I assume you are using default dhcpcd networking. So just add a line to /etc/dhcpcd.conf:

denyinterfaces enx2c16dba05ff7
| improve this answer | |
  • Thank you, that did the trick. So the predictable names would have been necessary, as the names (eth0, eth1), could change based on if the hub were plugged in or not. I find it curious that USB devices and hence, the hub's network interface would be initialized before the on-board one. – FailedShack Aug 7 at 21:11
  • Hmm, I might not have had the dongle plugged in because I'm running into the same issue on reboot. I've checked journalctl _SYSTEMD_UNIT=dhcpcd.service and at least now there is no mention of the interface. – FailedShack Aug 7 at 23:18
  • Updated the question with the output of ip -details link after this change. – FailedShack Aug 8 at 0:34
  • @FailedShack Interface enx2c16dba05ff7 is DOWN now. That's correct so far. Do you still have eth0 and is it UP? Better you post the complete output. Boot with USB hub connected and then execute the commands ip addr and ip route and add the output to the question. – Ingo Aug 8 at 8:21
  • I have marked the answer as correct as in a vacuum it answers the question and does in fact, disable the interface. However, my problem is still unsolved. I've been investigating further and shed some new light on the matter. Please see my new question here: raspberrypi.stackexchange.com/questions/116009/… – FailedShack Aug 8 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.