Hi Tyson,

thanks for opening this. I have not tried enabling the hotspot to work as a captive portal, so there might be many things that don't work quite right.

The issue you're seeing here is the downloaded UI being unable to establish a WebSocket connection (which it uses to communicate back and forth) to the server on the speaker. The UI tries to open the connection to the same host as the webpage is served from, using the window.location.host expression, so a wild guess is that somehow the host reported is not correct, but hard to say without debugging this in a JavaScript console.

The captive portal idea is great, however, and I think warrants further investigation.

Thanks, I will look into the host possibilities. Currently I set it to redirect to "/", but the hostname is e.g. captive.apple.com (handled by local dnsmasq routing all names to 10.0.0.1. I'll try redirecting explicitly to "http://10.0.0.1/" to see if it does better.

I believe that's the culprit.

Thanks for doing this and let me know how it goes.

Best,
Tuomas from Bang & Olufsen

Using

expressServer.get("*", function(req,res){
        res.redirect("http://10.0.0.1/");
});

Worked for me. I'm not sure the best flow for "after connection", currently I think the captive portal closes, but the setup is not complete, but loading http://hifiberry at that point works to complete the setup (option to rename "HifiBerry"). It would be great to have the captive portal save a link or somehow let the user know to open a browser to http://hifiberry, but at least it's a start. I'll create a PR.

I tried it a couple times, and it mostly works, but it seems like the connection state flaps a bit, periodically terminating the access point, but when reconnecting I'm able to get through the setup process eventually. Depending on the timing, the network connection options may not be given (it thinks it is connected sometimes before I've entered wifi creds?), but I'm able to finish setup, then go back to network and configure wifi.
I will attach logs from beocreate2 from one of these runs, in case there is some way to make the connection state checking more stable during the captive portal.
Note that this is with a hifiberryos build from 25-01-2021 (hifiberryos-20210125-pi3), in case there is any difference with latest released version (hifiberryos-20201213-pi3).
logs.txt

Thanks Tyson. I will have to try this out before merging anything to evaluate the user experience. Currently I'm not inclined to introduce changes that require the user to jump from one browser to another when setting up their product. Once the user enters the setup UI, it should continue in a seamless flow all the way to the end. This is the upside of operating in a regular browser and not the captive portal login screen – it won't close from beneath us by itself.

Best,
Tuomas from Bang & Olufsen

Agree. I'm wondering if the network detection is causing issues that lead to closing the window - I haven't looked closely at the code, but if there is a way to disable network detection during the setup process (if it doesn't already do that), or at least disable it if redirected during captive port, it may be helpful. I'll try to experiment with it a bit more as well, and add any changes to the PR that might help.

When the network has been added and the Next Step button is pressed, that's when the system will attempt connection to any configured network that's available (for first-time setup, the only network generally). I try to put the speaker on the network in as early phase as possible because there might potentially be steps that require that connection.