Hey, I'm running OpenWRT Barrier Breaker 14.07 on my router, and I'm having some trouble connecting to free WiFi hotspots.

It works fine with ethernet connections and connecting to my own broadband, but I’ve been unable to make it work with any public hotspot.

It seems to be incompatible with any hotspot where web authentication is required, such as a page that you agree to the t&c’s of the wifi. Even manually entering the portal address doesn't work. On most devices, trying to go to a website like google.com will bring up this page.

Is there any way around this or does OpenWRT simply not support public hotspots?

Are you trying to build wifi repeater from your openwrt or you're going to have your own AP that NAT internet provided by another AP ?
In last case create one wifi network as AP client and bind it to WAN interface. Another one create as AP and bind to LAN interface.
One physical radio cannot work simultaneously on two frequences - thats why they will have to share one channel.
Or if you have two radios then you can separate client and AP and configure them independently.
If you want repeater without NAT then you'll probably need relayd.
In any case openwrt from the box cannot enter data to hotspot webpage for you. If you want this you'll have to create your own robot script to do that. Analyze web page, see how form is submitted, then write script to call wget or curl.

(Last edited by bolvan on 22 Jan 2016, 15:15)

Using the 'Search' service on this forum would have returned this link, answering your question.

The recipe in the wiki is unnecessarily complex. This works for me:

Add a new virtual interface (wifi-iface) in /etc/config/wireless in STA mode, assign it to network wan. Make sure the radio (wifi-device) uses the same channel as the public hotspot (you can set channel to auto if in doubt):

config wifi-device 'radio0'
    option type 'mac80211'
    option channel '11'
    ...

config wifi-iface
    option device 'radio0'
    option network 'wan'
    option mode 'sta'
    option ssid 'Hotspot SSID'
    option encryption 'none'

Modify the wan network's interface in /etc/config/network to use the wifi interface instead of a switch port:

config interface 'wan'
    option proto 'dhcp'

This works with public hotspots which just show a splash page (such as an agreement of its use), but with hotspots using some kind of user authentication (e.g. by client's MAC addresses) it can lead to problems, since your (routing) repeater might be seen by the hotspot as only one client regardless how many users connected to your AP try to log in.

To overcome the latter, you would have to configure an AP wifi interface bridged with the STA interface and turn on 4addr (Wireless Distribution System) mode on both, your OpenWRT box and on the public hotspot.

(Last edited by R1D2 on 23 Jan 2016, 14:44)

I'm not sure why you consider this a problem. When you stay at a hotel which provides a login splash screen to access the WiFi, you want all the computers connected to your OpenWrt AP to be considered as one computer by the hotel WiFi. This way you only have to log in to the hotel WiFi once and no other devices connected to your OpenWrt AP need to log in.

1. Configure your OpenWt device for AP+STA using the instructions here substituting your hotel SSID for Google Starbucks.

2. Connect your computer to your OpenWrt AP.

3. When your computer web browser gets the hotel WiFi login splash screen, log in with your username/password, room number/last name or whatever is required.

4. Now you can connect all your other devices to your OpenWrt AP and you will not get a login splash screen from the hotel Wi-Fi.

Chaos Calmer will disable its AP if you do not type in the hotel SSID correctly when you are configuring AP+STA. If you do not have an Ethernet cable along and a laptop with an Ethernet port, you could be locked out of your OpenWrt device. This is what the fix_sta_ap.sh script towards the end of the recipe here attempts to address. If your OpenWrt device does not connect to the hotel WiFi in 30 seconds, the fix_sta_ap.sh script will revert your OpenWrt device to AP only mode so you can connect to it through wireless and correct your error.

Please note that I have only tested the above with Chaos Calmer. I don't know if it works the same with Barrier Breaker.

As I wrote, this is no problem with splash pages. But e.g. in Germany, the law requires you to log in using a personal login account at public hotspots (login pages are btw. not splash pages, but login pages in the terminology of most Captive Portal Software, so as to describe their different behavior). Even on login pages, as long as only you use the repeater for yourself, this setup also works fine.

However, if the repeater is set up as a repeater for several users (i.e. as a "range extender"), this will lead to problems if several (different) users use the repeater and logins are required, since as soon as one user logs out, every other user is logged out also. Believe me, this can become a real problem - I once had to deal with lot of unsatisfied hotspot users because of this effect, when hotspot owners used range extenders with such a setup.

Of course this is not OpenWRT-specific, but happens with every repeater in the so-called "universal repeater mode" (i.e. without 4addr-mode turned on on both sides).

(Last edited by R1D2 on 27 Jan 2016, 18:32)

Please note that I described a web browser login page for a hotel WiFi hotspot in my previous post. Does the German Public WiFi Captive Portal Software use anything other than MAC address to keep track of what computer is connected to it?

If the OpenWrt device is set up in AP+STA mode as described here, then only the first computer should get a login screen in its web browser. Since the Captive Portal will only see the MAC address of the OpenWrt device, no other computers connected to the OpenWrt device should ever get a login screen.

How do you get to a log out screen with your web browser? All the wifi hot spots I have seen simply automatically log you out after a period of time or when you disconnect your computer.

(Last edited by vernonjvs on 27 Jan 2016, 20:57)

The Captive Portal (CP) software manages all packet traffic for associated STA(tion)s. CoovaChilli, the base code for most if not all current CP solutions, interrogates URLs and encountering one which is 'magic', one being '/logout' IIRC, closes the connection AKA logging off. CoovaChilli handles blacklisted domains in the same manner.

I don't understand what you mean by interrogating a URL and magic URLs. I have a PC which is connected to a WiF public hotspot in Germany which requires a login. Once I log in with a web browser, how do I get a log out screen with the web browser?  I have not seen a log out screen in my web browser on any public wifi hot spot that requires authentication in the US. Typically de-authentication only occurs after a timeout or disconnecting the PC. Since only the OpenWrt device is is connected to the WiFi hotspot, WiFi de-authentication will not occur when a PC connected to the OpenWrt device shuts down or disconnects.

Are you saying that the German public WiFi hotspots will de authenticate your PC if your browse to a blacklisted site? Typically, I have only received warning web pages under such circumstances and no de-authentication.

wifidog uses the combination of the MAC and the IP address to identify clients internally.

As soon as the first user logs out or is automatically logged out - e.g. because his browser's session on the authentication server times out -, every other user will be logged out also and they will see the login page at next page load in their browser (or even automatigically on tablets and phones due to their network location awareness requests if any app tries to access the net during this time-window until any other user again logs in). wifidog's auto-timeout for inactive users is as short as 10 minutes.

By addressing the portal page, either manually as described in the hotel's flyer or through a NFC tag our hotspot service used to direct the user's browser to the login / logout page.

wifidog would only see the IP and MAC address of the OpenWrt device when it is configured in AP+STA mode so wifi dog should not be able to identify any computers connected to the OpenWrt AP and de-authenticate them.

Are you saying that if a user who logged in closes their web browser that this will cause their computer to get de-authenticated from the hotel WiFi hotspot? 

I have never seen hotel wifi requiring a special URL to log in. Typically, all web addresses are initially resolved to the portal log in page. Once you log in, normal DNS resolution occurs and there is no log out page.

Please note that I am not doubting what you are saying is true. I just have never a seen a hotel hotspot that

• De-authenticated your computer if you closed your web browser.

• Required a special URL to log in and out.

I've definitely seen portals with logout pages.  Most of the ones I've seen create a small popup when logging in so you can go back to it easily (assuming it doesn't get blocked by a popup blocker).

Closing it though usually doesn't affect the session.  Personally I usually do close it and just let the session time out when I'm done.

Yes, and exactly this (not be able to identify any computers) is the problem.

Not by closing the browser. Any user gets de-authenticated in wifidog if:

• they turn of their wifi connection for more than a few minutes (see below) - be it by leaving the location or by the device entering sleep mode,

• the browser's session on the auth server expires (usually after one or more hours),

• they log out manually through the login/logout page which is left open in a separate tab.

The code in wifidog responsibe for auto-logout after 10 minutes (or whatever you set as timeout) of inactivity is:

        /* Ping the client, if he responds it'll keep activity on the link */
        icmp_ping(ip);

        /* Update the counters on the remote server only if we have an auth server */
        if (config->auth_servers != NULL) {
            auth_server_request(&authresponse, REQUEST_TYPE_COUNTERS, ip, mac, token, incoming, outgoing);
        }
            LOCK_CLIENT_LIST();
        
        if (!(p1 = client_list_find(ip, mac))) {
            debug(LOG_ERR, "Node %s was freed while being re-validated!", ip);
        } else {
            if (p1->counters.last_updated + (config->checkinterval * config->clienttimeout) <= time(NULL)) {
                /* Timing out user */
                debug(LOG_INFO, "%s - Inactive for %ld seconds, removing client and denying in firewall",
                        p1->ip, config->checkinterval * config->clienttimeout);
                fw_deny(p1->ip, p1->mac, p1->fw_connection_state);
                client_list_delete(p1);

                /* Advertise the logout if we have an auth server */
                if (config->auth_servers != NULL) {
                    UNLOCK_CLIENT_LIST();
                    auth_server_request(&authresponse, REQUEST_TYPE_LOGOUT, ip, mac, token, 0, 0);
                    LOCK_CLIENT_LIST();
                }

As you can see, it even advertises the gateway's auto-logout to the central auth server, therefore destroying the session there also.

Absolutely right, the Captive Portal will intercept URLs addressed by the user to re-direct them to the login page. But often users don't even start a browser after connecting to the hotspot's wifi card. They instead start a mailer program or another app on their smart phone/table/laptop and wonder why they "don't get Internet access".

They even tend to ignore the notification e.g. of Android due to the NLA requests send out by the device after associating with the router's wifi card. In latest OS/X the NLA will even prominently show the login page in a big web view window on the screen (implemented in Preferences AFAIK) if such a re-direct appears after connection to the wifi card of the router. There is no doubt, that the NLA scheme has been introduced b/c of high-volume support calls at vendors why "their device won't work with public hotspots" :-)

In the past, hotel managers asked for a flyer with step-by-step instruction on how to log in. The URL of the login page on the central auth server in wifidog is something like login.authserver.domain. This page stays open in a separate tab, not only to allow manual logout, but also to show URLs for the hotel's own website, the city's website, the link to the user's profile, the status of other routers of this hotspot etc. It is not just a cheap login form in wifidog, it's more a fully featured portal page.

Since in Germany we have very stupid laws allowing even lawyers (no judge needed!) to punish hotspot owners or users, which let others download copyrighted material from the web, people here insist of being able to explicitely log out from a public hotspot. I wish, those stupid laws would be dropped, but just yesterday the high court of Germany has refused to declare the new law for prophylactical data storage by ISPs as un-constitutional, therefore allowing lawyer firms to continue spying on IPs, which is an important issue for owners of public hotspots. Each copyright infringment can cost them as much as 700 to 1.500 USD for every single download done by some unauthorized user either because he didn't need to log-in or because he abused some other's account.

Therefore it is very risky for hotspot owners to set up a repeater which does not enforce a login-/logout-scheme. But it's only a specific usage case, which does not apply to using a repeater for only yourself to avoid having log in with every devices you use, so I completely agree with you in that a STA+AP bridge might be sufficient for most people - but not for all and that was it, what I wanted to point out, especially b/c OpenWRT offers a solution even for this usage case, where devices need to be uniquely identifyable by the hotspot.

(Last edited by R1D2 on 28 Jan 2016, 13:54)

And clearly you do not understand how CPs work -

So please take it on faith that 'logout' links exist.

N.B. a hotspot is not always public. Many require a (free) voucher.

From the Chillispot FAQ you linked:

This is a great idea to return to the logout page without having to know the full URL! Thx for pointing this out.