WISPr -- rXg

In this post, I will lay out some of the deeper details of configuring the rXg as a WISPr provider, intending to cover both TP-Link's Omada Pro CBC and RUCKUS's vSZ.

This will be a particularly rXg-heavy post, so if you would like to follow along at home please check out our free rXg program, where you can download and install rXg on your own hardware.

WLAN Controllers (also known as Infrastructure Devices)

WLAN Controllers are how the rXg is able to track and interact with WLAN controllers such as Ruckus's vSZ and TP-Link's Omada Pro CBC. In general, each WLAN Controller that you expect the rXg to interact with should have its own record in Network::Wireless .

No matter the vendor, a controller must be reachable from the rXg, and it must be correctly credentialed in the rXg.

For more in-depth information on the rXg's integration with WLAN controllers, I recommend checking RG Nets' Youtube, Subreddit, and manual.

RUCKUS vSZ

To configure a vSZ integration, make a new WLAN Controller with type 'RUCKUS SmartZone'.

One notable feature of the RUCKUS vSZ platform is the Northbound Portal Interface (NPI). This features a username/password combination that will be unique to wispr login / logout API calls. Therefore this must be configured.

In the RUCKUS vSZ, this will be configured under Administration :: WISPr Northbound Interface.

It's a bit outside the scope of this article, but here's a great video about running a vSZ WITHIN the rXg, with the rXg acting as the hypervisor. If you are planning on deploying your vSZ onto any kind of self-hosted VM, some of the setup instructions in that video may give you ideas.

Omada Pro CBC

To configure an Omada Pro Cloud Based Controller integration, make a new WLAN Controller with type 'Omada Pro Cloud Based Controller'.

Setting up the Omada Pro CBC is fairly straightforward because the Host will always be the same if you are located in North America: use1-omada-northbound.tplinkcloud.com.

Username

Username is Omada ID. Click on the eye in the right hand side to find it.

Client ID

Client ID is the easiest to find: it's right there.

Client Secret

The Client Secret becomes visible if you click on the eye icon. You MUST be in widescreen to find this.

RADIUS

The RADIUS config is broken down into two parts: RADIUS Server Option and RADIUS Realm.

RADIUS Server Option

The Server Option defines important parameters regarding access to the RADIUS Realm such as RADIUS secret, the port, and the policies / WAN Targets that are allowed to reach it. I am allowing the sub natted wispr sites WAN Target because the TPLink APs send in RADIUS packets from those sites, and I am including the vsz.asdf.website WAN Target because that is the vSZ WLAN Controller which will proxy RADIUS requests coming from RUCKUS wispr APs.

RADIUS Server Realm

The Radius Server Realm defines which accounts, ie policies, are able to use this Realm. Since we're not doing "real" "in-band" Virtual Residential Gateway VLAN administration, it's safe and required to leave VLAN re-use checked. (Essentially everyone will be getting assigned the same VLAN but that is expected to be ignored on the infrastructure side anyways.)

Portals and Usage Plans

The Portal and Usage Plan setup for WISPr sites is fairly standard with a few particular features.

Portals

Splash Portal

Landing Portal

Background mode: MAC, and Portal mode: MAC or Cookie tend to work best.

Usage Plans

In general, any usage plan should work as expected for this, but there is one particular feature that is well suited to the WISPr setup, and that is "Manual Billing" or "Sponsored Guest" usage plans. This essentially means that settlement of the billing happens out of band by an rXg admin approving the transaction. Admins belong to Admin Roles and these Roles can have a balance which can be deducted against when approving Manual Billing transactions, if using Admin Roles as an intermediary seller is desired.

If you are an Admin and you wish to approve a pending Manual Billing transaction, you can do that via the Admin UI and via the Front Office Manager (FOM) operator portal. In the Admin UI you can access it via the Billing :: Transactions menu.

In the FOM you can access it in the upper right Admin menu :: Pending Ar Approvals

Conclusion

I hope this post gives you some ideas about how you can use rXg as a centralized point of authorization, accounting, command and control for WISPr deployments. In this setup, if you host your rXg/vSZ in your private data center, and plug in your WLAN Controller-provisioned AP literally anywhere with an uplink & reachability to your WLAN controller and begin collecting revenue. Please use responsibly.

Caveat

• Having two devices obtain the same private IP address at two different sites can cause instability. This is a known issue that reduces the simplicity of this kind of deployment. For now the recommendation is to make every subnet unique across every WISPr site running under one 1 rXg.

• Users will probably be connecting to an open SSID. Wireless client isolation is encouraged, but it's not a layer 1 solution meant to thwart a determined eavesdropper. 6GHz OWE should mitigate this. You could still use WPA encryption on top of this, but that works against the hotspot service-for-sale potential of this deployment methodology.