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?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/02c92417-7142-41c8-8564-f202658fce00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/RFbRNJCk7l8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b8121485-46b9-43b2-a4a8-436b7a5c8454%40googlegroups.com.
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!
On Tue, Mar 21, 2017 at 2:29 PM, Jon Seymour <jon.s...@gmail.com> wrote:
On Tuesday, 21 March 2017 14:18:41 UTC+11, William Hermans wrote: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.
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.
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.
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,