Connecting On A Public Network (no encryption)

So I’m at Grand Teton National Park for several months and there are a few public WiFi networks available for internet service.

Unfortunately, they all require clicking through a login button on an html webpage to gain access.

I’ve connected my phone by clicking through the web portal on my phone’s browser, but when I try to connect the :spark: to the network through the Tinker app, the :spark: powers on to cyan and goes to constant flashing green.

I’m guessing the Core can’t mouseclick the html just right, so… is there a way to connect it, or will I pretty much need to go to CLI and local cloud?

1 Like

As stated in the documentation, it is clearly mentioned that the core is unable to navigate login portals :).

2 Likes

Okey dokey http://docs.spark.io/connect/#connecting-your-core-smart-config-with-the-ti-app

I really don’t know enough to see if this will work, it was so easy to connect on my home network.

Is it only because the Tinker App (Java) is being used ? If an HTML version of login was available then problem would go away.

It is very easy to create inside the core firmware

Core requires secure ssl API java login (Tinker +)

Is it possible to login to to Spark API via Router using HTML ? I don’t know, I’m just asking ?

If a router can be setup to Auto-login to Spark API then would it not be possible to auto-login a portable device ?

It’s a different scenario here.

The core needs to get connected to Wifi, followed by internet. Wifi works OK but getting internet is not due to the login page :wink:

Hi @Elijah,

I’ve been thinking about a firmware modification that could automatically click through captive portals like that. Essentially you’d need an extra step before attempting to connect to the cloud, or perhaps as a recovery step if the cloud can’t be reached.

The core would need to make a request, note the IP of the captive portal server, and send a HTTP post / form submit to that server at the correct action point with the right form data (e.g. checkbox clicked), and then wait for the referral page to load, and then it might either need to restart, or wait for DHCP / DNS to clear back up. It’s not impossible, but it’d need to be tweaked on a case by case basis. :slight_smile:

Thanks,
David

Hi @Dave,

Since this sounds like it’ll be a prerequisite for getting my Core up while I’m here I’m going to go ahead and try to implement this for my case. If it works, I can share and hopefully it will be easy to point out where the case-by-case modifications should be made.

Cheers! :smile:

3 Likes

Hi @Elijah,

Very cool! Seems like the http client library could help, and I think you could use the “disable cloud” / “disable wifi” stuff to manage your connection / wait until you have the form sent before connecting to the cloud. Good luck, let us know if we can help!

Thanks,
David

1 Like

@Elijah, as I had a similar question a long time ago (Captive Portal) I would be interested in your success :wink:

One idea I had, but never tested, was to use a router with “Client Mode” where each request that comes from any device linked to this router gets passed to the WiFi AP with the router’s MAC/IP and so it should be possible to hook up the router to the captive portal by just initially clicking through the CP using another device (e. g. Laptop, Mobile Phone, Tablet, …) and so the router should provide its connection to the :spark: Core.

The only problem I had with this, is that I can’t find a router that does WiFi in both directions. The router I have does sport “Client Mode” and does work as outlined above, but only for devices hooked up to it via RJ45 and not via WiFi, since it does not support two SSIDs which it would need to (one SSID provided by the desired host AP and one it provides to its own clients like the Core).
It would be great if anybody knew a device doing this :wink:

In my special case, it’d not only be a matter of checking a checkbox, but my desired host CP uses an https-site and requires User/Pwd input, where the SSL might be a bit much for the Core to handle. So I guess there won’t be a Core-only solution to this - or will there :question: :blush: :question:

One possible method can be to route the login challenge over BLE to an app on the iPhone, where the user can handle the challenge. This also allows the logic to be held in the app, using the phone as a display.
See example of BLE integration with spark here.
This would also make it a lot more flexible to handle a variety of login challenges, like hotel rooms, public WiFi etc.

1 Like

@daviddedwin That’s adding a few layers of complexity. If I was going to rely on my iPhone to get my :spark: online, I think I’d just use the Mobile Hotspot feature.

One problem with these login portals is that there are lots of different ones out there. Some just want you to press a button, some want you to enter an email address, or some other information. There’s not going to be a way to handle all of them.

For the simplest case (just a button), you can try to just look for a form in the page, parse out the input data, and do the form submit (by sending the appropriate GET or POST client request to the form’s action URL). But even just doing that is probably going to take a fair bit of code, and probably eat up some of your valuable RAM.

1 Like

I was posting the possibility using BLE as a transport to send the challenge directly to the phone/PC app, without any processing, so RAM usage is minimal. The phone app would then parse/render the page, after that user input can be captured and send back over BLE as a constructed action. This constructed action can then be executed on the Spark.

You should be able to interface BLE to the spark and the phone with less than 400 to 500 bytes of RAM, since all the heavy lifting is done in the phone/PC app there should not be any RAM constraints.

This should be able to solve the login portal issue. In addition it would not depend on a data plan being present on the iPhone/Android/Windows 8/OS X, which I assume would be needed for tethering.

Definitely more work to add BLE but can be made to work a lot more consistently.

It sounds like there may be a number of solutions as it turns out! For my case there is very little cellular data service, so Bluetooth may be a nice way to go.

Unfortunately, between work and exploring this:

it might be a minute before I can get it all working together. :sunny:

4 Likes

Wow, where is that? “Don’t follow the lights?”

1 Like

This is Grand Teton National Park near Moran, Wyoming. I will be posting updates on getting my Core online while out here =]

1 Like

OK, I have gotten Spark-CLI installed and have dfu-util running, so now I should be able to flash either a BLE library or the http client library to get logged in to this captive portal. :cool:

Although there is an error message:
File downloaded successfully
Transitioning to dfuMANIFEST state
Error during download get_status
Flashed!

I am pretty sure it worked just fine! I can flash over USB via spark-CLI now :smile:

Hi @Elijah,

Nice! You can safely ignore the Error during download get_status message for now.

Thanks!
David

OK, so the next thing I needed to get going was Serial monitoring for debugging my case-specific usage of the HttpClient library for sending credentials to a captive portal.

The hardest part for me was finding the spark_core.inf driver which can be found here: https://s3.amazonaws.com/spark-website/Spark.zip

Once I installed that driver through Windows Device Manager I was able to select the COM port the :spark: was assigned in Tera Term and see output from Serial.println() calls, but only as long as I:

#include application.h

#include spark_disable_cloud.h

I haven’t tested various iterations to see where the dependency lies, but it seems if spark_disable_cloud.h is not included, then windows doesn’t recognize the device (because the code never reaches Serial.begin(9600); in setup()?)

So now will come the difficult part in figuring out how to structure my request to the captive portal :stuck_out_tongue: I’m going back to @Dave’s original post here.

P.S. @ScruffR It might sound silly but have you checked into an RJ45–>miniUSB adapter? I have no idea if this would require external powering of the :spark: rather than through USB or if it would work at all, just that they make adapters for everything.

1 Like

you will need to disable wifi too that will let the setup and main loop start, then you can do WiFi.on() in the loop :smile:

@Elijah, no I haven’t looked into such an adapter, but I don’t think that the :spark: Core does do http/https via USB.
And the WiFi feature was the reason to go for the Core in the first place, so I don’t want it tied to the router via USB either :wink:

But thanks for the suggestion anyway :+1:

1 Like