APs drop connection in WLAN configured as a wireless mesh network
I'm setting up a WLAN in a hotel I'm working on. It uses a Colubris MSC 3200 access point (AP)/controller. For some reason the Internet keeps dropping from the controller. The signal needs to span about 1,000 feet, and there is no RADIUS (Remote Authentication Dial In User Service) server, and I do not have any detailed info on the 3200's settings. In the hotel there are 16 APs on the same floor, each addressed by static IP's, with one transmit radio and one receive radio. Is the transmit radio (which uses a different SSID that I cannot connect to) supposed to be a bridge?
It sounds like your hotel's WLAN might be designed to use a wireless backhaul mesh to connect all APs to the Internet via the Colubris MSC 3200 AP/controller.
Colubris WLANs can form a wireless backhaul mesh connecting APs to each other and the MSC by using one of two radios on each AP to participate in a Dynamic Wireless Distribution System (DWDS) group. A DWDS group has its own auto-generated SSID and self-healing, secure configuration. All members of the DWDS group speak a Local Mesh Protocol (LMP) which is used to discover other WDS nodes, form the best possible backhaul links, and heal the mesh after AP failure or RF change -- all without administrator intervention.
In a DWDS, each AP is configured to serve as a master, alternate master, or slave
. Your MSC is probably your Master, accepting only upstream DWDS link requests from downstream nodes and relaying traffic to the Internet. Alternate masters simultaneously support both upstream and downstream DWDS links, and step in to fill the master role if the MSC goes down or can't be reached. Slaves are leaf nodes that can form only upstream DWDS links.
|Wireless backhaul mesh info|
| To learn more about configuring and using DWDS to construct a wireless backhaul mesh, read Lisa Phifer's tutorial at Wi-Fi Planet: Colubris LMP: Extending hotspot reach.|
If an alternate master loses touch with its master and cannot find a new master within 20 seconds, it becomes the master for its group. This is a big help if the alternate master can provide Internet access, but not so much if it doesn't. Furthermore, if a distant AP assumes the master role when your MSC goes down, it may not hear or relinquish the master role when the MSC comes back up. Therefore, distant APs and those that lack their own Internet connectivity should be configured to operate as slaves that never try to become the master.
I don't know why your MSC is losing Internet connectivity -- that could be caused by a physical, routing, or DNS failure in your Internet uplink, your Internet access router (assuming you have one), the MSC's Ethernet port, or the cable or switch that connects the MSC and router. You can debug those problems using device log files, trouble-shooting tools like ping, or a LAN analyzer like Wireshark. When you hear hoofbeats, think horses not zebras. However, assuming that you've already ruled out those culprits, I'll offer another possibility: perhaps your DWDS group is dynamically reforming itself, re-rooting to an alternate master that lacks Internet connectivity. That could happen if signal from the MSC periodically drops too low; you mentioned your WLAN covers 1000 feet, which is far enough that distant APs probably cannot hear your MSC. Use the CLI or GUI on each AP to determine whether your APs are part of a DWDS group and current/past DWDS group topology.
This was first published in September 2009