0

Is it possible to scan for networks and discern which ones are captive portals WITHOUT connecting to it? I'm currently using

wpa_cli -i wlan1 scan
wpa_cli -i wlan1 scan_result

To get a list of available networks, and I know there are ways to check if we are in a walled-garden once we connect to it, but I was wondering if it is even possible to filter out captive portals before connecting to them. Probably not? But just want to see if I'm missing any possibilities. Thanks!

5
  • 1
    try pinging 8.8.8.8 ... see who responds
    – jsotola
    Nov 5 '20 at 22:45
  • @jsotola You'd have to connect to the wireless network first. Nov 6 '20 at 10:36
  • d'oh ... lol .... @badatmath, you would have to sniff existing traffic
    – jsotola
    Nov 6 '20 at 17:17
  • @jsotola But that would require some one new connects to the wifi while you are sniffing because only when sniffing the first redirect you can identify the network as redirect to the portal. Additionally the network uses the new WPA3 protected public network you can't sniff it's data.
    – Robert
    Nov 6 '20 at 23:38
  • @Robert that is absolutely correct
    – jsotola
    Nov 7 '20 at 0:36
0

No, you need to connect to the network before. Otherwise you can't expect the network to allow you to communicate through it. For detecting a captive portal you (the client device) need to access a domain within the network, which collides with the above. Detecting a captive portal in principle works as follows:

  1. Connect to network

  2. Try to open a specific webpage (this website is specific for a manufacturer, e.g. apple devices try to connect to http://captive.apple.com)

  3. If

    a) no response or an error is received, the device assumes that there is no internet connection

    b) the expected response is received (Success in case of apple), the device assumes that it has internet connection

    c) a response is received which is different from what the device expected, it opens the response in a captive portal

The most important thing to make clear is, that it's the device itself that opens the captive portal after using the above heuristic. All the network can do to force the captive portal on the client device is to provide it with a response that the device did not expect, but it's up to the device to "detect" the captive portal. This whole captive portal story is just a hacky technique, rather than a defined standard.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.