-->
Page 1 of 2

ESP8266 connect to WiFi Hotspot(user, pwd)

PostPosted: Mon Mar 30, 2015 4:24 pm
by lstynen
Connecting to AP is no problem, but my project requires connection to a hotspot, which requests username and password.
Can anyone help me with this please?

Re: ESP8266 connect to WiFi Hotspot(user, pwd)

PostPosted: Thu Apr 02, 2015 2:25 am
by mmcginty
The easiest way is to use Fiddler or something similar to see what the login request (or sequence of requests) looks like under the hood, and then replicate it in code. I wrote an app to query an AT&T Elevate (by Sierra Wireless), it's a Windows app but the principle is the same. In this case I had to request the home page, extract a token value from a hidden input in the response, build the form data block with credentials and that token, and post it to the hotspot. On successful authentication the hotspot writes a cookie, which I needed to acquire from the response header and send with subsequent requests.

Yours may be somewhat different, but still consider that the device is expecting users to interact with it via a web browser, therefore the task is to write code that makes it look like that's what's happening, at the network level.

Hope it helps,
Mark McGinty

Re: ESP8266 connect to WiFi Hotspot(user, pwd)

PostPosted: Fri Apr 03, 2015 4:09 pm
by lstynen
Thanks for sharing your experience, I'll test it out.

Re: ESP8266 connect to WiFi Hotspot(user, pwd)

PostPosted: Thu Apr 09, 2015 10:48 am
by mmcginty
You're welcome, happy to share, hope it helps.

Out of curiosity, which hotspot are you working with?

The data returned by the Elevate is pretty much a trip, for example, it supports the url /api/model.json, but the huge block of data it returns is actually only json-ish, it mixes 1 byte and 2 byte line terminations randomly, mixed tabs and groups of contiguous spaces (none of which makes it any more human-readable) and most importantly, none of the common libraries can parse it as json. I ended up cherry-picking part of what I needed out of the mess. The rest of what I needed was served separately as plain text (/about.txt) which was easier to deal with...

Looks sort of like the team that started the project got fired half way through the project... maybe just another part of AT&T's long legacy of insane data served via HTTP, the logical step to follow their decades of CSV malfeasance. :roll: