On Wednesday, 22 March 2017 16:58:35 UTC+11, Jon Seymour wrote: > > > > 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 <jon.s...@gmail.com> >>>> 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. >
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, -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2c053e3b-16a7-409e-b2b8-7b02318314e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.