Michael McNamara

technology, networking, virtualization and IP telephony

Motorola RFS 4000 WiNG 5.5 Captive Portal

by

We use both Motorola and Aruba equipment in our locations. We recently deployed a few newer Motorola RFS 4000s in Spain and the United Kingdom which were running WiNG 5.5. We almost immediately noticed an issue with our externally hosted captive portal where the client would get an error after getting redirected, “Query Variable Qv not found”. That error was being generated by a piece of Javascript code that was running on the externally hosted captive portal pages that parses the Qv value so it can be returned to the RFS4000 to properly identify the user/device that is authenticating via the captive portal.

Here’s an example of WiNG 5.4 forwarding a client to an external captive portal;

"GET /?hs_server=172.16.1.10?Qv=it_qpmjdz=BVQ@bbb_qpmjdz=@dmjfou_njou=532778335@dmjfou_nbd=ED.:C.:D.13.EE.C9@ttj e=VSCBO_HVFTU_XJGJ@bq_nbd=C5.D8.::.33.32.:9 HTTP/1.0" 200 6040 "-" "CaptiveNetworkSupport-305 wispr"

Here’s an example of WiNG 5.5 forwarding a client to an external captive portal;

“GET /?hs_server=172.16.1.10&Qv=it_qpmjdz=BVQ@bbb_qpmjdz=@dmjfou_njou=23:45:9571@dmjfou_nbd=F1.C6.3E.53.:F.:9@ttje=Vscbo _Hvftu_XjGj@bq_nbd=95.35.9E.2:.49.6D HTTP/1.0" 200 6040 "-" "CaptiveNetworkSupport-306.3.1 wispr"

If you look at the URL you’ll notice that the WiNG 5.4 software release utilizes “?” as the variable separator while the WiNG 5.5 software release utilizes “&” as the variable separator.

The Javascript on the captive portal was parsing the URL by splitting it using the “?” value.  I could have just changed the value to a “&” but that would have broken the WS2000s and older RFS 4000s that were using the same webpage and Javascript. As a work around I created an additional path, aup.acme.com/wing55, copied all the files and images into that directory and then editted the Javascript in that folder only. I then reconfigured all the RFS 4000s running WiNG 5.5 to use the new path, example; “http://aup.acme.org/wing55/” and left the remaining devices using “http://aup.acme.org/”.

Cheers!

Reference;
http://www.michaelfmcnamara.com/files/motorola/WiNG5_Captive_Portal_Design_Guide_June_2011.pdf

 

Adopting US Access Ports in GB – Ooppss

by

I ran into another interesting problem today…. we use a combination of Aruba and Motorola wireless equipment. When we have an issue with say the captive portal on a Motorola RFS 4000 it’s pretty easy to take an AP 650 and configure it via DHCP to connect via WISP/WISPE/CAPWAP to the remote controller so you can easily observe the problem first hand. In this case the Motorola RFS 4000 happened to be in Barcelona, Spain although it was configured with a country code of GB (Great Britain). I probably spent the better part of two hours trying to get the AP to adopt to the RFS 4000. I originally thought the problem was related to the AP trying to perform a software upgrade over a 200+ms distance between the AP and WLS but even after I disabled the auto-upgrade feature I would still end up with the following SYSLOG messages;

Nov 20 18:21:59 2014: LED state message WIOS_LED_NO_COUNTRY_0_24G from module DOT11 : %DIAG-6-NEW_LED_STATE:
Nov 20 18:21:59 2014: LED state message RADIO_ALL_LED_OFF from module DOT11 : %DIAG-6-NEW_LED_STATE:
Nov 20 18:21:59 2014: Radio 'ap650-981XXX:R1' changing state from 'Initializing' to 'Off(no country-code)' : %RADIO-5-RADIO_STATE_CHANGE: ff(no country-code)'
Nov 20 18:21:49 2014: RFS-4000 : %AP-6-ADOPTED: Access Point('ap650-981XXX'/'AP650'/5C-0E-8B-98-XX-XX) at rf-domain:'default' adopted and configured. Radios: Count=1, Bss: 5C-0E-8B-31-XX-XX|

I finally realized that the AP650s I had were US models and not WW models. I was able to take an AP300 (WSAP-5110-100-WW) and configure it to connect to the RFS 4000 via DHCP option 189 and ultimately solve the puzzle around the captive portal issue (future blog post).

Cheers!

Recent Posts

Categories

SUBSCRIBE BY EMAIL