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 > > > >