On Thursday, 23 March 2017 11:21:17 UTC+11, Jon Seymour wrote:
>
>
>
> 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,
>
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.
--
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/7f0b5572-dcef-4695-9f2a-3b0e0925f5b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
