Problems with MVP panels connect to every accesspoint on first try
Jurgen Sachs
Posts: 33
in AMX Hardware
Hi there,
We got some installations with the same strange behavior.
We have to use the existing wireless network on side.
In one installation we have to use an cisco wap, in the second we have a siemens AP2610.
In both installations every AP hosts multiple SSIDs and VLANs with a lot of AP (50-90 peaces) the wireless network is set up fine for the channels and coverage and PCs and other equipment works just fine.
If we now boot the panles in some locations, the panels did not connect (MAC-Adress of AP is 44:44:44:44:44:44 so it is not connected to any AP).
If we move the panels to different area in the same wireless network, but different AP, the panel connect to the AP. If we now move the panel back to the location where it doesn't work before, it connect to the correct AP and work fine until the panel is rebooted.
Anyone see this before ?
Panels are MVP7500 and MVP8400, using 802.11B CF wireless card.
We did a lot of testing on the side with the cisco wap. Removed WEP encryption, disabled other networks. Always the same result.
The panel did not connect after reboot. Move it to an other location let it connect and go back to your previous area, where it now works fine until it shuts down or is rebooted.
Hopefully someone can explain what happens.
Thanks a lot
Juergen Sachs
COMM-TEC Germany
We got some installations with the same strange behavior.
We have to use the existing wireless network on side.
In one installation we have to use an cisco wap, in the second we have a siemens AP2610.
In both installations every AP hosts multiple SSIDs and VLANs with a lot of AP (50-90 peaces) the wireless network is set up fine for the channels and coverage and PCs and other equipment works just fine.
If we now boot the panles in some locations, the panels did not connect (MAC-Adress of AP is 44:44:44:44:44:44 so it is not connected to any AP).
If we move the panels to different area in the same wireless network, but different AP, the panel connect to the AP. If we now move the panel back to the location where it doesn't work before, it connect to the correct AP and work fine until the panel is rebooted.
Anyone see this before ?
Panels are MVP7500 and MVP8400, using 802.11B CF wireless card.
We did a lot of testing on the side with the cisco wap. Removed WEP encryption, disabled other networks. Always the same result.
The panel did not connect after reboot. Move it to an other location let it connect and go back to your previous area, where it now works fine until it shuts down or is rebooted.
Hopefully someone can explain what happens.
Thanks a lot
Juergen Sachs
COMM-TEC Germany
0
Comments
If the WAPs are serving DCHP, then perhaps it's taking some time for your previous connection to time out on the DCHP server. By moving the panel to another WAP, connecting, and then coming back to the previous WAP your clearing out the old connection and creating a new DHCP lease.
Just a thought...
All panels are set to static IP address and set to url mode. The master also has a static IP address.
The main problem is, that the panels did not connect to the wap at all, so IP is not envolved yet.
The only thing we see, while we are in the panel setup and the panle tries to connect is, that the wireless channel change and signal strength and signal quality shows something. But the MAC of the WAP is set 44:44:44:44:44:44. So the panel is not connected to ANY WAP yet, so IP can not work.
Thanks for the idear.
I have already done that, and they are also out of idears (and this is not often the case, so this is a "hard one") :-)
I tried that, but with my laptop I am not able to sniff ethernet traffic to all devices using ethereal :-(
As soon as I enable the "promiscue" mode (think that is what is needed to see traffic to all devices) I see no messages at all. Without, this mode, I see the traffic for my network card.
But, please correct me if I am wrong, since the panel is not yet connected to the WAP, it does not use the MAC or IP to communicate ? I guess the handshake for the MVP to log into a network is not seen by ethereal, but I am not shure about that.
That is something I can not get information about. How does this work in detail like:
- Panel looks for all WAP around
- Picks the best and starts asking "do you have my SSID ?", if SSID broadcast is on, it connects to the right WAP right now.
- if so, it tries to log into the WAP if not starts over and over again.
But there must be much more "behind the scene" I think. And I guess this is a "layer one" thing, which is not seen by ethereal.
But as I told, I am not 100% shure about that, so let me know if I am wrong.
Jurgen
It is my bad, I am spending most of the time in wired environment... In short, Ethereal can analyze 802.11 packets but it might not be able to capture control and management packets in rfmon mode - it is all device/driver/os dependent. On Windows, it does not work usually (http://wiki.ethereal.com/CaptureSetup/WLAN).
As an alternative, try to use airodump (aircrack). Another alternative is Kismet on Linux - that should definitely give the result (control packets). There is also Airopeek, but it is commercial.
I am not aware of other free Windows tools you can run the card in rfmon with. Can a professional from wi-fi contribute to the thread?
P.S. 802.11b handshake and packet info is here WildPacket’s Guide to Wireless LAN Analysis
Two areas covered by each of the AP's we'll call Area 1 & Area 2.
Two AP's which will call AP1 & AP2.
AP1 is in Area 1 and AP2 is in Area 2.
You have a TP let's say MVP1.
Somewhere a router (possibly multiple) and a possible dedicated DHCP server or several DHCP servers.
****************************************************************************************************
AP1 & AP2 have the same SSID, no encryption (at this point), different broadcast channels let's say 1 & 6 respectively.
You boot up in Area 1 and get not connection.
You move to Area 2 boot up and connect with out a problem.
When you go back to Area 1 you don't reboot and the MVP associates with AP1 like it's supposed to.
****************************************************************************************************
Is the MVP set static or DHCP?
Where is the DHCP server? Is it on the same network or a different subnet or VLAN?
Are there multiple DHCP servers?
What was the last channel the MVP used for a connection prior to booting up in Area 1?
What happens if you swap the channels of AP1 and AP2 (instead of 1 & 6 make it 6 & 1) and try again.
I personally don't think the MVP's do a proper job at handing off an re-associating and are ideally suited for areas coverd by one AP becasue do seem to be sluggish and resist giving up the channel there on even when there a better channel available.
Your problem is a little odd and may be a result of other AP's overlapping AP1's area from different networks and on boot up it sees something other that AP1 and possibly bombarded by DHCP assignment from different subnets or VLAN. Then once you try it again in Area 2 where the air is possibly cleaner with only one DHCP server to respond you get an IP address right away on that DHCP's servers subnet mask. You then back to Area 1 where it didn't work before but now your already assigned an IP and subnet so you simply change channels.
Now this theory only works if your DHCP on the MVP.
Master IP is static, panel is URL mode.
The buildings have multiple floors, so yes it could be that the other area is "cleaner" and does not have so much RF like the other area.
I did some snoop with netsumbler and saw a lot of WLAN and AP, but according to the signal strenght I also saw, they seemed to be placed well and do not have overlapping channels. Normaly I see around 10-20 WAP with netstumbler, but most of them are to fare away for the MVP to see because of the signal strength I guess.
I also want to test if the new Wireless G-Card chnage the behavior.
Maybe this fix things.
But I guess the buest will be an wireless expert who explains how things work in the background, so I know WHERE to search.
Are IT guys in charge of the network or is it your network to configure? If it's yours reverse channel numbers. You said the other APs seen through Net Stumbler were relatively weak but were the channels diiferent as well. I prefer to be at least a channel or two off even the weakest sniffable AP that seen on Net Stumbler as RF propagation changes during the day for several reasons. So even in a large installation where I have to repeat channel numbers I don't actually repeat.
Does this panel only have to roam between the two areas as one larger area? How much area it that?
Can the AP's locations be changed?
Are the APs configured identically except for channel numbers?
I assume ther are no other devices using yur MVP's IP address causing a conflict. (grasping!)
Again, try reversing the AP's channel numbers and repeat the test.
But they claimed that they interfer with theyre VOIP, so we had to use theyre network.
And the nightmare begins.....
- Every AP is set up identical.
- The channels did not overlap ( I aggree with that)
Each panel is used in one room only, where it only has to use one WAP. This WAP has a very good signal strength.
We checked the IP address multiple times (shut down the panel and made a ping). We only got a responce, when the panel was powered up, so I guess the ip is not used by second device. Also we have our own "network" (ip and netmask).
We can not change anything in the existing location or configuration of the WAPs installed. They go crazy because it is a heavy loaded net and is also used for VOIP.
I am out of options, and can only hope that a wireless expert is reading this thread and gives me hint.
Was this problem ever resolved? I think I am having a similar issue...
We are trying to use existing AP's also, and the networking folks have given us our own subnet. They do not want to broadcast the SSID they have given us for security. Normally when we enter the SSID manually on the panel, connection strength will show "Excellent" but the AP mac will show 44:44:44:44:44:44 If networking temporarily broadcasts our SSID, the panel links up and works fine. At that point, they can change the SSID to non-broadcasted and the panel still works fine until the panel is rebooted. Once rebooted, the panel will not link up and shows the AP as 44:44:44:44:44:44 again
Is it not really possible/ideal to have the panels on a non-broadcasted SSID? Surely there is a way....
Yes the problem is solved since friday. But we still keep an eye on this for a week or two.
In this installation we had SSID broadcast disabled and we also disabled SSID broadcast in our office. I never see problems with that.
What type of panels are you using ? MVP8400 or MVP7500 ?
What type of card is installed in the panel the older B or the newer G wireless card ?
In our installation the problem was an enabled QoS on the WAP, that confuse the wireless card. Anyway, there will be a new firmware, that could fix your problem, if it is the same we had.
Best is talk to AMX tech support I guess.