davesteele
commented
3 years ago That redirect is in place, but it only works for http requests, not https.
Closed Adrianni closed 3 years ago
davesteele
commented
3 years ago That redirect is in place, but it only works for http requests, not https.
Adrianni
commented
3 years ago Thanks for your fast reply. Ok. So then I am experiencing some issued with comitup. I just tried with another unit (iPad) as well. Did not redirect, even if I forced http (not s).
The main issue is actually that the captive portal does not seem to work. I have never had problems with connecting to new wifi and entering captive portal before.
davesteele
commented
3 years ago Are you using the Comitup image, or did you install the package? The image is preferred.
If you installed the package, did you consider the install issues from the Wiki?
Did you check the logs per 'systemctl status comitup', or /var/log/comitup.log or /var/log/comitup-web.log?
For your issue, the things to check are the status of dnsmasq and comitup-web (though, from what you say, comitup-web looks to be running OK). Make sure the active dnsmasq is the one using dns-hotspot.conf.
I just tested the latest image (https://steele.debian.net/comitup/image_2021-02-11b-Comitup-lite.zip, running Comitup 1.15-1) with my Android phone. The captive portal worked fine.
Adrianni
commented
3 years ago Thank you. This solved the problem.
The version available from apt-get was out of date (v. 1.3). The newer version 1.15 fixed the issue with the captive portal.
Hey Dave,
Awesome project!
I'm experiencing some issues with the captive portal and my android phone. Google chrome is not supporting the .local url, and i have to use the ip adress http://10.41.0.1/. Would it be possible to enable a redirect of all url into this ip-adress while connected to the hotspot? That would mean that if i for example try to visit any website, i will end up to the correct ip-address. That would solve this issue for many users i guess.
Again, great work!
Adrian