Wlan predictable names

Hello, I have a rpi3 with two usb wifi dongles attached, and I have wifi-connect running as well.
The system seems to have systemd-predictable mechanism switched off and at every reboot, ifconfig shows wlan0, wlan1 and wlan2 referring every time to different hardware devices.

I need to activate systemd-predictable mechanism in order to allow to use wifi-connect only over wlan0 and allow my software to work with the specific dongles on wlan1 and wlan2

I’ve setup --portal-interface argument variable for wifi-connect, however it doesn’t seems to work (see below printout) and considering that wlan0 at every reboot refers to different hardware… is difficult to get it running predictably

this is what i see from inside the wifi-connect container and what the balenaos has as interfaces:

root@485b1c6:~# balena ps
CONTAINER ID        IMAGE                               COMMAND                  CREATED             STATUS                   PORTS                    NAMES
0aff7fb97ee9        2a4b40f80667                        "/usr/bin/entry.sh /…"   About an hour ago   Up 3 hours                                        scheduler_61_44
08d0a9064053        817e59585503                        "/usr/bin/entry.sh b…"   About an hour ago   Up 3 hours                                        wifi-connect_59_44
24d23e95a9cb        balena/armv7hf-supervisor:v9.15.0   "./entry.sh"             5 weeks ago         Up 8 minutes (healthy)                            resin_supervisor
root@485b1c6:~# balena exec -t -i 08d0a9064053 /bin/bash 
root@485b1c6:/usr/src/app# ls
start.sh  ui  wifi-connect
root@485b1c6:/usr/src/app# echo $PORTAL_INTERFACE
wlan0
root@485b1c6:/usr/src/app# exit
exit
root@485b1c6:~# ifconfig
[... output cut ....]
wlan0     Link encap:Ethernet  HWaddr 66:45:74:19:9A:DE  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan1     Link encap:Ethernet  HWaddr 00:00:F6:00:78:B1  
          inet addr:172.22.15.70  Bcast:172.22.15.255  Mask:255.255.254.0
          inet6 addr: fe80::2c09:ae26:7ac9:3cd3/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:42345 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3872 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5799484 (5.5 MiB)  TX bytes:657109 (641.7 KiB)

this is ifconfig after a reboot:

root@485b1c6:~# ifconfig
    [... output cut ....]
wlan0     Link encap:Ethernet  HWaddr 00:00:F6:00:78:B1  
          inet addr:172.22.15.70  Bcast:172.22.15.255  Mask:255.255.254.0
          inet6 addr: fe80::b5f7:dd97:a5d7:d6ae/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8704 errors:0 dropped:0 overruns:0 frame:0
          TX packets:650 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1472943 (1.4 MiB)  TX bytes:102376 (99.9 KiB)

wlan1     Link encap:Ethernet  HWaddr 2E:41:F6:19:EB:40  
          UP BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Do you have any clue on how to do that?
thanks!
Marco

A while ago we looked into predictable interface naming for Raspberry Pi devices and we found out that it was not working very well with the Raspberry kernel.

I can recommend adding UDEV rules instead. Here is an example with renaming according to driver name used:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="brcmfmac", NAME="wint"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="ath9k_htc", NAME="wext"

UDEV rules are quite configurable and you may configure them according to your specific needs. They have a bit of steep learning curve unfortunately.

On balenaOS additional UDEV rules could be added through config.json: https://github.com/balena-os/meta-balena#udevrules

udevadm info --attribute-walk -p <SYSFSPATH> is a useful command for building up custom rules.

Please let us know if you have any questions.

1 Like

We implemented udev rules in our product and it is working great. When we were working on this, I did run into problems using names of the form wlan*. Even with udev rules, naming was not consistent. From the research I was able to do that’s because of a problem within the kernel. We ended up using wireless* for our stuff and have not had any problems once we moved away from wlan* interface names.

1 Like

Thanks for sharing @ejohnso49!

Ok, sorry to reply so late. so this is what I have reached so far:

  • i’ve used UDEV rules to give predictable names and using “wiseless*” names.
  • using @ejohnso49 approach actually the system looks more stable and “wireless0” always get paired with the internal wifi network card

However, now I’m facing the issue that all the cards get connected with the wifi network, and I don’t know how to tell NetworkManager to use only 1 specific device.
I’m also using wifi-connect’s container and I’ve set the internal wifi as default wifi to be used.

Thanks

You can prevent network manager from setting up wifi connections with
nmcli dev set NAME_OF_INTERFACE managed no

from within a container with network-manager installed see here.

I just unmange all the devices I don’t want network manager to mess with.

You can also use udev rules to make the usb dongle named something different than the onboard wifi.
You can even maintain %.

What is the make and model of the dongles you are using? I would love to test them.

-Thomas

1 Like