SOLVED: Re: accessing guest wireless networks
- Reply: Bob Proulx : "Re: SOLVED: Re: accessing guest wireless networks"
- In reply to: Andrew Gould : "Re: accessing guest wireless networks"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 02 Nov 2022 14:19:50 UTC
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.
Andrew
On Sat, Oct 29, 2022 at 4:05 PM Andrew Gould <andrewlylegould@gmail.com>
wrote:
>
>
> On Fri, Oct 28, 2022 at 12:22 PM Bob Proulx <bob@proulx.com> wrote:
>
>> Andrew Gould wrote:
>> > I have wpa_supplicant.conf configured to successfully access two
>> different
>> > home networks; but I can’t seem to figure out how to access guest
>> networks
>> > (is this the right term?) at places like Starbucks.
>> >
>> > network={
>> > ssid=“Starbucks WiFi”
>> ^ ^
>> ! !
>> > bssid=any
>> > key_mgmt=NONE
>> > scan_ssid=1
>> > priority=4
>> > }
>> >
>> > What else do I need?
>>
>> Those quotation marks are UTF-8 and not ASCII. Change those to the
>> traditional ASCII double quotes.
>>
>> I have only exactly this following in my wpa_supplicant.conf file and
>> this works for me.
>>
>> network={
>> ssid="Starbucks WiFi"
>> key_mgmt=NONE
>> }
>>
>> Note that with the Starbucks captured portal one must open a web page
>> in a compatible browser, allow it to be attacked with a MITM attack,
>> land on the Starbucks authentication page, and click through their
>> agreement. I am using Firefox and Firefox automatically recognizes
>> many captured portals and will emit a dialog line with a button just
>> above the page body content. Clicking that Firefox dialog button
>> works for me.
>>
>> This captured portal access can be problematic if using a local DNSSEC
>> validating nameserver such as unbound because captured portals like
>> Starbucks are MITM attacks for which DNSSEC is designed to stop.
>>
>> Also DNS over HTTP DoH being enabled in the browser may prevent the
>> captured portal from the MITM attack needed to open the portal.
>>
>> Before attempting to authenticate with the captured portal disable DoH
>> in the web browser and stop any local caching nameserver. Inspect
>> /etc/resolv.conf to ensure that the Starbucks captured portal DHCP
>> assigned nameservers are in use and NOT "safe" ones like 8.8.8.8 or
>> any of the other similar ones. Since you must to allow yourself to be
>> DNS attacked in order to gain access through the router you need to
>> use the DHCP provided nameservers. Attempting to go to any URL name
>> the DNS will resolve to a captured portal router which will issue an
>> http redirect causing the browser to visit the portal page. That's
>> the MITM that must be allowed to gain access.
>>
>> Then after completing the captured portal handshake and getting on the
>> network don't forget to return to a normal network configuration.
>> Start up unbound if using unbound. Enable DoH in the web browser
>> again if using DoH.
>>
>> Background reference.
>>
>> https://en.wikipedia.org/wiki/Captive_portal
>>
>> Bob
>>
>> Thank you for the help. 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.
>
> 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 . Restarting Firefox and trying to access the internet failed.
> Redirection to a login webpage did not occur.
>
> Andrew
>
>
>
>