Hi,
We are building a device that a user will connect it to available wifi.
i saw the wifi-connect project, but one of our use cases is that the user will also be able to connect the device in a hotel, where there is a captive form when connecting to the wifi.
how do we by pass that? how can i enable the user to put the right captive for the raspberry pi ? (or any other HW)
and another question, related, are we able to provide a hotspot and simultaneously be connected using the same wifi to the network?
Hi
Right now this is not easily possible - see an in-depth discussion on this issue on GitHub here - https://github.com/balena-io/wifi-connect/issues/51
The gist of it is (as you have figured already) that we would need to have simultaneous station + AP mode, which is an open issue in NetworkManager which we depend on.
Thanks for your reply.
Regarding the captive, did you guys encounter a solution for that? (i saw in the thread you sent spoofing and than proxing might help), but did you get something to work, with a bypass?
Regarding the hotspot+ap - will configuration with hotspad might work? Without using network manager at all. (Or the whole networking of Balena will disable that since its working with Network manager)
We have not worked on bypassing hotel’s captive portals in wifi-connect and probably won’t work on this in the future as it is a really complex task.
As for using simultaneous client+AP mode, it is possible with NetworkManager managing the client interface and hostapd managing the AP virtual interface, but it is bit tricky. I would not recommend not using NetworkManager for the client interface as managing this from a container may lead to connectivity loss, e.g. when the container is restarted or there is an application or other problem with it.
The solution with NetworkManager is to add an udev rule to the OS - https://github.com/balena-os/meta-balena#udevrules. The udev rule needs to tell NetworkManager not to manage the AP interface when it is created. It should be similar to this: ACTION=="add", SUBSYSTEM=="net", KERNEL=="vap0", ENV{NM_UNMANAGED}="1".
Then from your container you need to run: iw dev wlan0 interface add vap0 type __ap
That will create the virtual AP interface which you may use with hostapd. I have tried that before and it worked. You may need to tweak the commands if necessary as I am writing those down from memory. You may also need to bring the wlan0 interface down if necessary - you can experiment and see what will work.
Alternatively you may always use a WiFi dongle for the AP interface and most of our users who need a secondary AP interface use that instead.
Our balenaFin board provides a secondary uap0 interface, which is for this purpose and the AP interface there could be even managed from NetworkManager.
Hi, i’ve tried as @majorz suggested.
its partly working, i’ve googled a lot, maybe you can help here from your experience.
i can see the hotspot created (i’ve created the hotspot using hostapd), but i cant login, it always returns wrong password although its the right one.
Few things i’m wondering:
regarding dnsmasq, should i turn off dns in network manager? what will be the effect on balena OS if i do that?
when you say bring down wlan0, you mean only when setup, right? (it misses the point of having an AP and wireless connection)
and another question, related, are we able to provide a hotspot and simultaneously be connected using the same wifi to the network?
I don’t know if this is advisable, or possible, but it would be done via controlling NetworkManager.
Your setup is super confusing to me; are you trying to make a balenaOS device which uses wifi-connect to create an AP for the user to connect to, and configure the device to use a hotel wifi as it’s uplink. Then, to remain in AP mode and allow the user’s mobile device to connect to it, and pass it through?
i mixed two questions in 1 post and that is a mistake.
the more important scenario:
our device which runs balena os, needs both to serve as a hotspot and be able to connect to a wifi network that has internet.
that way, our device could talk directly to the mobile app with hotspot, while also be connected to the internet.
thats what i’m trying to achieve with @majorz answer, he said this is not possible solely from network manager.
I think that’s a fair statement; using the 1 interface to do both isn’t something that I have experience with and if @majorz says it’s not possible in network manager then I would say it’s not a path to go down.
Is there any reason not to add a secondary interface and use that for the clients, and reserve the internal interface for backhaul?
well, since we have a board already, it will be adding another module, and i’m not sure what will be the impact in terms of RF reception when working with the device.
Hi Daniel, I got a ping from a teammate about your follow up.
regarding dnsmasq, should i turn off dns in network manager? what will be the effect on balena OS if i do that?
You do not have to stop dnsmasq running on the host OS. The one that has to be setup in the container will not interfere with the one running on the host OS. They serve different purposes as well.
when you say bring down wlan0, you mean only when setup, right? (it misses the point of having an AP and wireless connection)
Right, however that may not be needed. I just tried adding the secondary __ap interface here and it did not borked my main connection.
What I advise about the other problem you described is make sure you first launch hostapd without any password requirements. Have it all running with an open network (passwordless) model first. Enabling debug mode for hostapd and the device you are connecting to it could be helpful as well. E.g. I use a Linux laptop and if I cannot connect to a network I can diagnose it easier if I enable NetworkManager and wpa_supplicant debug logging - Projects/NetworkManager/Debugging - GNOME Wiki!
As a side note: we may release a modified NetworkManager soon in a next OS release which will support internally the dual STA+AP mode. I have been looking into this for the past week, trying to patch NetworkManager, but it is not still clear whether this will work. Currently chances are 80% it will work. If I am successful we should release that in a month or two, but I cannot promise anything for now as I do not have anything working yet. Fingers crossed.
Please let me know if you have any further questions. You may also ask for my direct attention, so that we make sure it gets answered by me directly.
thank you, will try without any password first.
we are currently working in the staging enviorment, so i’m ready to do some QA to the NetworkManager feature
Hi Daniel, I made nice progress with this. Let me double check this today on a RPi since I only worked on newer Linux hw/sw. At the end I managed to make it work without any NetworkManager modifications, so if it is working on the RPi you can use it even today.
Thanks,
Zahari
Sorry for the delay on this. Unfortunately the method I used to make this work on my laptop did not work for the RPi and I will need to debug it more I will probably resume this early next week and will let you know how that goes.
However you may try it on your device just in case:
Run from the host OS or container with host networking: iw dev wlan0 interface add vap0 type __ap addr 12:34:56:78:ab:cd
The difference between this and the command I posted in message above is specifying the MAC address.
@majorz - looks like its working, thank you for your help.
i would still need some advice on two issues:
After restart, the vap0 interface is gone and i need to add it every time, how do i make this to be saved?
2.How to automate this process for our manufacture process, will it be possible to flash an image that already contains this property?
Add this to your application and run it each time your container is started, e.g. at the beginning of your start script. This is the easiest approach.
Make this an udev rule. The command can be executed with RUN+="...". Not sure what the complete rule should be, but I imagine it something similar to this:
ACTION=="add", SUBSYSTEM=="net", ENV{INTERFACE}=="wlan0", RUN+="iw dev wlan0 interface add vap0 type __ap addr 12:34:56:78:ab:cd"
The udev rule will go as usual inside the config.json, thus the OS itself does not need to be modified.
I will probably resume this early next week and will let you know how that goes.