Motorola/Symbol RFS6000 Wireless switch

Started by bdefloo, June 05, 2013, 05:37:57 PM

Previous topic - Next topic

bdefloo

Hi,

First of all, great work the new update!
I love the monitoring on our WS5100 wireless switches.

However, we also have a number of motorola RFS6000 switches in use. It'd be great if we could monitor these in the same way. These are the successors to the WS series, and appear to use the same MIBs.

But to be sure, is there any way i can force the SYMBOL-WS driver on such a switch to test? Would you prefer I give you SNMP walk results? (of what OIDs?)

Thanks in advance,
bdefloo

Victor Kirhenshtein

Hi!

To use exysting SYMBOL-WS driver, device must support the following OIDs: .1.3.6.1.4.1.388.14.3.2.1.9.2.1 (adopted access points), .1.3.6.1.4.1.388.14.3.2.1.9.4.1 (unadopted access points), .1.3.6.1.4.1.388.14.3.2.1.12.3.1 (mobile units). Please check that they are supported, and if yes, send me walk results of .1.3.6.1.2.1.1 - I'll add device ID to the list of supported by driver.

Best regards,
Victor

bdefloo

Hi,

Walk results on those OIDs look good! I didn't get any results for unadopted APs, but our wireless switches are set to automatically adopt so there never are any.

The RFS6000 OID (read from .1.3.6.1.2.1.1.2.0) is .1.3.6.1.4.1.388.16. If you want to test before making any final changes to the device driver, feel free to send me a modified version.

There is also a small sidenote I'd like to make: if an AP goes down, it will dissappear from both the adopted and unadopted lists. This makes it difficult to monitor when one goes down, unless you look at the list of access port radios on the wireless switch:
OID .1.3.6.1.4.1.388.14.3.2.1.11.5 lists all configured radios,
.1.3.6.1.4.1.388.14.3.2.1.11.11 lists all adopted radios and their status. So, radios that are down are only listed in the former. In the WS5100/RFS6000 web interface radios that are down are shown with a red cross, which makes them easy to spot. The first list however does not appear to have a status field :(

Downside to working with radios rather than APs is that a single AP may have multiple radios (eg an 802.11a and a 802.11b/g radio), so they're listed more than once. On the other hand, I have had issues with one of multiple radios being down on a single AP, so this can be a valuable monitoring advantage as well.

Thanks for the support!

Victor Kirhenshtein

You right about configured and adopted lists. I think I should change the driver to read both configured and adopted radios, and change status of APs/radios if they not found in adopted list. Can you send me full SNMP walk dumps of .1.3.6.1.4.1.388.14.3.2.1.11.5 and .1.3.6.1.4.1.388.14.3.2.1.11.11? I don't have instant access to the device, so I cannot get this information for testing. Btw, when I design wireless monitoring part, I was also thinking about putting radios as interface objects below access point objects. Do you think it could be useful?

Best regards,
Victor

Victor Kirhenshtein

Also, on what OS your server is running? I'll build a patched driver for you.

bdefloo

#5
Hi,

I'm running NetXMS on Windows Server 2008 R2 (x64).
I've sent SNMP dumps of both tables from a WS5100 and an RFS6000 wireless switch to [email protected].

Like I mentioned, it does happen that an AP is up, but some of its radios are down/unadopted. So being able to view individual radio statuses would be an advantage. (id 62 in the WS5100 dump file is such an example)
Radios are layer 2 interfaces on the access ports, so listing them under their respective AP makes sense. Technically, they also have an ethernet interface with the MAC address of the AP itsself.

One remark is, how will you display (unadopted) radios on an AP that is down (not listed in SNMP)? You could fall back on the AP MAC address which is listed under .1.3.6.1.4.1.388.14.3.2.1.11.5.1.2, and use information from .1.3.6.1.4.1.388.14.3.2.1.9.2 to fill in the name and other details when available.

Kind regards,
bdefloo

Victor Kirhenshtein

Hi!

Attached is updated version of SYMBOL-WS driver. It should detect RFS6000 as supported device. I'll try to implement other changes we have discussed in 1.2.8 release (radio interfaces as separate objects and correct handling of down APs).

Best regards,
Victor

bdefloo

#7
Hi Victor,

I've put the new driver in our NetXMS server, it detects RFS6000 switches nicely and displays the APs. Thanks for the help!

One small additional remark: the AP model is detected as "UNKNOWN" for our AP650 devices.
I suspect this is because of OID
.1.3.6.1.4.1.388.14.3.2.1.11.5.1.5
which for an AP650 has value 9, whilst AP300's are 3.

Kind regards,
bdefloo