Re: SOLVED: Re: accessing guest wireless networks

Andrew Gould wrote:
> I changed the security settings in Firefox so it wouldn't block
> popups; but I didn't know what else to change.  I'm not running any
> DNS services, and I'm using the standard firefox pkg for FreeBSD
> 13.1.  I did the OS installation last week.

You should not need to unblock popups.  I have them blocked.  Firefox
captured portal detection works.

Firefox recognizes that a captured portal login is needed by
attempting contact and detecting the failure and in that event will
produce a "button" that is not a popup but a bit of Firefox control
bar below the main location bar area.

I verified that it was okay to leave Firefox's network setting for DoH
enabled.  It did not affect the captured portal auth detection.

The only requirement was that I had to use the DHCP server's
nameservers.  But with that then I was able to auth through the login
of the captured portal okay.  I was successful, with some hacking, on
FreeBSD 13.1 on a Thinkpad x201 with the builtin Centrino N 6200
wireless device.

I actually tried to verify all of this for myself again before I
posted this response.  And discovered what seems to be a problem in
FreeBSD 13.1 with wpa_supplicant and dhclient interaction.  I'll avoid
discussing that here in this thread since it seems like a separate
issue.  But something seems broken for me now.  I had to hack around
it to perform this above test.

> After I checked everything, I restarted netif.  The output showed the
> correct ssid and status of associated.  However, it also showed inet
> 0.0.0.0 .

That 0.0.0.0 shows it has not successfully DHCP'd an address yet.
Some DHCP servers are slow responding.  Pause for a moment and check
again.  Repeat for up to two minutes.  I will frequently tail the
system log with some popcorn and watch the show.  Then I can see the
association and the DHCP succeed or fail.

    tail -F /var/log/messages

> Replacing "WPA DHCP" with "SYNCDHCP" (please excuse the UTF-8 characters -
> I'm typing on an iphone) in rc.conf did the trick.  I just have to add WPA
> back in to use the home networks.

Ah...  So in this case the problem was mostly due to slow DHCP server
responses causing things not to be ready yet.  And changing to
synchronous DHCP caused it to wait and therefore it was ready when you
interacted with it.  Gotcha.

However for me that SYNCDHCP would be a problem.  Because success of
it depends upon having networking up, available, and online.  And if I
boot my mobile device laptop away from an accessible network then it
can't successfully DHCP.  But with SYNCDHCP I think it will continue
to retry.  And I won't be able to log into my system until it gets
past that point.  With DHCP at least there will be a timeout after a
couple of minutes and then I can log in afterward.

Also the need to edit the file to add or remove "WPA" seems less than
optimal to say the least.  The documentation (such as in the wifimgr
man page) calls for it to be there.  But now it seems there is a
problem for open Access Points which blocks dhclient if it is.  I have
that same problem too.  I think it is a bug.

Things are definitely not very nice and not happy in WiFi land. :-(

Bob