Updating Ruckus AP DNS Settings

I ran into an issue recently while trying to do some cleanup on a Ruckus SmartZone wireless controller. We migrated to new AD servers, which also doubled as DNS servers and included assigning new IP addresses to our controllers. All devices on our network with static IP settings needed to be updated. Servers and switching hardware weren’t difficult because we could script the change. Our Ruckus APs were more challenging. With 400+ APs to touch, making the change by hand wasn’t practical. There had to be a way to script the change. No problem. The Ruckus SmartZone controller had an SSH interface. It was pretty easy to get into settings of an AP config, so I could just change the DNS settings, right?

Or Not. It turns out you can’t just change the IP settings of an AP on the SmartZone controller. You can swap from static to DHCP and back, but that results in two reboots of the AP as it reads the config changes. There had to be another way.

I opened a ticket with Ruckus support to see if they had any suggestions. One option proposed was to use the “remote ap-cli” command to set the DNS settings directly on the APs themselves rather than in the config on the controller. Was that a solution? Yes, but if that APs were ever to reset, they would get the old settings from the controller. There had to be another way.

I then talked to our Ruckus Systems Engineer about the problem. He suggested I look at the SmartZone API. The API did have a command to change the IP settings, so I set out figuring out how to use it.

NOTE: Today, you can read through the SmartZone API documentation without a Ruckus support account, but I’ve been told that may change in the future. http://docs.ruckuswireless.com/smartzone/5.1.1/vszh-public-api-reference-guide-511.html

Now, I am not a developer or programmer. My official code learning stopped at VB.Net in 2005, but I’ve been using PowerShell for years to perform Windows and Active Directory management. From a talk I watched by Jeffery Snover (father of PowerShell), I know there are two useful functions I can use to talk with web-based APIs: Invoke-WebRequest & Invoke-RestMethod. Invoke-WebRequest can be used to get a session cookie needed to execute other API commands. Invoke-RestMethod is very similar to Invoke-WebRequest but can automatically parse JSON or XML data and turn them into PSObjects. With that knowledge in hand, I got started.

First, I had to get a web session.

$uri = "https://:8443/wsg/api/public"
$logonuri = $uri+"/v8_1/session"

$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Content-Type", "application/json;charset=UTF-8")

#logon
$body = @{"username"="admin";
    "password"="";
    "timeZoneUtcOffset"="-05:00"
    }

$json = $body | ConvertTo-Json


###Requesting a web sessions and adding the cookie to the header file doesn't work in Windows PowerShell 5.1
###Instead HTTPWebRequest from .NET has to be used and pass that session to all the subsequent PowerShell commands.
$webrequest = Invoke-WebRequest -Uri $logonuri -Headers $headers -Body $json -Method Post -SessionVariable websession

Next, I retrieved a list of all the APs managed by the controller. By default, the command paged the result to 100 items at a time, but I could easily loop to capture all the APs.

###Get all the APs on the controller###
$index = 0
$aps = @()
$apsuri = $uri+"/v8_1/aps?index=$index"

do {
    $response = Invoke-RestMethod -Method Get -Uri $apsuri -WebSession
    $websession -Headers $headers
    $aps += $response.list
    $index += 100
    $apsuri = $uri+"/v8_1/aps?index=$index"
} while ($response.hasMore)

Now all I had to do was retrieve the IP settings of each AP, create a JSON object with the new IP settings, and PATCH is back to the controller

#Example DNS addresses
$DNS1 = "1.1.1.1"
$DNS2 = "1.0.0.1"

foreach ($ap in $aps){
    $apuri = $uri+"/v8_1/aps/"+$ap.mac
    $ap = Invoke-RestMethod -Method Get -Uri $apuri -WebSession $websession -Headers $headers
    $oldnetwork = $ap.network

    if ($oldnetwork.ipType -eq "Static") {
        $newnetwork = @{
            "ipType"="Static"; "ip"=$oldnetwork.ip;
            "netmask"=$oldnetwork.netmask;
            "gateway"=$oldnetwork.gateway;
            "primaryDns"=$DNS1;
            "secondaryDns"=$DNS2;
        }
        $networkjson = $newnetwork | ConvertTo-Json

        $networkuri = $apuri+"/network"
        Write-Host "Updating $($ap.name)"
        Invoke-RestMethod -Method Patch -Uri $networkuri -WebSession $websession -Headers $headers -Body $networkjson 

        Remove-Variable networkjson
    } else {
        Write-Host "$($ap.name) is not using static IP settings"
        $notstatic += $ap
    }
}

That’s it. In a matter of fewer than 60 seconds, I was able to update the DNS settings on all the APs managed by our Ruckus Smartzone controller. This was just the start of what is possible through the Smartzone API. If I only wanted to modify APs in a specific zone, I could narrow the AP retrieval down by performing something like this.

###Get all the APs of a zone###
...
$apsuri = $uri+"/v8_1/aps?index=$index&zoneId=<INSERT ZONE ID HERE>"
...

I hope you found this interesting. If you want a complete PowerShell file to play around with, check out my GitHub repository found at https://github.com/agizmo/SmartZone-AP-DNS-Update

Have Fun.
-Tony

Modern Wireless for PowerPC Macs

Recently I took the opportunity to upgrade my home server from a heavily upgraded 2001 Quicksilver PowerMac G4 to a PowerMac G5. With that I took the opportunity to reinstall OS X 10.5 on the Quicksilver and turn it into web browsing station for when I’m in the basement working on projects. The main limitation I had with this was network connectivity. I could have run a network cable from the 1st floor office through the basement to the work area, like I did for the living room, but thought it was a little overkill. With the basement ceiling have interlocking tiles I also didn’t want to fight with them. The next logical conclusion was wireless, but that had its own challenges. The G4 PowerMacs never officially supported wireless above 802.11b.

Today 802.11b has two major disadvantages compared to every other wireless standard used: it is slow at only 11Mbps theoretical throughput and only the only encryption it supports is WEP. While 11Mbps of bandwidth is enough for simple surfing the WEP security is a big problem. The security protocol can be easily cracked using only a few MB of passively collected data and 5 seconds of compute time. Seriously: https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy.

So using an original Apple Airport card was out of the question. I could have created a separate wireless network off my DD-WRT router that used WEP and isolated the traffic from the house, but I felt that was still too much of a security risk. Instead I started looking into PCI or USB wireless cards that still worked with PPC OS X. I was surprised to find that may be multiple products that worked. Turns out Realtek made drivers for many of the RTL81XX series wireless chips going back to OS X 10.4 PPC. So all I had to do was find a wireless adapter with one of those chipsets and I would be set. Searching Amazon.com turned up dozens of results and I chose to go with a Bolse BO-N1557 USB adapter. The unit was small, built on the RLT8192CU chipset, and supported 2.4GHz 802.11n and therefore WPA2 encryption.

$15 and 3 days later I received the adapter and got to installing it. Years ago I had purchased a USB 2.0 PCI card during the CompUSA closeout and was happy to see it was plug & play in the PowerMac. It only made since to plug the USB adapter into the USB card rather than the USB 1.1 ports. Installing the drivers was easy and straightforward with no major issues.

The only challenge with using Bolse card was the configuration. It looked like Apple never allowed third party manufacturers to tie into the wireless features of OS X. That meant the wireless card showed up as a wired network connection to OS X and the Realtek driver utility had to be used to configure connections to wireless networks. The process wasn’t as smooth or hassle free as the built in OS X process, but was doable.

So there you go, if you have an old PPC Mac and you want to add some modern wireless connectivity, check out the dozens of wireless adapters built on the Realtek RTL8192CU chipset.

Fun Fact: Internally the original Apple Airport cards were WaveLan Silver/Gold PC Cards only without the built-in antennas. In fact, you could take a WaveLan card, plug it into the Airport slot of a PowerMac or PowerBook and it would show up just like an original. You couldn’t close the case because the card stuck out too far, but you at least had wireless connectivity. The WaveLan cards were also used in the original Airport base stations before Apple swapped over to Airport cards.

Have fun.

Newton Networking On-The-Go

A public service announcement from a fellow Newton nerd

Friends,
Do you surf the web on a mobile phone?
Do you find that experience too rich and interactive?
Do you wish for a simpler Internet experience while on the go?
What if I told you there was a way? A way to surf the Internet anywhere there is a cellular signal?
And do it from a Newton?

Introducing: WiFi Tether 3.1 Beta 11. Now with WiFi Tether you can turn your mobile phone into a mobile wifi hotspot and allow any wireless device to connect on the go.

How much would you be willing to pay for a product like this? $20? $50? $100? Now for an unlimited time you can have Wifi Tether 3.1 Beta 11 for the low price of $0.00. To prove how easy this product it I’m going to demonstrate on an Apple Newton 2000 MessagePad. Just watch:
Continue reading “Newton Networking On-The-Go”