WISPr workflow

WISPr ("Wireless internet service provider roaming") is a type of hotspot setup that is cheap to deploy because all the centralized tracking of usage, as well as command and control of infrastructure, can happen in one centralized system running in a private data center. The rXg can imiplement that centralized system.

Initial Connection

When the user first connects to the the Open SSID implementing the wispr hotspot, the infrastructure will try to determine if this device has usage or not. It will do this by attempting a RADIUS request. If the device does have usage, the RADIUS response will be success and the device will be placed online. Otherwise it will be placed into a "walled guarden" or unauthenticated state.

When a device is in a Walled Garden, the hotspot will try to redirect it to an external captive portal server. Depending on the vendor, this may be a redirect served completely locally by the AP or it may involve redirecting through the cloud controller. Either way, this process adds important "wispr data" to the context of the HTTPS conversation between the client and the external portal server. The key attributes of the wispr data are the client's MAC and IP, these are used to recognize the client's identity. Beyond those, further information about the client's site, connected AP, and so on can also be transmitted via the wispr parameters.

Without the wispr data, the external portal server would have no way of knowing which natt'ed device it is talking to. Please see sub natted wispr sites for more of a discussion on this. Once the device is connected and talking to the external portal, the external portal can decide what kind of usage to give to the device. This may or may not depend on a payment, and/or it may or may not depend on manual approval, which is a process RG Nets has termed "Sponsored Guest".

Getting Online

Once the user has obtained usage from the external captive portal, the external captive portal must make sure that their device is actually online so they can enjoy the usage they have paid for. Depending on the particular vendor, this can either be an HTTPS API + RADIUS process (RUCKUS vSZ), or just HTTPS API process (TP-Link Omada Pro Cloud Based), though in my opinion it is always better to have RADIUS working if possible. Once the HTTPS API and/or RADIUS transactions succeed, the client device will be put into an "AUTHENTICATED" state, meaning it can access the internet.

API is "client driven" in the sense that the external portal server can proactively decide when and which API requests to make. RADIUS is "infrastructure driven" in the sense that the external portal server responds to RADIUS activity from the APs/Controller.

Usually the two most important HTTP API transactions are described as "wispr login" and "wispr logout" for authorizing and de-authorizing devices, respectively.

I intend to go into more detail on each of these vendors in seperate blog posts.

Staying Online

Occaisonally the user is likely to depart from the Hotspot area. In this case, when the user returns, a new RADIUS transaction can be initiated by the AP to determine whether to treat the device as authenticated or unauthenticated, same as when a device first joined. If the device still has usage, the RADIUS server will return an ACCESS-ACCEPT, which will tell the AP to put the device online. Otherwise it will go back into the walled garden.

Hitting the portal from within the Walled Garden may also provoke the external captive portal to notice that the device has a cookie that correlates to an account with usage and get the device online via initiating an HTTP API transaction.

Going Offline

When the device's usage expires, the external portal server will initiate a "wispr logout" API transaction with the infrastructure controller. Further RADIUS ACCESS-REQUEST messages will be responded to with ACCESS-REJECT.