Accessing WiFi Internet through Captive Portal pages

[markopolo]

I'm curious to know what methods you all are using when accessing the Internet through Captive Portal protected Access Points. (WiFi, not wireless) Captive Portals are those pages that you have to agree to terms or enter a temporary code etc.

Did you give up on using a router? Do you have a Travel Router?

Also, I'm curious to know what percentage success rate you have if you any sort of router device.

I deployed a test Captive Portal AP at home and was able to get through to the Internet using my bridge and router combo ( http://www.classbforum.com/forums/f2...-rvs-5906.html ) but it took some time and effort to get it working and I wonder if that time and effort will end up being a often repeated occurrence as DHCP leases expire.

If anyone is using a Travel Router - does it auto renegotiate DHCP leases or do you have to logon again periodically?

[fratermus]

In my experience it's just a passthrough and the first user to hit the AP (or hit it again after the DHCP lease expires) jumps through the hoop.

Google has a tool baked into some of their devices that does this automagically. If ubiquity is linux under the hood you might be able to script the the AUP or whatever. Or maybe throw a Pi in the mix and let it do the grunt work.

[markopolo]

Thanks for the reply. It has given me some thoughts / ideas to try.

As you noted, it's all about the passthrough with Captive portal setups. Interaction via a web browser seems to be needed because of the variety of captive portals out there. You just click on a button for some, a checkbox plus button for others, a short code for others etc.

I am using two networking devices so as to utilize two radios for best performance; one to connect to the Internet source and the other one for internal network connectivity.

In the test setup, network device #1 is basically a bridge and network device #2 is a router. I had hoped that once I got browser enable device directly connected to the bridge (network device #1) through the portal then all other devices, including the router would connect. In my testing, that didn't happen until I reconfigured the router (network device #2) to also be a bridge. After network device #2 had been authorized I reverted its configuration back to being a router. Other devices behind that router had Internet access through the test portal.

My first thought on this today prompted by your reply about the passthrough step was that the front end device (network device #1) could be setup as a wireless bridge (station) to the portal and also be the router for the LAN. It might have to be station / bridge for the initial connection to the portal then changed to station / router after being authorized. Network device #2 would be configured as a wired bridge to the router and WiFi Access Point for the LAN.

Your suggestion to use a Raspberry Pi might be the easiest way to go (because it has a browser) if it can be setup as a station / router combo. I'd pair it with an Airgateway providing LAN WiFi.

I used a Pi for making the test AP with Captive Portal. It is a handy and versatile device.

[markopolo]

I went ahead and setup network device #1 as a Station (wireless client) on the WiFi side and as a Router with NAT enabled on the Ethernet side. Network device #2 connects to network device #1 via Ethernet cable and is setup as bridge on the Ethernet side and as an Access Point on the WiFi side.

Network device #1 gets associated with the Captive Portal protected Internet providing Raspberry Pi test AP. Internal network phones and computers all get connected to the network device #2 Access Point.

The Captive Portal page has successfully passed through to all the phones and computers that I tested. Some would only get the Captive Portal page when requesting a plain HTTP, not HTTPS webpage. Others got the Captive Portal page when requesting any webpage. That might be browser or device dependent. If any one of the internal network devices (phone, computer etc.) clicked on the access the internet button on the Captive Portal page then all internal network devices got internet access. It works as good as I hoped and is easy to manage via phone app. It is much easier this way than my previous setup. I'll have to test it on some other commercial Captive Portal pages.

I'm still interested to know how others get through Captive Portal protected AP's and also interested to know what router type devices you use with what estimated percentage success rate you get.

[Winston]

We hesitate to respond, in part, because we had difficulty following the technicalities of what you are doing and have tried. But we offer the following as it may be useful to others.

Our goal was to replicate our home network and server(s) in the van. To that end, we have an old, re-purposed Belkin 4-port wireless router, a Ubiquiti M2 Rocket modem/antenna and an Asustor file server as well as the normal panoply of tablets, laptops and cell phones.

The van is extensively wired for ethernet, but the router can also be accessed wirelessly. (The server and video editing computer are always connected via ethernet while lesser computers may be hard-wired depending on data transfer expectations).

Access to the internet is always through the Ubiquiti - - we have none of those interesting cellphone routers/antennas referenced in other threads on this Forum. The Ubiquiti connects either to an available WiFi Hotspot or to one of our cell phones acting as a Hotspot. And, again referencing other threads, we use the "trucker" version of the WeBoost with success - - it may not be as good as having an external antenna directly tied to a cell phone or cell router but, not having this alternate approach, it often makes that critical extra step between coverage and no coverage.

Now, attempting to address your question. After much experimentation, we configured the Belkin router in bridge mode, thus, we don't really 'talk to' our router, instead, always, to the Ubiquiti. This is important as - - for every different internet connection - - we have to reprogram the Ubiquiti, in short, selecting the desired Access Point (which more and more frequently is our own cell phone Hotspot) and, as required, enter the required password.

Access Points fall into three general categories: 1) Open - requiring no password or subsequent authentication; 2) Password Protected - requiring us to enter that password into the Ubiquiti; and, 3) Passive Portal - requiring no password 'to connect' but requiring 'acceptance' or subsequent user intervention in order to access the internet.

The above described system works well for all three. Option #1 allows all Belkin router connected devices immediate access to the internet once the Ubiquiti-to-AccessPoint connection has been established.

Happily, the #2 option works just as effortlessly. All Belkin router connected devices have internet access without further user intervention once the Ubiquiti has connected to the Access Point (i.e. once we've entered the required password).

The #3, or Passive Portal, option is only slightly more complicated. Once the Ubiquiti connection has been established, each connected device must separately self-authenticate or "accept" per the terms of the Access Point.

What we are uncertain of . . . but will be looking to document in the future - - is whether any time-out restrictions apply to all connected devices or whether each device sets its own 'time-out timer'. Our 'guess' is that each separately 'accepted' connection starts its own time-out sequence.

It is our impression that reliability/repeatibility is very high . . . nearing 100%. Our biggest problem came with Ubiquiti's later firmware revisions which precluded use of WEP authentications . . . not too many of those Access Points around any longer, but we downgraded our firmware to be able to use them as required.

So, from some obscure Missouri State Park campground, with no WiFi, we send you this missive via our Verizon cellphone Hotspot.

Winston

[markopolo]

I'm guessing your Ubiquiti M2 Rocket is set up as in Station mode on the wireless side and router mode on the on the Ethernet side. If so, then my setup pretty much mirrors what you had already accomplished. I'm using two Ubiquiti Airgateways with the second one connecting to the first in bridge mode like what you did with your Belkin.

It's good to get confirmation that your setup particularly the Ubiquiti front end does pass captive / passive portal pages through to your other devices. For some reason only one device on my network needed to "accept" the terms of the portal Access Point and then all of my other devices got internet access. That might have been because of the particular Captive Portal I was accessing for my testing. My test portal showed only one device connected; the Ubiquiti Airgateway in Router mode. All of my other devices are behind that router.

Like you, I'll connect the Ubiquiti to the phone hotspot if/when needed.

EDIT: I took a drive with this setup and stopped outside two fast food type chain restaurants. The portal page at both places successfully passed through to the two phones I had with me. In both cases only one device needed to accept the portal terms page. The other device got access after that. That will be good for network devices that don't have a browser.

[Winston]

Originally Posted by markopolo

I'm guessing your Ubiquiti M2 Rocket is set up as in Station mode on the wireless side and router mode on the on the Ethernet side.

The portal page at both places successfully passed through to the two phones I had with me. In both cases only one device needed to accept the portal terms page. The other device got access after that.

Correct - Ubiquiti is in Station/Router modes.

We'll pay more attention to 'portal page passthru' and report if, like yourself, only one authentication is required. We generally don't connect our phones, just the computers.

[avanti]

If anybody is wondering why I haven't jumped in here despite having a very similar setup:

After putting a lot of time and money into this issue (and ending up pretty much in the same place as Marko), I have discovered that I have literally NEVER actually ended up using these capabilities (and so have little experience with the issues currently being discussed). It is not that these aren't important issues for many people, it is just that given where and how we travel, we have found that a Jetpack connected to an external MiMo antenna is vastly more useful to us than looking for free WiFi. The MiMo antenna routinely lets us turn almost nonexistent cell service into a useful Internet link.

I love the idea of the Ubiquiti devices, but if I were starting over, I wouldn't bother with them. Rather, I would concentrate on a vehicle router that plays well with some MiMo-capable modem and get the best possible MiMo antenna.

YMMV.

[Winston]

Originally Posted by avanti

I would concentrate on a vehicle router that plays well with some MiMo-capable modern and get the best possible MiMo antenna.

We know there's a thread here somewhere but could you reiterate which Jetpack and antenna you would recommend? And the monthly cost? One advantage to our current 'jetpack' (cell phones) is that the data access is already paid for.

[avanti]

Originally Posted by Winston

We know there's a thread here somewhere but could you reiterate which Jetpack and antenna you would recommend? And the monthly cost? One advantage to our current 'jetpack' (cell phones) is that the data access is already paid for.

Here's what we use:

http://www.classbforum.com/forums/f5...html#post73350

Yes, the big disadvantage of this approach is that it is very difficult to pair an unlimited data plan with any device that is capable of sharing connections (for obvious reasons). But, this is just as true of tethered cell phones as it is of MiFi devices. And, as far as I know, no modern smartphone supports external MiMo antennas, which is key to a happy life. If you are going to use a phone, you are limited to so-called "cell boosters", which are pretty much snake oil (at least relative to MiMo). (BTW: note that since modern phones can make calls via WiFI, getting a good data link via a hotspot also gets you cell service where you might not otherwise have it--even across providers).

However, if you have a non-unlimited shared data plan, you can easily add a MiFi device such as the Jetpack to the plan for a nominal monthly fee. I think ours is $10/month. Hopefully the restrictions on unlimited wireless data won't hold in the coming age of 5G. But, in the mean time it is what it is.

[NFRicaS]

Originally Posted by avanti

If anybody is wondering why I haven't jumped in here despite having a very similar setup:

After putting a lot of time and money into this issue (and ending up pretty much in the same place as Marko), I have discovered that I have literally NEVER actually ended up using these capabilities (and so have little experience with the issues currently being discussed). It is not that these aren't important issues for many people, it is just that given where and how we travel, we have found that a Jetpack connected to an external MiMo antenna is vastly more useful to us than looking for free WiFi. The MiMo antenna routinely lets us turn almost nonexistent cell service into a useful Internet link.

I love the idea of the Ubiquiti devices, but if I were starting over, I wouldn't bother with them. Rather, I would concentrate on a vehicle router that plays well with some MiMo-capable modem and get the best possible MiMo antenna.

YMMV.

I have an unused TV Antenna on the roof of my class B..(2004 Pleasure Way) Do you think I could put a MiMo in its place? I really need better internet when I travel...all ideas appreciated.

[avanti]

Originally Posted by NFRicaS

I have an unused TV Antenna on the roof of my class B..(2004 Pleasure Way) Do you think I could put a MiMo in its place? I really need better internet when I travel...all ideas appreciated.

I don't see why not. The antenna is just mounted magnetically or via adhesive (depending on exactly what you buy). But, you do need a wire path, so using the old antenna location may save you from putting a new hole in your roof.

[fratermus]

Originally Posted by avanti

It is not that these aren't important issues for many people, it is just that given where and how we travel, we have found that a Jetpack connected to an external MiMo antenna is vastly more useful to us than looking for free WiFi.

Fair point.

In my case, being able to leverage free wifi allows me to have a much cheaper/slower data plan. I have a $35 Verizon MVNO that I use for light duties. I queue up heavier tasks and run them when I treat myself to a beer or restaurant meal somewhere with wifi.
My setup

no wifi available = verizon smartphone (nexus 6, used, $100) + EasyTether app ($10) as my plan does not include hotspot. Started out doing usb tether but have changed to bluetooth. My data speed is less than the BT capabilities so BT isn't a chokepoint. And it allows me to move the phone around in the camper instead of having it physically connected to the laptop.

wifi available = either

1. GL-iNet 300a mini router ($25) mounted in the cab. This is preferred as it can repeat the open wifi inside the camper and also repeat to nearby folks with more limited setups. Mounted inverted from the ceiling so it has a view through front and side glass but is relatively stealth. Apropos OP's original question, the first browser to hit the captive portal accepts the AUP. Since the router is relaying the traffic everyone behind it gets by on the original accepter's click.
2. Alfa usb wifi ($25) connected to laptop. Also mounted in the cab. This device is renowned for pentesting, but I use it because of its superior range (for its type) and deep peer knowledge base. I use a small panel ant with it when greater range is needed, otherwise an omni is less fuss.

I will eventually connect the Alfa to the mini-router for the best of both worlds (superior range + repeating). Have to do some reading first. It's linux under the hood so it'll just take some reading and play.

--

Afterthought: posting this from the Organ Mountains national monument. Tethered by bluetooth since there is no wifi (or humans!) around.