On Wednesday, 22 March 2017 14:58:32 UTC+11, Jon Seymour wrote: > > > > On Wednesday, 22 March 2017 11:58:26 UTC+11, Jon Seymour wrote: >> >> >> >> On Wednesday, 22 March 2017 01:08:22 UTC+11, RobertCNelson wrote: >>> >>> On Mon, Mar 20, 2017 at 9:37 PM, Jon Seymour <[email protected]> >>> wrote: >>> >>> > Can anyone help me understand why this isn't working as expected? >>> >>> 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, >>> >>> >> 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. >> >> > 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 >
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. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c8ddc676-dd09-4716-b435-202a02527cb3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
