Option to bypass network connectivity check

[airdrummingfool]

tl;dr: It appears that wifi-connect does some level of connectivity checking, which I want to bypass so I can trigger the captive portal on-demand, regardless of existing connectivity.

I'm using a modified version of the start.sh script from balenablocks/wifi-connect. The script does connectivity checking, and once connectivity is lost, it launches the wifi-connect process.

In order to test this, I intentionally "broke" the connectivity check, so that it would launch wifi-connect as if there was no connection (but there was an existing LAN connection so I could watch the log output). The log output indicated that an AP was created, but it never showed up on my devices. After some debugging, I figured out that the wifi-connect program runs its own connectivity check, and even if it says "Access Point created", it doesn't actually create the AP until there is no connection. This defeats the purpose of my custom connectivity checking, and bypasses my logic for when to launch the config AP.

This might be an issue that mostly comes up in testing, but this could be a problem anytime the custom connectivity check logic doesn't match up with what wifi-connect decides is "connected". At the very least, I think that documentation/logging could be improved to explain that the AP isn't actually launched until connectivity is lost.

Log output when no AP is created:

Deleting already created by WiFi Connect access point connection profile: "Configure WiFi"
WiFi device: wlan0
Access points: ["Configure WiFi"]
Starting access point...
Access point 'Configure WiFi' created
Starting HTTP server on 192.168.42.1:80

[maggie44]

I think my experience has been the opposite. I use the device over LAN with an ethernet cable plugged in, but start Wi-Fi Connect and often connect to the AP (while still on ethernet with another device) for testing various features during development.

Sometimes devices won't see access points first time, disabling and re-enabling wi-fi on the device trying to access it from may help. You also won't be able to access Wi-Fi connect portal via the ethernet connection, only via wi-fi.

I use a Raspberry PI 4, but not the Balena Blocks version, I use the setup from this repo. Not sure if that would make a difference.

[airdrummingfool]

@maggie0002 interesting, thanks for sharing your experience. Toggling wifi on the mobile device hasn't made a difference, and the hotspot shows up very reliably when wifi-connect doesn't have a working internet connection.

I've been investigating this a bit, and the behavior I describe is still occurring. However, I haven't been able to find a connectivity check in the rust code, so I think my initial assumption (that there is a check) is incorrect.

There's still something weird going on, because I realized that the log line that says Access points: ["Configure WiFi"] is just listing my wifi-connect portal SSID, when it should be listing the other SSIDs around me (there are many). This is repeatable any time I connect the wifi-connect host to the internet and then start wifi-connect. Even more interestingly, I realized it is actually showing the previously-configured wifi SSID from the last run of wifi-connect. E.g. if I run it with --portal-ssid MySSID1 and then restart it with --portal-ssid MySSID2, it will show Access points: ["MySSID1"] in the log.

If I disconnect my LAN cable (so that there's no internet connection to the wifi-connect host), wifi-connect successfully lists the many SSIDs around me instead of the previously-configured portal SSID.

[airdrummingfool]

I was able to bypass the bug described in my previous comment (where the only AP listed is the SSID from the previous wifi-connect run) by using nmcli to delete the existing connection before calling wifi-connect, e.g.

nmcli connection delete id "$PORTAL_SSID" && sleep 5 # Give deletion time to propagate
./wifi-connect --portal-ssid "$PORTAL_SSID"

I noticed on my Pi 4 that if I didn't add a sleep before the subsequent wifi-connect call, the bug would still occur.

---

I should note that this still doesn't fix the original bug in the issue description; even with this workaround, $PORTAL_SSID is not broadcast if the Pi has an existing internet connection (e.g. ethernet) when wifi-connect is launched. If I disconnect the LAN cable from my Pi and then start wifi-connect, the SSID is broadcast and everything works as expected.