Hi everybody.
I have a customer with an area covered by 4 access point 9150 placed in peripherical zone of this area and one 9160 access point placed in the middle of that area.
All the access points have the same SSID broadcasted, same channel used and all the access points work only with 802.11b protocol.
I have this problem.
In some situation, when i go from the center of the area on the peripherical zone, I see the access points' log and I find a Reassociation event on 9150, no deassociation event on 9160 with the result that I can't reach my client (i have a lost of packets).
It seems like both access points are the owner of the association and my network doesn't know how to reach the client.
Any suggestion? I know I didn't explain so well, but the situation is very strange.
bye and thanks.
Francesco
HI Francesco, there are a few things I can think of:
1. has this worked well before?
2. Why are you using the same channel on all APs? It is a configuration suggested only in certain conditions.
3. APs use what is called the IAPP protocol to communicate the association/ disassociation between the APs. Make sure you are running the latest SW on the APs to avoind the eventual issues caused by IAPP.
4. How are the 5 APs connecting to the backbone? Ideally the same switch.
5. Are there any clients that works fine in this environment?
I hope this helps,
Marius
Hi Marius,
Many thanks for your answer.
1) This area is a warehouse where our customer prepairs picking.
In the old configuration they worked with handheld computer without problem. They've started use voice picking and with this new hardware they are having problems (I don't know now the hardware model).
2) I can try to change channel, do you think could it be a good idea to leave peripherical APs on channel 1 and change only the AP placed in the middle on channel 11?
3) 9150 version: F192n ; 9160 version: J188e
4) Today I put all the Aps on the same switch. But It didn't solve the problem.
5) For example my PC. But I think I stay always connected with the AP in the middle.
Thank you another time for your kind help!
bye
Hi Francesco, in order to check if the software level is the recommended one I would suggest talking to our Help Desk analysts, I am not in a position to talk about what you have now vs what is recommended.
As for the issues you're seeing, the fact that you do voice picking now using different devices is a key element in the investigation. Wireless networks are designed specifically for the application and for the devices that are going to be using it. That means that the requirements from your wireless network can be different from what you've had in the past when using the handhelds. The fact that they worked well in that network is good, but it doesn;t guarantee that the new devices and new application will run as smooth.
Usually, the recommendation is at least to re-check the coverage to make sure it is adequate for the new devices/ application if not to do a site survey with the new requirements in mind.
The only time when you would use the same channel on all APs is when the roaming is key and you want to speed it up as much as possible. It is deployed after careful analysis and usually not recommended if everything works well. I would recommend using channels 1, 6, and 11 to avoid the co-channel interferrence.
How many devices do you have on the network? What is the maximum number of devices/ per AP that you see?
Roaming is a client decision, so if your laptop things that the middle AP provides enough coverage and good SNR (signal to noise ratio) then it doesn't roam. Usually, it is a good thing to have as little roaming as possible. It introduces delays, lost packets and trouble, especially for more complicated wireless security methods.
Hi Francesco,
As i read your description of the problem. I think it has to do with the mix from 9150 and 9160 accesspoints. The problem was introduced with installing the 9160 accesspoint?
I would expect that an upgrade of the 9150 to the recommended release would solve the roaming problems.
Regards,
Lowie
One thing you might want to try, just as a test would be to plug the APs into a HUB instead of a switch. The IAPP between the APs might be getting blocked by the switch preventing the 9160 from knowing that the client has roamed and updating the switches CAM table. As a result network packets are getting routed improperly by the switch to the wrong AP.
If this works I would first update the software as Marius and Lowie suggested. If you continue to have the problem but it works when using the hub, look at the switch configuration.
Hi all and thank you in advance for your help.
Marius:
maximum number per AP: 8; The coverage is very good, in every place i have good signal (between -50 and -70).
I investigated and I found that the problem is only with LXE HX2 terminal. With teklogix 7035 We have no problem. I'm thinking it's a roaming problem on LXE (windows CE 5).
Lowie:
I tried to change the 9160 with another 9150 (to have all the same AP). But i didn't solve the problem.
I couldn't find on Psion's Site any firmware upgrade (files and procedure) for the 9150.
Don:
I didn't try with an HUB, but i have the problem also using only 9150.
With LXE Client (ex: Mac xx:xx:xx:xx:xx:00) I have this Situation.
If i can see in the log these records:
On AP 1 -> Reassociation xx:xx:xx:xx:xx:00 on AP 2 -> xx:xx:xx:xx:xx:00 moved elsewhere
I don't have any problem.
If I see these records:
On AP 1 -> Reassociation xx:xx:xx:xx:xx:00 on AP 2 -> Reassociation xx:xx:xx:xx:xx:00
I have problem!
The problem was fixed only when on one of the AP logs I can read: xx:xx:xx:xx:xx:00 moved elsewhere.
Bye and thanks
What happens is when a client roams, the AP that you roamed to sends out a packet that announces that the client has roamed to him. This packet is a multicast that is heard by the other APs, when the previous AP that the client was associated to hears this multicast packet, it drops the client from its association table. When you see the message, "[MAC Address] moved elsewhere" that means that the previous AP heard the multicast and updated it's table correctly. When you see the "Reassociation" message on two APs then it is say that the client is associated in two locations which is obviously wrong. So my conclusion would be that the one AP did not hear the multicast packet, did not understand the packet correctly or the roamed to AP did not send the packet out correctly. Also, the multicast packet is sent out as spoof using the clients MAC address. This way the switch sees network traffic from the client coming from it's newly associated AP and updates it's CAM table.
Now, in your case it sound like sometimes it works and sometimes not. When you are using all 9150s are they the same software version? If not, upgrade to get them all on the current recommend build. If you cannot find the procedure, call the help desk and have somebody walk you through the upgrade process.
If you upgrade software and still have problems then start looking at network issues. Maybe packets are getting dropped. Maybe packets are getting blocked (this is what the hub will prove). Not sure how in-depth you are with network analysis but if you can do some sniffer traces on the wired network of the communication between the APs you can see if those packets are being sent out correctly and if they are making it through. (Wireshark is a nice, free packet sniffer) One thing you could also look for since it seems to work sometimes, is there a pattern between roams. for example if I roam from AP1 to AP2 it works but if I roam from AP2 to AP3 it fails. Look for patterned like that that might give you some clues as to where the problem is.
Hi Don,
You gave me a very appreciate suggestion! I'm planning the HUB test. For now, I can say you that all 9150s have the same software version (F192n).
Bye
Hi Francesco
In an area where roaming occurs between 9160G2 and 9150 Access Points the 9150 must be running at least version 9150_Mini_5.0.408_D137q for problem free roaming to occur. as It had been noted already it is recommended to contact you local Help Desk for assistance updating the 9150.
You may also find the following information helpful
"Starting with the 9150 18865E release (file name 9150_Mini_5.0.408_D137q), the 9150 will issue an IAPP multicast packet whenever a client associates or re-associates from a 9150 or an IAPP unicast packet if the association/re-association is from a 9150. These IAPP packets will now address the LAN switch with the terminals MAC address contained in the IAPP packet. The 9150 will remove associated terminal MAC addresses when it received either an IAPP from other 9150s or when it received the LLC frame through the LAN interface."
Regards
David
If you have an urgent issue please contact your Regional Technical Support Help Desk
Americas - Asia Pacific - EMEA
Hi David,
just a question: Is D137q newer than F192n?
thanks
francesco
Yes it is as Date codes follow the format <month code><day><Last digit of year><hour of build>.
F192n would have been built on June 19 2002 during the 13th hour, while D137q was built on April 13 2007 during the 16th hour.
The following article explains the date code that Psion Teklogix uses
community.psionteklogix.com/.../understanding-the-software-date-code.aspx
Do your 7035's have Lucent radios? If so, then if you are upgrading from F192n to the latest 9150 release, there could be a radio firmware upgrade required on the 7035's to maintain compatibility. Help Desk should have the details.
Cheers
Nick