WiFi Connect - Community Maintainers

It has been proposed that WiFi Connect will benefit from additional community input for development and maintenance (see posts below from Balena staff). Here are a few thoughts after having been working with WiFi Connect for a while, and having gone through the issues on the GitHub repo. Hoping to get some input to evolve the ideas and then see who else may be able to contribute.

Note each number in the notes below relates to a numbered issue and associated GitHub Issue below.


I think it’s safe to say that the issue where the list of available access points is empty is the biggest issue. There appears to have been quite a bit of investigation already (see some of the conversations in issues below), which point towards RequestScan as a potential solution. Would need someone with Rust background to explore this.

A related pull request for a refresh button also looks promising. It would require someone with Rust background to make a new endpoint available (/refresh for example) which would update the list. An issue has been raised that the AP cannot be running while this is done, which would subsequently kick the user off the device, and require reconnecting again to be able to see the refreshed list. This isn’t ideal, but would be a far better solution than telling someone to power cycle their device repeatedly until the list appears. It would be easy enough to add in a notification informing the user what is happening, and could also explore having the portal UI poll the access point and trigger a refresh of the page automatically once the user has reconnected to the device (shouldn’t be an issue as the web-UI is browser based).

A more complex alternative would either 1. exploring multiple channels so the user can stay connected while a second channel tries to make the connection, although my understanding is the amount of Wi-Fi chips on devices that can support his is limited (would also be wary about making the app any more complex than it already is, as it makes support and maintenance even harder); or 2, if someone can find a way to rescan while the access point is still running (Add a refresh networks button by sradevski · Pull Request #354 · balena-os/wifi-connect · GitHub).

A combination of exploring the RequestScan fix, along with a refresh button (that requires the user to reconnect to wi-fi afterwards) would be a big step forward.

2, 3 & 4:

Being able to forget the network currently connected to is a real pain point (At the moment, once you successfully connect to a network, you then get reconnected to that network every time the device boots). There are a bunch of script solutions posed, Python and Shell, but they can be temperamental and generate a lot of support questions. If the app allows you to connect, it seems fair to have a feature built in that allows you to disconnect again.

Unfortunately, it would require a bit of a rethink of how the app works. At the moment the app starts and creates an access point, then when the connection is established successfully the app exits. To be able to have a disconnect option, the app would have to stay running and listening for the request. I think this however, may well be a better workflow. The application, thanks to Rust, is very small and consumes very few resources, especially since someone did some work on the very clever Balena Blocks version that shares the firmware from the device (GitHub - balenablocks/wifi-connect: Easy WiFi setup for Linux devices from your mobile phone or laptop).

Building towards the Balena Blocks version being the default seems to make sense to me, it reduces the footprint and dependencies, and also resolves issue 2. which is a request for Alpine container support (at the moment it only runs on Debian image, which for Alpine users means having an extra image). Not having to deal with additional libraries (musl) should be advantageous for maintainace and support going forward. The app then running as a listening portal would allow the expansion of an API to add in some of the basic features, such as forgetting the wifi-connection (our apps could call the API via the other containers).

Would suggest then adding in a few endpoints:


/start-access-point (as a POST, able to include the current config strings such as --SSID --PORT etc.)




Hopefully self explanatory, but by having the option to stop and start the access point, we remove the need to have a large Debian container wrapper around the app. Without these endpoints, it is very hard to build more controls of the access point (i.e. enabling and disabling it through a settings panel), without having the Debian container and a custom listening port (I use a Flask instance) that listens just for stopping and starting the app. Which seems a little crazy considering that wifi-connect already has an API built into it listening for requests.

I would suggest also adding in an ‘—api’ flag for starting the app in the listening state. That way it is backwards compatible with how people were using it before, and those that want to leave it running and listening for commands can simply add the flag.

Being able to prevent the retry of connections when the wrong password is entered (number 4.) could also be resolved though an API, by checking the returned /status and using the /start and /stop endpoints as necessary. In addition to a —no-retry flag that would also help the workflow ( https://github.com/balena-os/wifi-connect/issues/283#issuecomment-485362893 ).


Multi-language support I think would be better thought of as an easy way to configure the UI. This should be simple enough, we could have all the text strings used in the UI stored in a config file and users can then adjust that config file so the messages display as they wish (whether it be in a different language or different wording). The config file could also control some basic colour themes and logos. This isn’t as significant a change as incorporating multi-language support, but would still massively improve the ability to customise. I can submit a pull request for this once there is more of an idea of what is going on with the UI from the other pending pull request (Add a refresh networks button by sradevski · Pull Request #354 · balena-os/wifi-connect · GitHub).


I think number 6 is probably already implemented, but the issue wasn’t closed?

7, 8 and 9

These have far fewer requests. I can see the value they add, but getting to them would all come down to how much time people are able to commit.

At one point I wondered if this was just going to become part of the Balena OS, but it often entails asking devices to do things they were not explicitly designed to do, so it is likely there will be bugs squashed and improvements made along the way. If it was integrated into the OS, it would require a significant update to devices, whereas keeping it as a small container like in the Balena Blocks example allows for more regular updates.

One of the biggest barriers from getting community support is the Rust language. A bunch of posts mention how they were going to submit pull requests but are not familiar enough with Rust. One user started a pull request, but couldn’t get around the Rust framework and ended up rebuilding the entire app in Python (wifi-connect python version · Issue #289 · balena-os/wifi-connect · GitHub). It would be a shame to not keep using Rust though, as it has so many benefits being self contained and using such a small footprint.

Hoping to hear ideas and thoughts.


  1. Sometimes list of available wifi-networks are unavailable




Related pull request

Feature requests

  1. Allow forgetting of connected network connection
  1. Support Alpine containers
  1. Prevent retry of correction when password is wrong
  1. Multi-language support
  1. Use only WPA2 for IOS compatibility (may already be implemented)
  1. Allow connections to hidden networks
  1. Support SSIDs with special characters
  1. Return signal strength (not a high priority, and not sure if NM returns this sort of info)

@dtischler @rbaynes


@majorz may be able to narrow a few of these down off the bat:

Do you know if this has been implemented already, or whether it’s still pending? Only WPA2 as security protocol for the portal AP · Issue #242 · balena-os/wifi-connect · GitHub

Did your investigation here still leave some hope that the RequestScan option as something we should persevere with or did something else come to light which means this needs a rethink? list of detected wifi access points is empty · Issue #206 · balena-os/wifi-connect · GitHub (also a more recent investigation here: Delay needed before wifi_device.get_access_points (on Raspberry Pi 3) · Issue #383 · balena-os/wifi-connect · GitHub

And of course any other thoughts.

Hi @Maggie,

Thanks for making this detailed list with issues, that will be very helpful.

Good news is that I resumed development on WiFi Connect very recently and I am making good progress with it. The first step was to make it compatible with newer Rust versions. Currently I am working on making it work on top of libnm instead of using D-Bus directly. This will make it much more easier to develop and maintain further. Once we release a new version that uses libnm we can start looking at those known issues you are mentioning here.

After that once we start with the fixes we can indeed start with looking at RequestScan. With libnm and the newer async architecture we will introduce in WiFi Connect it should be much easier to implement this properly.

The rescan button is indeed a non-trivial problem because NetworkManager does not allow scanning while the AP is running. We need to explore the reasons of why this is not allowed and also compare this behavior with setup based on hostapd or iwd. As an alternative I have been thinking about acquiring the scan information from the Linux kernel directly. If iw dev wlan0 scan is able to return results while NetworkManager has put the interface in AP mode then we can find a solution for this I think.

Let me follow up with the rest of your items next week so that we continue arranging the list of issues you prepared.


1 Like

This is great news, thanks for the update.

If a pull request containing the UI updates I mentioned would be of interest then let me know. I will wait to hear to avoid any unnecessary work or overlap.

@majorz Are you stilling working on WiFi Connect? I’m hoping to use it in an upcoming project.


Just to be clear, it is still working, the changes I mentioned were only suggested improvements and a few bug fixes.

I took a look at the Rust code and considered contributing, but it seemed like it was going to be difficult to get continued support. I ended up recreating it in Python instead: Alternative Wi-Fi Connect looking for testers