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.

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.

Thanks for sharing @ejohnso49!