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 <[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.
>
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 [email protected].
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.
