0

Starbucks indicates:

If the Starbucks WiFi page does not pop up, open a browser, navigate to a website, and you will be redirected to the WiFi landing page.

Observations

An attempt to assist a friend at Starbucks wifi was unsuccessful in resulting the SBUX landing page. Device = MS surface (Windows): ipconfig indicated that the access point assigned the device a LAN IP address and the gateway's IP address. Attempts to ping itself were successful, however, attempts to ping the gateway's LAN IP failed

The Surface device was assigned a LAN IP and gateway address (172.16.224.1). Attempts to point the web browser to http://172.16.224.1 failed and did not return the landing page.

A MacBook air was successfully connected to the Wifi and a similar ping test was performed:

 ping -c 1 172.16.224.1

returns:

PING 172.16.224.1 (172.16.224.1): 56 data bytes
92 bytes from 10.128.128.128: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 5b9e   0 0000  40  01 04e5 172.16.226.3  172.16.224.1 

It seems the network is setup to intentionally deny use of ping.

QUESTIONS

  1. Based on the observation can one conclude that the Surface's wifi layer is working correctly in the sense that there is no wifi setting on the Surface to be configured?

The MacBook would not return the landing page:

http://172.16.224.1
  1. From the surface, what commands can summon the SBUX landing page or enable the request?

  2. What additional troubleshooting could have been done from the Surface PC to diagnose an actionable solution?

1 Answer 1

1

There's no requirement that the default gateway be pingable, and there's no requirement for captive portal Wi-Fi networks to run the captive portal web server on the same IP address as the default gateway.

Captive portals work by doing a "man in the middle" (MitM) hijacking attack on unsecured HTTP requests in order to inject their own web content instead of letting you load the page you were trying to load.

The way to trigger the captive portal system is to issue any insecure HTTP request so it can be attacked and hijacked by the captive portal.

If you try to load a site that you've loaded securely (i.e. via HTTPS / TLS) before, then your browser may automatically try HTTPS again, so that attempt won't work for triggering the captive portal. Also, if you are running a browser extension like "HTTPS Everywhere" that tries to force all page loads to go over HTTPS, then that can get in the way of providing the captive portal with an insecure attackable hijackable connection attempt.

Try making an HTTP connection to httpforever.com, neverssl.com, or even some IP address that never even runs a web server, like 8.8.8.8. The point is to try to make an insecure HTTP attempt.

If you can't get the captive portal to trigger and still don't have internet connectivity, it may mean the captive portal system is either down, or it is confused about the state of your device (maybe its web server thinks it has authorized you, but its router disagrees and is blocking your traffic). If that happens, leaving the network for a little while (disconnecting the Wi-Fi) and then reconnecting will often clear up the bad state.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .