Issues with configuration of USB Ethernet adapter under Debian

GoogleGroups
1

I am trying to use d D-Link USB Ethernet with Debian 8.7 running on BBB.

The device describes itself as: “D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter”.

The lsusb output is:

“Bus 001 Device 002: ID 2001:4a00 D-Link Corp.”

The driver for this device is ax88179_178a which is loaded into the kernel as a module.

The driver finds the device:

[ 21.274812] ax88179_178a 1-1:1.0 eth1: register ‘ax88179_178a’ at usb-musb-hdrc.1.auto-1, D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter, e4:6f:13:f3:df:43

[ 21.280951] usbcore: registered new interface driver ax88179_178a

[ 21.791100] omap-sham 53100000.sham: hw accel on OMAP rev 4.3

[ 21.836014] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2

[ 23.920271] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping ok

[ 24.088282] ax88179_178a 1-1:1.0 enxe46f13f3df43: renamed from eth1

If I manually bring enxe46f13f3df43 up, then I can configure it and get a working connection to the internet.

I wanted to automatically bring up the device to use DHCP but when I added:

auto enxe46f13f3df43

iface enxe46f13f3df43 inet dhcp

to /etc/network/interfaces the interface was not brought up automatically (even after reboot)

I tried to statically configured the device with:

auto enxe46f13f3df43

iface enxe46f13f3df43 inet static

address 192.168.1.100

network 255.255.255.0

gateway 192.168.1.1

but the interface also did not come up automatically in this case. It would come up correctly configured if I manually ran ifup enxe46f13f3df43.

I also tried to change the interface name to eth1 using /etc/udev/rules.d/71-local-rules

Auto generated by RootStock-NG: setup_sdcard.sh

udevadm info -q all -p /sys/class/net/eth0 --attribute-walk

BeagleBone: net device ()

SUBSYSTEM==“net”, ACTION==“add”, KERNELS==“enxe46f13f3df43”, ATTR{dev_id}==“0x0”, ATTR{type}==“1”, NAME=“eth1”

I also tried to use the systemd.link feature by creating a file called /etc/systemd/network/10-local.link with these contents:

[Match]

Driver=ax88179_178a

[Link]

Name=eth1

So, there are two problems here:

  • the interface is not being configured automatically

  • I can’t rename the interface with either udevd or systemd.link configuration

Can anyone help me understand why this isn’t working as expected?

2

So, it’s very likely you need the driver to come up before you can bring the interface up. So, one option would be to “inject” your driver into the initrd( very advanced ), or to write a systemd service( a systemd timer may also work ) that sets the device up appropriately.

My thinking is that /etc/network/interfaces is loading devices before the device driver for your adapter is loaded and running. You could experiment by duplicating the exact commands you’re using to manually bring the interface up( the commands where it works ), and run that script at boot through a systemd service. If that works, there is a good chance that it’s still loading slower than using the /etc/network/interfaces file . . . but if that’s the way you have to get it working at boot. It’ll work. Anyway, try that, and see if that work. If not, then what I said about the interfaces file trying ot load your network interface too fast is probably the case.

3

William, thanks for your reply.

I haven’t tried those steps yet, but what I have tried is systemctl stop networking which causes all intefaces but usb0 to disappear (which is fortunate, since I need that!). In particular, it removes eth0 and lo0. If I then run systemctl start networking, the other interfaces come back. My interpretation is that even if there was race condition during boot that might prevent enxe46f13f3df43 being detected on first boot, by the time it starts the second time, it should be there. The command I am using to bring up the interface is ifup, which does consult the /etc/network/interfaces file. It isn’t clear to me why a manually invoked ifup works, but a systemctl start networking doesn’t, even after the system has been booted for a while.

4

So, it's very likely you need the driver to come up before you can bring
the interface up. So, one option would be to "inject" your driver into the
initrd( very advanced ), or to write a systemd service( a systemd timer may
also work ) that sets the device up appropriately.

My thinking is that /etc/network/interfaces is loading devices *before*
the device driver for your adapter is loaded and running. You could
experiment by duplicating the exact commands you're using to manually bring
the interface up( the commands where it works ), and run that script at
boot through a systemd service. If that works, there is a good chance that
it's still loading slower than using the /etc/network/interfaces file . . .
but if that's the way you have to get it working at boot. It'll work.
Anyway, try that, and see if that work. If not, then what I said about the
interfaces file trying ot load your network interface too fast is probably
the case.

William, thanks for your reply.

I haven't tried those steps yet, but what I have tried is systemctl stop
networking which causes all intefaces but usb0 to disappear (which is
fortunate, since I need that!). In particular, it removes eth0 and lo0. If
I then run systemctl start networking, the other interfaces come back. My
interpretation is that even if there was race condition during boot that
might prevent enxe46f13f3df43 being detected on first boot, by the time
it starts the second time, it should be there. The command I am using to
bring up the interface is ifup, which does consult the
/etc/network/interfaces file. It isn't clear to me why a manually invoked
ifup works, but a systemctl start networking doesn't, even after the system
has been booted for a while.

William,

I just tried the systemctl stop/start networking scenario again and found
that it does actually work in this case, so the problem I initially
reported does appear to be a startup race condition as you suggest.

I'll investigate what can be done to fix a boot race along the lines you
suggest. Thanks for your help!

jon.

5

So I'm not exactly sure how to proceed myself, as far as putting your
drivers into the initrd, I'd have to read up myself on that. Robert does
have a script that updates the initrd, but I'm not clear on if this script
would work for this specfic case. If you're good at reading bash scripts .
. .

root@beaglebone:~# ls /opt/scripts/tools/developers/
apt-proxy.sh rcnee-testing.sh update_bootloader.sh
nfs-rsync.sh secondary_rootfs.sh update_initrd.sh

If not, google should yield decent results. The file here is
update_initrd.sh. Ideally, I think if you're always going to need this
adapter, you'd probably want to build the driver statically into the
kernel. Otherwise the best option would be inserting the driver into the
initrd( initramfs ) image. But the easiest way, would probably be to write
a systemd one shot timer that fires off at around maybe 30 seconds after
boot. This requires writing the timer, writing an associated service, and a
script that the service calls. enabling the timer, etc ,etc.

6

A further wrinkle is that I get “Bind socket to interface: No such device” errors if I try to configure dhcp for the interface in /etc/network/interfaces for reasons that are not clear to me. Configuring a static ip address works fine.

7

it's systemd that's doing the rename, in /boot/uEnv.txt, find the
"cmdline=coherent_pool=1M quiet" option and change it to:

cmdline="coherent_pool=1M net.ifnames=0 quiet"

Starting on Dec 9th 2016, we added the "net.ifnames=0" option by default.

on your next reboot, it'll show up as eth1..

Regards,

8

Robert,

Thanks for the suggestion. However, It doesn’t seem to have helped:

from dmesg output:

[ 21.314582] ax88179_178a 1-1:1.0 eth1: register ‘ax88179_178a’ at usb-musb-hdrc.1.auto-1, D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter, e4:6f:13:f3:df:43
[ 21.316347] usbcore: registered new interface driver ax88179_178a
[ 21.769915] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
[ 21.813675] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
[ 23.989152] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping ok
[ 24.099140] ax88179_178a 1-1:1.0 enxe46f13f3df43: renamed from eth1

debian@beaglebone:~$ cat /proc/cmdline
console=ttyO0,115200n8 root=UUID=74cfcc82-bdc4-483a-bcbd-cce4ad70ba00 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet

Currently, I have a udev rule in place:

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS==“ax88179_178a”, ATTR{dev_id}==“0x0”, ATTR{type}==“1”, KERNEL==“enx*”, NAME=“eth1”

Although I have also tried it with no udev rule. I also don’t have a systemd.link configuration in place.

debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.26-ti-r59 #4 SMP Wed Feb 22 00:13:46 UTC 2017 armv7l GNU/Linux

The kernel is a kernel I built from the r59 tag with a slightly different UART driver configuration.

jon.

9

It turns out that the following command is sufficient to disable the mangled interface names:

sudo ln -sf /dev/null /etc/udev/rules.d/80-net-setup-link.rules

and, in fact, net.ifnames=0 didn’t seem to have any effect one way or the other.

Also, with the shorter interface name, DHCP now works on the renamed interface - I have a suspicion that it was failing previously because the enxe46f13f3df43 was at the limit of a char array length in a structure defined in dhclient and this ultimately caused a downstream issue in the AF_PACKET handler within the implementation of the bind system call) because of the lack of a trailing null - all a supposition, of course.

jon

10

The reason net.ifnames=0 didn’t work appears to be related to this issue: http://askubuntu.com/questions/811295/73-usb-net-by-mac-rules-issue-with-net-ifnames/895533#895533.

In particular, net.ifnames=0 works if and only if /lib/udev/rules.d/73-usb-net-by-mac.rules is changed so that:

IMPORT{cmdline}=“net.ifnames”, ENV{net.ifnames}==“0”, GOTO=“usb_net_by_mac_end”

becomes:

IMPORT{cmdline}=“net.ifnames”
ENV{net.ifnames}==“0”, GOTO=“usb_net_by_mac_end”

With respect to the DHCP errors, I found that dhclient fails immediately if the interface name is: enxe46f13f3df43:

Internet Systems Consortium DHCP Client 4.3.1

Copyright 2004-2014 Internet Systems Consortium.

All rights reserved.

For info, please visit https://www.isc.org/software/dhcp/

Bind socket to interface: No such device

If you think you have received this message due to a bug rather

than a configuration issue please read the section on submitting

bugs on either our web page at www.isc.org or in the README file

before submitting a bug. These pages explain the proper

process and the information we find helpful for debugging…

exiting.

fails in a different way if the interface name is enxe46f13f3df4

Internet Systems Consortium DHCP Client 4.3.1

Copyright 2004-2014 Internet Systems Consortium.

All rights reserved.

For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enxe46f13f3df4/e4:6f:13:f3:df:43

Sending on LPF/enxe46f13f3df4/e4:6f:13:f3:df:43

Sending on Socket/fallback

DHCPDISCOVER on enxe46f13f3df4 to 255.255.255.255 port 67 interval 4

send_packet: No such device

dhclient.c:1966: Failed to send 300 byte long packet over enxe46f13f3df4 interface.

DHCPDISCOVER on enxe46f13f3df4 to 255.255.255.255 port 67 interval 10

send_packet: No such device

dhclient.c:1966: Failed to send 300 byte long packet over enxe46f13f3df4 interface.

and succeeds if the interfacename is enxe46f13f3df or shorter.

The apparent explanation is a short copy in dhclient when it attempts to bind a PF_PACKET socket with the AF_PACKET address type.

jon.

11

The udev problem with /lib/udev/rules.d/73-usb-net-by-mac.rules is fixed by the version of the file in:

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/extra/rules/73-usb-net-by-mac.rules?h=debian/233-5

which should be available in v233 or later releases of the debian udev package but is not the current jessie-backports version (which is v230).

jon.

jon,

12

To round this out, I raised a debian bug report on the isc-dhcp-client package

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858580

regarding support of long (>13 char) interface names.

jon.