udev rules to prioritize network interfaces

[macmpi]

This PR replaces Pi3-specific driver blacklist-based filter by udev rule.
It brings several benefits:

• avoids unwanted brcmfmac/brcmutil driver loads on all Pi platforms
• prioritizes plugged-in external USB network interfaces over built-in (wlan & eth)
• generic for all platforms (+added customization for Pi built-in eth which is on USB)

This fix has been tested with several devices and dongles.

[volumio]

That's clever. Has it been tested extensively? (trying to avoid regressions)

[macmpi]

Thanks.

Extensively, not really as I do not own sufficient HW derivatives.

I made many unitary (positive and negative) tests for base search on my PiZero with my USB dongles (wifi 8188eu, ethernet asix), and noted no issue.
The only test on Pi3 is on the mentioned forum thread: only wifi part has been validated with a realtek dongle.
You may want to check with your Pi3 (seems you have one) and wifi dongles.
If you have USB-ethernet dongle, I'm interested in your feedback too.

If you experience issues, please send me udevadm info /sys/class/net/YOUR_INTERFACE so that I can eventually fine-tune the filters.

[chsims1]

I have a Pi3 with several USB wifi adapters. Exactly what do you need testing? Simply udev rule inclusion and look at interfaces brought up?

[macmpi]

Sure, that would be great, thanks!

Indeed, you just have to restart with/without USB adapter plugged, and check which interface is actually used by Volumio.
You can confirm that's the one you want, by getting current interface details with udevadm info /sys/class/net/wlan0 (or eth0 if you test ethernet dongles).

Besides adding the udev rules file, you'll also want to (make copies elsewhere first):

• sudo rm /etc/modprobe.d/raspi-blacklist.conf
• keep only last line of /bin/wifistart.sh

This will replicate the complete PR

Looking forward your feedback.

[chsims1]

RTL8188cus: works as wanted, USB dongle wlan0, RPi internal wlan1
RTL8192cu: USB dongle 'rename4', RPi internal wlan0
RT5370: USB dongle 'rename4', RPi internal wlan0
Atheros (AR9170+AR9101): USB dongle didn't work, RPi internal wlan0

Edit: used second udev rule

[macmpi]

ok, thanks.
Could you please provide output of udevadm info /sys/class/net/YOUR_INTERFACE on those failing please? (maybe on pastebin)?

For few (rename4 in particular) it may be because of existing ralink rule installed by mrEngman drivers: could you sudo rm /etc/udev/rules.d/95-ralink.rules (keep a copy before) and check if it has any effect?

I guess Volumio does not have drivers for Atheros (AR9170+AR9101), so the fact they won't work is probably not related to this. Should we install drivers, they would probably be taken care of. (Would be nice to try though)

[chsims1]

Well, on second time of asking RTL8192cu comes up as wlan0 (RPi internal wlan1). Strange??

RT5370:

volumio@volumiokitchen:~$ udevadm info /sys/class/net/rename4 P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/net/rename4 E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/net/rename4 E: DEVTYPE=wlan E: ID_BUS=usb E: ID_MODEL=802.11_n_WLAN E: ID_MODEL_ENC=802.11\x20n\x20WLAN E: ID_MODEL_FROM_DATABASE=RT5370 Wireless Adapter E: ID_MODEL_ID=5370 E: ID_NET_DRIVER=rt2800usb E: ID_NET_NAME_MAC=wlx7cdd90b0dec5 E: ID_OUI_FROM_DATABASE=Shenzhen Ogemray Technology Co., Ltd. E: ID_PATH=platform-3f980000.usb-usb-0:1.4:1.0 E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_4_1_0 E: ID_REVISION=0101 E: ID_SERIAL=Ralink_802.11_n_WLAN_1.0 E: ID_SERIAL_SHORT=1.0 E: ID_TYPE=generic E: ID_USB_DRIVER=rt2800usb E: ID_USB_INTERFACES=:ffffff: E: ID_USB_INTERFACE_NUM=00 E: ID_VENDOR=Ralink E: ID_VENDOR_ENC=Ralink E: ID_VENDOR_FROM_DATABASE=Ralink Technology, Corp. E: ID_VENDOR_ID=148f E: IFINDEX=4 E: INTERFACE=rename4 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/rename4 E: TAGS=:systemd: E: USEC_INITIALIZED=66025

Removing the ralink rule made no difference.

[macmpi]

let me look...
for Atheros (parallel track), it's probably missing firmware: you may want to sudo apt-get install firmware-linux-free

[macmpi]

Can you please make sure /etc/udev/rules.d/70-persistent-net.rules is this:

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", KERNEL=="wlan*", ATTR{type}=="1", NAME="wlan0"
ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", KERNEL=="eth*", DRIVERS!="smsc95*", ATTR{type}=="1", NAME="eth0"

/etc/udev/rules.d/95-ralink.rules does not exist anymore
And you do a cold reboot each time you do another dongle test (removing power): sorry for this tedious process...

With that, are RTL8192cu and RT5370 still "faulty" in their names?

[volumio]

before removing power, make sure you type:
sync

[macmpi]

yes remove power after proper shutdown indeed!

[chsims1]

Ok, sorry for delay ... dog walking and making dinner got in the way ;).

Right, repeated for 4 dongles, ralink rule renamed, 70-persistent-net.rules as per your post above, sync & cold reboots between each.

RT8188cus: wlan0 and RPi internal on wlan1
RT9192cu: wlan0 and RPi internal on wlan1
RT5370: rename4 and RPi internal on wlan0
(AR9170+AR9101): rename4 and RPi internal on wlan0 (driver updated as above)

Don't know if it's useful but udevadm info /sys/class/net/rename4 for Atheros is:

volumio@volumiokitchen:~$ udevadm info /sys/class/net/rename4
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/net/rename4
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/net/rename4
E: DEVTYPE=wlan
E: ID_BUS=usb
E: ID_MODEL=USB2.0_WLAN
E: ID_MODEL_ENC=USB2.0\x20WLAN
E: ID_MODEL_FROM_DATABASE=WN111(v2) RangeMax Next Wireless [Atheros AR9170+AR9101]
E: ID_MODEL_ID=9001
E: ID_NET_DRIVER=carl9170
E: ID_NET_NAME_MAC=wlx00223f8b129f
E: ID_OUI_FROM_DATABASE=Netgear Inc.
E: ID_PATH=platform-3f980000.usb-usb-0:1.4:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_4_1_0
E: ID_REVISION=0106
E: ID_SERIAL=ATHER_USB2.0_WLAN_12345
E: ID_SERIAL_SHORT=12345
E: ID_TYPE=generic
E: ID_USB_CLASS_FROM_DATABASE=Vendor Specific Class
E: ID_USB_DRIVER=carl9170
E: ID_USB_INTERFACES=:ff0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_PROTOCOL_FROM_DATABASE=Vendor Specific Protocol
E: ID_USB_SUBCLASS_FROM_DATABASE=Vendor Specific Subclass
E: ID_VENDOR=ATHER
E: ID_VENDOR_ENC=ATHER
E: ID_VENDOR_FROM_DATABASE=NetGear, Inc.
E: ID_VENDOR_ID=0846
E: IFINDEX=4
E: INTERFACE=rename4
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/rename4
E: TAGS=:systemd:
E: USEC_INITIALIZED=915012

[macmpi]

ralink rule renamed

renamed what? (names do matter for rules as they are executed in sequence): removed from that directory (or altogether) would be much safer.

[chsims1]

Ah sorry, I was under the impression that it was anything named *.rules. I'll move it & try again.

Edit: Nope, exactly the same behaviour for RT5370 with the ralink rule totally absent from directory.

[macmpi]

Thanks for your kind help.
Could you look at dmesg for the early part of the startup process, if you see what happens with that interface: this may give clues. (put in pastebin if long log)

...and udevadm info -a /sys/class/net/rename4

[macmpi]

one other thing...can you comment (or remove) the second line (the one related to eth0) of the rule for now?
Does it change anything? (including the rename#)?

[chsims1]

I've not truncated the output from dmesg: http://pastebin.com/JzbazcyQ

Removing the eth0 line from the rule made no apparent diffference.

udevadm info -a /sys/class/net/rename4: http://pastebin.com/x4bqQjy5

[macmpi]

Thanks. Can you replace the rule content by this and tell if it helps?

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", ENV{DEVTYPE}=="wlan", NAME="wlan0", OPTIONS+="last_rule"
ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", KERNEL=="eth*", DRIVERS!="smsc95*", NAME="eth0", OPTIONS+="last_rule"

[chsims1]

Dongle still named 'rename4'

[macmpi]

dmesg has interesting bits, but indeed seems a bit shortened...can you get more through journactl?
rt2800usb seems to get to wlan1 and then rename4
Is built-in still at wlan0? (dmesg seems to imply that name was already taken when bcm wanted it...or maybe it's due to a Volumio wifi restart)
Are other dongles fine with that rule?
(BTW do you have any ethernet-USB dongle too?)

[chsims1]

http://pastebin.com/rfFKqgxg .....journalctl -b up to Volumio system starting. Noticeably much longer to reach accepting ssh connections with these dongles that have name as rename4.

Built-in wifi still wlan0.

Just checking other dongles now.

Sorry, no ethernet-USB dongles

Edit: RTL* work fine
AR* rename4

[macmpi]

Did you cut&paste the rule, can you eventually delete and retype?

I'm wondering if there is nothing wrong with those dongle drivers.
A part from this rule thing, did you get RT5370 or Atheros (AR9170+AR9101) working with Volumio distribution at some point?
Would they connect to Home AP or successfully created Volumio Hotspot?
To check this, you may use another (more radical) method to turn-off Pi3 wifi, and move the rule away.

[macmpi]

ok, seems like RT5370/TL-WN727N v3/Tenda_W311M might need extra config for proper udev support... do you have anything in there /sys/bus/usb/drivers/rt2800usb?
It uses rt2800usb driver like for all these.

[chsims1]

I did cut&paste..now deleted and typed in ... no difference to naming behaviour.

Yes, the dongle drivers are working fine; I can connect to my home AP without problems (after disabling internal wifi). However, neither Atheros or Ralink successfully created Volumio hotspot (indicated as 'on' in UI, but can't see network on my phone or a wifi analyser).

Drivers present in rt2800usb:

root@volumiokitchen:/sys/bus/usb/drivers/rt2800usb# ls /sys/bus/usb/drivers/rt2800usb 1-1.4:1.0 bind module new_id remove_id uevent unbind

So to conclude: the Atheros and Ralink dongles work fine with Volumio in RPi3 with internal wifi disabled, but they do not 'behave' with your prioritising udev rule, and nor do they produce hotspots with Volumio's current scripting.

As an aside, I bought the Atheros dongle specifically, quite some time ago, to investigate generating a hotspot for Volumio for a portable device ... at the time, it was one of a few dongles with an appropriate chipset that could simultaneously act as hotspot and normal wifi.

[macmpi]

ok, thanks.
Will keep investigating then & try to fine-tune (have another idea, focusing the rule in opposite direction to target bcm chip instead): thanks again for all your helpful efforts.

Maybe @earlchew can bring expertise on overall udev science to help making it more "universal" to dongles.

[chsims1]

Good luck. Udev is very powerful, but a bit of a pig to fine-tune to achieve exactly what you want/expect.

[chsims1]

RT5370: wlan1 (internal wlan0)
RTL8188cus: wlan0 (internal wlan1)
(AR9170 + AR9101): wlan1 (internal wlan0)
RTL8192cu: wlan0 (internal wlan1)

[macmpi]

Ok. I'm going to try to remotely access a friend's Pi3 to directly test some base stuff on that HW next week (several things at play it seems). If you accept, I'll get back to you when I have something more reliable to test across dongles, not to abuse your time and patience. Thanks again!

[volumio]

Still WIP?

[macmpi]

Yes...planning a remote session with @chsims1 to figure-out specif issues with his dongles/setup.
Had things work on several Pi3, but I'd rather confirm with this one.
Will update title when done.

BTW, to you want me to keep empty wifistart.sh as empty placeholder, or shall I remove altogether?

[volumio]

Let's keep it as an empty placeholder please (but I think we still need it to set power save off)

[macmpi]

/etc/network/if-pre-up.d/powersavedisable does it already!

[volumio]

Sometimes this does not work, for example for network devices turned on by wireless.js

[macmpi]

@volumio said

Sometimes this does not work, for example for network devices turned on by wireless.js

For my education, I'm curious which action in wireless.js does not relate to ifupdown and potentially omit if-pre-up.d scripts.
Quoting this:

About when scrips in if-pre-up.d and if-up.d are executed. They are only run for interfaces that are managed by ifupdown, that is they must be mentioned in /etc/network/interfaces. They are executed before and during setup of the interface that are to be started, as mentioned in the man page of interfaces.

I'll restore the line in wifistart.sh for precaution then.

As for the udev stuff: seems to work great on wlan side on @chsims1 setup: will let him confirm.
Still looking for eth0 side and tests... (Pi is special case here because built-in eth is on USB bus)

[chsims1]

Yep, all seems to be playing together nicely here. Well done.

[macmpi]

Glad it works!
Thanks so much for all your tests and kindness to provide remote access to get that done.

@volumio still giving a bit of thought & re-reading: will change PR title when ready for merge on my side.

[macmpi]

@volumio I think it can be merged now.

[volumio]

Ok, let me do last checks and then I'll merge

[macmpi]

Please hold a bit pending a last test from @chsims1 with that rules:

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", ENV{DEVTYPE}=="wlan", ATTR{type}=="1", KERNEL=="wlan[1-9]*", NAME="wlan0"
ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", ENV{DEVTYPE}!="wlan", ATTR{type}=="1", DRIVERS!="smsc95xx", KERNEL=="eth[1-9]*", NAME="eth0"

Simpler if no rename4 issues reported with that one (would not depend on extra code for naming).

[macmpi]

Ok, so the whole current PR is needed to circumvent some potential race conditions in renaming interfaces with kernel's default names.
So I consider PR "final": @volumio you may merge when you feel comfortable.

Longer term, it might be wise to consider naming Volumio network interfaces by some specific (and predictable) names, outside of kernel's default namespace (like volumio_wlan, volumio_lan or any other better names).
One key benefit is that whatever kernel's naming conventions (there could be at least 3) across platforms' own upcoming kernel versions, Volumio interfaces would always be called in the same way (no bothering with kernel/systems updates).
From there, one could also think about a plugin to pick&choose preferred interface cards for Volumio, etc...while avoiding potential race conditions.
Just food for thoughts...not too big (albeit careful) changes needed in Volumio codebase.