This is my first time using balenaOS and this forum, so be gentle. I have an application that requires two wifi networks. One uses the internal wifi adapter, the second uses a wifi dongle. Typically, I would write udev rules to name them to a name that would identify them appropriately…wlan0 (internal) and wlan1 (external). However, balenaOS, when it comes up with the external wifi dongle plugged in, names the internal wifi wlan1 and the external wlan0. This seems counterintuitive, and the udev rules fail for some reason. Is there an option in the config.json that I can use that allows it to name the internal wlan0 and then allow the external to be named wlan1 ?
Hey @jprovan
Welcome to the forums!
How did you define these udev rules? Could you paste the rules themselves here for us please?
You can define udev rules in config.json, so I’m wondering if this what you’ve done, and if so that’s definitely something we should look at.
Sure. Thank you for responding so quickly. I did define them in config.json. Probably not the cleanest definition, but here it is:
"os":
{
"network" :
{
"wifi":
{
"randomMacAddressScan": false
}
},
"udevRules":
{
"72": "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", ATTR{address}==\"48:A4:93:05:3E:46\", ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\", NAME=\"wlan0\"",
"73": "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", ATTR{address}==\"1C:BF:CE:1A:39:D3\", ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\", NAME=\"wlan1\""
}
}
}
Those rules look like they should work, could you paste the output of nmcli d show when ran from the host OS please?
GENERAL.DEVICE: eth0
GENERAL.TYPE: ethernet
GENERAL.HWADDR: B8:27:EB:87:B7:C4
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: Wired connection 1
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1
WIRED-PROPERTIES.CARRIER: on
IP4.ADDRESS[1]: 172.16.0.156/24
IP4.GATEWAY: 172.16.0.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 172.16.0.1, mt = 100
IP4.ROUTE[2]: dst = 172.16.0.0/24, nh = 0.0.0.0, mt = 100
IP4.DNS[1]: 172.16.0.1
IP4.DOMAIN[1]: localdomain
IP6.ADDRESS[1]: fe80::8b74:2dac:13e5:60ff/64
IP6.GATEWAY: –
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 100
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256, table=255
GENERAL.DEVICE: supervisor0
GENERAL.TYPE: bridge
GENERAL.HWADDR: 02:42:FD:49:BF:E9
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: supervisor0
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/2
IP4.ADDRESS[1]: 10.114.104.1/25
IP4.GATEWAY: –
IP4.ROUTE[1]: dst = 10.114.104.0/25, nh = 0.0.0.0, mt = 0
IP6.GATEWAY: –
GENERAL.DEVICE: wlan0
GENERAL.TYPE: wifi
GENERAL.HWADDR: 1C:BF:CE:1A:39:D3
GENERAL.MTU: 1500
GENERAL.STATE: 30 (disconnected)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
GENERAL.DEVICE: wlan1
GENERAL.TYPE: wifi
GENERAL.HWADDR: 48:A4:93:05:3E:46
GENERAL.MTU: 1500
GENERAL.STATE: 30 (disconnected)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
GENERAL.DEVICE: balena0
GENERAL.TYPE: bridge
GENERAL.HWADDR: 02:42:C2:48:A7:81
GENERAL.MTU: 1500
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
IP4.ADDRESS[1]: 10.114.101.1/24
IP4.GATEWAY: –
IP4.ROUTE[1]: dst = 10.114.101.0/24, nh = 0.0.0.0, mt = 0
IP6.ADDRESS[1]: fe80::42:c2ff:fe48:a781/64
IP6.GATEWAY: –
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256, table=255
GENERAL.DEVICE: br-bf0e0bae36fe
GENERAL.TYPE: bridge
GENERAL.HWADDR: 02:42:84:A8:DF:8D
GENERAL.MTU: 1500
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
IP4.ADDRESS[1]: 172.17.0.1/16
IP4.GATEWAY: –
IP4.ROUTE[1]: dst = 172.17.0.0/16, nh = 0.0.0.0, mt = 0
IP6.GATEWAY: –
GENERAL.DEVICE: resin-dns
GENERAL.TYPE: bridge
GENERAL.HWADDR: 9A:40:10:14:CC:72
GENERAL.MTU: 1500
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
IP4.ADDRESS[1]: 10.114.102.1/24
IP4.GATEWAY: –
IP4.ROUTE[1]: dst = 10.114.102.0/24, nh = 0.0.0.0, mt = 0
IP6.ADDRESS[1]: fe80::9840:10ff:fe14:cc72/64
IP6.GATEWAY: –
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256, table=255
GENERAL.DEVICE: vethc8a3d69
GENERAL.TYPE: ethernet
GENERAL.HWADDR: 72:FC:67:98:2E:C8
GENERAL.MTU: 1500
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
WIRED-PROPERTIES.CARRIER: on
GENERAL.DEVICE: vethde0b1f2
GENERAL.TYPE: ethernet
GENERAL.HWADDR: 76:51:1C:5B:A6:E9
GENERAL.MTU: 1500
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
WIRED-PROPERTIES.CARRIER: on
GENERAL.DEVICE: lo
GENERAL.TYPE: loopback
GENERAL.HWADDR: 00:00:00:00:00:00
GENERAL.MTU: 65536
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
IP4.ADDRESS[1]: 127.0.0.1/8
IP4.GATEWAY: –
IP6.ADDRESS[1]: ::1/128
IP6.GATEWAY: –
GENERAL.DEVICE: resin-vpn
GENERAL.TYPE: tun
GENERAL.HWADDR: (unknown)
GENERAL.MTU: 1500
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: –
GENERAL.CON-PATH: –
IP4.ADDRESS[1]: 100.64.27.160/32
IP4.GATEWAY: –
IP4.ROUTE[1]: dst = 52.4.252.97/32, nh = 0.0.0.0, mt = 0
IP6.ADDRESS[1]: fe80::11d:4616:f6c:f78b/64
IP6.GATEWAY: –
IP6.ROUTE[1]: dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.ROUTE[2]: dst = fe80::/64, nh = ::, mt = 256
As you can see, they are inverted. It should be:
wlan0 Link encap:Ethernet HWaddr 48:A4:93:05:3E:46
wlan1 Link encap:Ethernet HWaddr 1C:BF:CE:1A:39:D3
If I boot the system without the external wifi dongle in place, then hotplug it after the boot, everything is correct.
I’m going to pass this on to one of the OS engineers as to me those probably should work. They should be able to provide some insight within the next day.
OK, thank you.
Hey @jprovan ,
Just an idea. I had a lot of trouble renaming things to wlanX in my application but everything instantly worked when I when to wconX or what ever. I think there is a conflict when you try and rename something to a name the kernal has already dispatched. Aka you might be able to do wlan0 --> wlan3 and wlan1 --> wlan4 but not swap them like your trying.
Also if they have different drivers a easy way to do this at scale is to match on driver not mac address.
Hope this helps,
-Thomas
Thank you, I will try the different names, but can you give me an example of a udev rule using the driver as the filter ?
Thank you for the hint @tacLog!
@jprovan, the following documentation page has an example of a DRIVER=="ide-disk" rule (which of course is not a wifi driver name, but shows the syntax). Does it not seem to work for you? Are you perhaps looking for the driver name? Let us know and we will go from there.
http://reactivated.net/writing_udev_rules.html#basic
Hey @jprovan,
“os”:{“udevRules”:{“12”:“SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", NAME="power"”}},
Is an example of a command that renames a usb ethernet adapter to “power”.
To find the driver information of a USB device I normally use:
lsusb -t
Which outputs something like this:
root@30cdf36:~# lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=, Driver=hub/3p, 480M
|__ Port 1: Dev 5, If 0, Class=, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=, Driver=r8152, 480M
Then google the driver to try and figure out which one goes to which, or unplug things until you have ruled as much as possible out. Note that this is a Rasberry pie 3 B+ so it has its onboard wifi showing up as r8152 I think. Other boards might have different stuff soldered on the USB bus.
This won’t work if they have the same driver, however. So, in that case, I have tried to develop a way to do it by port.
I ultimately gave up after an afternoon of trying. If you want to continue down this path, or @pdcastro or someone on the balena team here are my notes. I think this would work great for making udev rules universal enough to easily fit many different production designs, but I just can’t get it to work.
To see the rules you have in place on a device, ssh into host and run cd /etc/udev/rules.d/ and ls. This is useful for making sure your rules took. Sometimes they took an additional reboot for me.
So to make udev rules I used:
udevadm info --attribute-walk /sys/class/net/wlan0
You can also put a /dev/ path as well. This will allow you to see exactly what the kernel can match on in regards to a device. (You can also get the driver this way)
My favorite resource for further information is here.
My best atempt at matching by usb port was here:
"9":"SUBSYSTEM==\"net\", ACTION==\"add\", KERNELS==\"3-1.1:1.0\" DRIVERS==\"rt2800usb\", SYMLINK+=\"wCom\""
But it still didn’t work. 
I have this link saved about udev info. I think I had to install it into a container to get it to work? Not sure.
Good luck and please let me know if you ever get matching by USB port working!
-Thomas
1 Like
Thank you. You guys are great. I will give this a try over the weekend.
The only driver that I am seeing with “lsusb -t”, obviously, is the external USB wifi dongle driver. What is the name of the driver for the internal wifi ?
Hello. You can also match by MAC address. But generally the best way to see what you can match on is to get the udevadm info on the interface sysfs entry.
This gave me the names:
root@25c505b:~# readlink /sys/class/net/wlan0/device/driver
…/…/…/…/…/…/…/…/bus/usb/drivers/rt2800usb
root@25c505b:~# readlink /sys/class/net/wlan1/device/driver
…/…/…/…/…/…/…/…/bus/sdio/drivers/wlan_sdio
The issue that I am having is that wlan0, when the external is plugged in, is the rt2800usb driver. I want wlan0 to be the internal wifi, which is wlan_sdio.
So, I should be able to write the udev rules now. I will update this thread with my findings.
udevadm info --attribute-walk /sys/class/net/wlan0
^ this will give you all the attributes you can match on.
It did not work. I cannot rename the wifi adapters no matter what udev rule that I create. None of this would be problematic if balenaOS would remain consistent on it’s naming.
These images show the “iw dev” command with the external USB wifi dongle plugged in after the boot up on the left. The right shows the same system with the external wifi USB dongle plugged in prior to boot. Notice the MAC addresses. They are inverted.
From this I can only conclude that balenaOS is enumerating the USB dongles prior to enumerating it’s internal wifi dongle. How can I avoid this ?
Hi @jprovan -
can you let us take a look at the udev rules you used ?
Also have you made sure that the rules you provided were actually in place ?
There is a lot that can go wrong when adding udev rules…
Regards
Thomas