1242/1510 Mesh on WiSM running

Unanswered Question
Apr 7th, 2008
User Badges:

I have set up wireless mesh with 1030s on earlier controller code with no problem. I used the Zero Touch config with a bridge group name and preshared key. Now I am setting up a mesh between a 1242 (RAP) and a 1510 (MAP). I have the MAC addresses in the MAC filter table and the APs join the controller fine. The 1242 is set up as the root, the 1510 is set up as a mesh AP. Ethernet bridging is enabled on the RAP, and the MAP will use the 5 GHz backhaul, with 2.4 GHz for clients (no client access on the 5 GHz back haul). I cannot get the APs to come up in mesh, and no amount of debug specific to mesh on the APs and/or the controller have yielded any useable information. What I have concerns about are the following:

1. Using the 1242 as the RAP. Documentation indicates it can be a RAP with no problem. Any reason why the 1510 MAP wouldn't be able to connect?

2. This version of code doesn't support Zero Touch. All documentation I have consulted says to use Zero Touch to configure. The command is not available in the GUI or command line as a choice. What procedure is required to authenticate the APs and allow them to pair?

I have also tried moving the APs further apart to make sure the SNR isn't too high, as I am testing the mesh in the same room before I deploy them to their intended locations.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Scott Pickles Tue, 04/08/2008 - 10:29
User Badges:

It is unfortunate that I didn't get any responses here, or from TAC for that matter, but sometimes that's just the way it goes. I figured this one out, and wanted to post my results so that someone else could follow in my footsteps.

Often times we can't get a mesh link working because one of the many prerequisite steps is not satisfied. I'm talking about just joining the AP to the controller, which requires things such as L3 routing, addressing, DNS/Option 43, trunking, MIC vs. SSC, MAC Filter/AP policy, etc. etc. So what do you do when the APs join the controller and won't form a mesh? We know they have to be on the same channel and share some trusted information. On earlier code releases, we could use the Zero Touch Config, in which case all mesh APs connected to the controller would download the pre-shared key from the controller, ensuring all physically connected mesh APs to that controller would share that trusted info in common (remember, we're authorizing APs with the MAC filter and/or trusted AP policies). Then all you have to do is give them all the same bridge group name, make one a RAP [most likely with ethernet bridging] and things should come up without a problem. Follow documented recommendations and join the RAP first though. In my situation, the Zero Touch config is gone, as is the CLI command for a pre-shared key. So now what? I wasn't sure if that had anything to do with my difficulties. So I resorted to meshing 2 1510 APs and they came up with no problems. This gave me enough insight to solve my mesh problems with a 1242 and a 1510...

1. Make sure you're running a version of code that supports both the 1131/1242 series of APs as well as your 1510s. I chose release, which supports 1131/1242/1510/1522 in mesh mode, as well as 1131/1242 in normal LWAPP operation.

2. Add MAC filters for your mesh APs, including the 1242 as that will be converted to bridge mode.

3. Join your 1242 first, and allow it to download the image. Set its primary controller, static IP [if used], channel and power, etc.

4. Change its mode to bridge, and it reboots (again, changing it image to the mesh which I believe is k9w8). Set the backhaul speed, bridge group name, ethernet bridging, etc.

################## IMPORTANT! ##############

# This next step is the reason why my scenario of a 1242 RAP and 1510 MAP was not working #


5. In order for the mesh link to come up, the APs have to be on the same channel. I noticed that my 1510s would always come up with 161 or 165, in the outdoor channel range. The 1242 would always come up with channel 36. This is due to the fact that under mesh mode, the 1242 is recognized as an indoor AP, whereas the 1510/1520 series APs are outdoor. I would think that the APs wouldn't have a problem agreeing on a channel to use, but in my case, they couldn't agree. So I joined my RAP first and manually set its channel to 161 on the Dot11Radio1 backhaul.


6. I next joined my 1510s with an ethernet connection and set them up as mesh APs, no ethernet bridging, and same bridge group name as the 1242.

7. Disconnected the ethernet drops and rebooted them and the mesh fully came up.

I hope this helps for anyone else trying to set up this particular scenario using an indoor AP as the RAP, meshed to outdoor APs in MAP mode.



MICHAEL SCHROEDER Mon, 06/30/2008 - 06:22
User Badges:

Hi Scott, thank you for your detailed Explanation. It matches exactly a few of my problems. I did my first steps in Mesh Networking... Is it right, all of the Mesh APs (including Root APs) have to be connected to the Ethernet at First, then to be configured for Mesh - including their Role in the Mesh - and after unplugging, mounting, powering they came up as Mesh AP? Is using of the AP1242 as RootAP for AP15xx as MAP officially supported?

Regards, Michael

Scott Pickles Mon, 06/30/2008 - 13:44
User Badges:


Yes, you need to connect APs via ethernet at first for a couple of reasons. First, it is likely you have changed the default Bridge Group name, as leaving it default is a security risk. The only way to change that is to connect the AP via ethernet. Second, by default all APs come online as MAPs, so if you didn't configure your RAP first via ethernet, the others wouldn't have any root to search for. So technically, you SHOULD be able to connect only one first and make it root, specify the other AP MAC addresses as allowed APs, and mesh the others. However, I HATE doing that as there is no CLI view of the outdoor mesh APs as they boot and go through the procedures. Finally, a simple mesh of as few as 4 APs can take as long as 20 minutes to converge - I don't have time to wait that long in the field to verify that what I have done is correct. Whenever possible, I pre-stage everything. Finally, the use of a 1242 is probably not a first choice, but I didn't find any documentation saying that you COULDN'T do it that way. The reason I was as detailed in my post is that although they don't indicate that it isn't supported, there sure isn't much documentation on it. Hope my posts will help you get up and running.



This Discussion



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode