When back in 2021 I wrote an article about how to handle factory reset on surplus Ruckus R700 access points, I was writing with an audience in mind of... myself. Basically public notes, so I made certain assumptions about foundation knowledge and context (mine), and so it didn't really occur to me that more details might be in order before I handed a link to a friend who's got broad sysadmin and project management experience and said "hey do this" and expected success. Oops.

So picking up from where I left off, what does one do after a sucessful factory reset?

The bottom of the Ruckus R700 has a label that says "Default IP Address: 192.168.0.1", which turns out to be a bit of fake news. What it should say is "In the absence of finding a DHCP server, this AP will number itself to 192.168.0.1 rather than something in the RFC 3297 (aka 169.254/16) space."

If you perform the factory reset with the AP cabled up to an untagged port your working small network, it will surely DHCP and get an address just as if it were any other IoT device. Of course, then you have to actually find it so you can talk to the web server on it, log in, and configure it.

One way to do this is via the cache/logs for DHCP on your router. Stuff that has a web gui often has that in the management portal. Figuring this out is left as an exercise to the user.

Another way is if you happen to have a Mac or Linux machine (to include raspberry pi) handy on the same network is to scan the network with a tool called "nmap" and then examine your ARP cache. I don't know how to do this in Windows, and if you were thinking of trying to do this with WSL2, don't bother - the WSL environment is not technically on the same "network" is the northbound facing NIC on Windows, so you can't see anything of interest.

In either case, you're looking for the MAC address of the access point and its mapping to an IP address via the ARP table or DHCP logs. If you're not familiar with these, a nice overview - the salient point though which you may not be aware of even if you're familiar with MAC addresses is that not only are they case insensitive but there are variant representations of them to trip you up. To wit:

• colon-separated between the octets 00:1A:2B:3C:4D:5E (Unix, which depending on the variant may leave out the leading zero on any octet starting with zero, so this would render as 0:1A:2B:3C:4D:5E)
• hyphen-separated between the octets 00-1A-2B-3C-4D-5E (Windows)
• Dot separated between double octets 001A.2B3C.4D5E (Cisco and perhaps others)
• All run together like an animal 001A2B3C4D5E (Ruckus apparently)

And there may be more!

On Linux or Mac, install nmap via your package manager (apt or yum or maybe something else on Linux, homebrew probably on Mac). Figure out your network prefix by using ifconfig, ip, or maybe your network control panel. Now you can do a ping scan of your network like so:

nmap -sP 192.0.2.0/24

This will try to ping every address in 192.0.2.0/24. It might take a minute to run. It'll print out a bunch of stuff. None of the stuff it prints out should matter to you - the goal is to prime the ARP cache on your computer so you can look at it.

When it's done running, you can examine your arp cache by typing arp -an. But that's gonna be a lot on a busy network so let's grep for your AP - the last two octets should be sufficiently unique to find it:

arp -an | grep -i 4d:5e

should give you output approximately like this:

Hunters-Laptop:~ rs$ arp -an | grep 4d:5e
? (192.0.2.104) at 0:1a:2b:3c:4d:5e on en0 ifscope [ethernet]
Hunters-Laptop:~ rs$ 

Aha, now we have an IP address. We can point our browser at https://192.0.2.104 and do the requisite clicking through (because it's a self-signed cert) and log in, using the super / sp-admin credentials that you also found on a label on the bottom.

Success (hopefully)! How do do the actual configuration depends on what you're tryihng to accomplish, but I recommend nailing down your channel choices rather than allowing automatic choosing to happen.