Reliable and updatable access point

Product support balenaOS
91

No problem!

When my wlan0 is initiated as an access point (because it can’t connect to a Wi-Fi network), it also starts a dnsmasq instance in the background (spawn in Node.js) with the following config parameters (credits to wifi-connect)

dnsmasq \
      --address=/#/10.42.0.1 \
      --dhcp-range=10.42.0.1,10.42.0.254 \
      --dhcp-option=option:router,10.42.0.1 \
      --interface=wlan0 \
      --keep-in-foreground \
      --bind-interfaces \
      --except-interface=lo \
      --conf-file \
      --no-hosts \
      --log-facility=-

Change device, gateway, route and dhcp according to your needs.

But what this does is the following:
It routes everything to 10.42.0.1. You can’t forward it to a port, because when a user does an HTTP request, it uses port 80, so DNSMASQ routes it to 10.42.0.1:80. HTTPS is the same, it routes to 10.42.0.1:443. So you can’t change the port, only the address (I’d recommend to just use this ports for your web application, because it’s the standard).

It also only binds to wlan0, so your ethernet can still be connected to the internet for example.
Because everything routes to 10.42.0.1, most devices will show a ‘hotspot’ interface, because it can’t reach it’s hotspot check (e.g. Apple checks for http://captive.apple.com/hotspot-detect.html).

When wlan0 is connected to a Wi-Fi client, or is trying to connect, my app kills the dnsmasq instance and tries to connect via NetworkManager. When it fails, it sets up the AP again and thus dnsmasq. But when it’s successful, it stays a Wi-Fi client.

Good to know
Most HTTPS websites set a HSTS-header. This means that your browser will “always” know, that when connecting to, for example, https://google.com, it uses HTTPS with a (valid) certificate. So when you’re connected to the AP, and you’re trying to go to https://google.com (with your webserver listening on port 443), it’ll give an HTTPS error, because the certificate is invalid (it’s not the Google certificate it expected).

We’re working around that by using a subdomain (local.domain.com) which doesn’t use HTTPS but just HTTP. That’ll work because the HSTS-header is not set for that domain. So we instruct users to connect to the AP, and if the hotspot interface doesn’t come up, go to local.domain.com, and it’ll “redirect” them to 10.42.0.1.

Hope you get the idea, if you’ve any other questions, please ask them here!
I’ve got this working by using Google and open-source projects, so I’m happy to share some knowledge!

2 Likes