I want to create an access point with an USB Wi-Fi adapter. But I want the naming to be consistent, like extAP. So I’ve created the following udev rule:
I’ve checked the idVendor and idProduct, and they seem right.
I’ve added these rules at runtime to the container at location /lib/udev/rules.d/90-usb-net-ap.rules. But it doesn’t work. I don’t want to add them to the config.json file, because it’s a new feature to the device, so it has to work with an update. When the rule is “installed”, I run udevadm control --reload-rules && udevadm trigger, but it doesn’t work. Even after unplug and replugging the USB, the naming is still wlp0s21f0u4.
Also, when I execute ifconfig inside the container, I only see the ethernet devices (eth0 & eth1). Is this normal behaviour? And I’d like to set the AP information using dbus-native for NodeJS.
Some background information: Device: UP Squared OS Version: 2.39.0 Supervisor version: 10.1.5 Docker image: balenalib/up-board-node:8 (OS: Debian GNU/Linux 10 (buster))
Hey @bversluijs how are you trying to create the access point? Is the name for the access point itself? Or the USB wifi adapter? What wifi adapter are you using exactly?
The network on our devices are managed by NetworkManager, so I would think that’s what you have to interface with mainly, not udev. The network device naming should be udev territory, but I think you should not need that for the access point naming (if that’s what you mean). Also, that name is a predictable name, i guess with some extra info in this blogpost
The wifi-connect project also does this sort of access point creation, that might help a bit to help with your original use case (if the access point is supposed to be the fixed name).
If you have a bit more details, we should be able to advise more as well.
Maybe I didn’t explain it correctly. The first step is to get a predictable name for my Wi-Fi adapter using udev. So naming the USB wifi adapter, not the name for the access point itself. So when I do ifconfig, I want to see extAP instead of wlp0s21f0u4. So it’s easier to communicatie with NetworkManager to setup everything.
Creating the access point is done by NetworkManager via dbus. But I don’t have questions about that (for now). So the first thing is naming the network device.
The Wi-Fi adapter I’m using is the TP-LINK TL-WN725N(EU) V3.0
Thanks for the extra context, @bversluijs, I think figured it out with a dongle that I had at hand, and some hints from this StackExchange anwer. I think in your case the change needs to be switching ATTR to ATTRS, thus:
would work. It is because ATTRS matches all the parent devices for a node as well, and that’s what is matched: a net device, that is added, where the parent has this vendor and product IDs. Can also find some more info in “Writing udev rules”.
The second part is, that in my experience with these rules, just udevadm control --reload-rules && udevadm trigger is not enough to trigger an add event, so when you are testing, you need to actually unplug-replug the device physically for it to take effect. Or reboot the device.
The only thing I’n concerned about, is if I add that udev rule to a container, is it applied to the host OS as well? So for NetworkManager? (Maybe that’s not necessary anymore, I’ve created a new thread about that)
And when I do ifconfig in the container, I only see the ethernet connections, not the wifi connections. Is that a problem, or is that as expected?
No, if your udev rules are ran only by the daemon running in your container, the hostOS will be unaffected by them. If you want udev rules to be applied to the hostOS, you would need to put them in your config.json (found in your boot partition), details can be found here: https://github.com/balena-os/meta-balena#udevrules).
Thanks for your fast response. If the udev rules are only inside the container, then it isn’t what I want to accomplish. But I’m using it now for development purposes.
I’ve added the following rules to /lib/udev/rules.d/:
But the /tmp/test isn’t created. I’ve made the udev rule as simple as possible, but it still doesn’t work, which is really weird. The udev monitor sees all actions…
Scrap that
I forgot to add ENV UDEV=1 and now it seems to be working.
But I can’t seem to get extAP to show up in ifconfig or somewhere else. I’ve configured it in /etc/network/interfaces, but it doesn’t seem to work.
I notice that you are using the idVendor and idProduct that my colleague has used, just want to make sure that these are right for your use case. Are they correct?
Because the chipset doesn’t work with Access Point mode, it’s a dead-end for now. At a given moment the command ran with the udev rule. But naming the device didn’t work, also with network_mode: host.
At a given moment the command ran with the udev rule. But naming the device didn’t work, also with network_mode: host .
I take note that you wished to avoid adding udev rules to config.json because “it has to work with an update”. But as Theodor had pointed out, in order for the udev rules to be applied to the hostOS, you would need to put them in the config.json file (found in the boot partition), with the syntax documented on this page: GitHub - balena-os/meta-balena: A collection of Yocto layers used to build balenaOS images
Yeah, I read that, but I haven’t figured out yet how to update the config.json file at runtime / from within a container. I also didn’t have the time yet to figure this out.
After some googling, I found different websites, like this one, that are saying that it’s possible to use the dongle in AP mode. The Wi-Fi dongle is the TP-LINK TL-WN725N v3 with chipset RTL8188EUS.
I found a post on the Raspberry Pi forum saying that the drivers need to be updated for that chipset in order for it to work. But I don’t know if NetworkManager supports that driver update. But I can’t seem to find that post at the moment.
