I
- 7 Posts
- 0 Reply Likes
Posted 6 years ago
Primož Marinšek, AlphaDog
- 413 Posts
- 49 Reply Likes
I'd say it's a Motorola problem. It usually is.
- 6 Posts
- 0 Reply Likes
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
Devices like iOS and Android do support .11h and seamlessly follow channel changes when ChannelFly is enabled.
Michael Brado, Official Rep
- 3089 Posts
- 444 Reply Likes
For intermittent packet drops, try 9.5.3.0.44 available now under Downloads.
- 102 Posts
- 49 Reply Likes
Hi Michael, from your description it seems like the client is not roaming as quickly as it should. Some assumptions:
1. The scanner are set to operate on one band only, 2.4 or 5 GHz not auto
2. If using 2.4 the scanners are NOT 802.11b only
3. Your deployment has a good overlap (so an signal of no less than -65 dBm everywhere)
Base on those assumption and what you have indicated try the following:
1. Set the wlan to tunnel mode (this is recommended for handheld and phone)
2. Set the BSS min rate to something higher than the default so the scanner will get "out of range" while still able to communicate quite well and when looking for a new AP it should still get a good enough signal on the new AP and connect right away.
With a -65 dBm coverage it's safe to start with a BSS min rate of 12 Mbps. This wil make the AP send out management frames, such as beacon and probe response be sent out at 12 Mbps so the client can not get too far before it get out of range of a 12 Mbps radius of the current AP. Here are the command to set the BSS min rate for the wlan:
ruckus> enable
ruckus# config
ruckus(config)# wlan motoscanner
The WLAN service 'motoscanner' has been created. To save the WLAN service, type 'end' or 'exit'.
ruckus(config-wlan)# bss-minrate 12
The mgmt-tx-rate will be set to the same value as bss-minrate.
The command was executed successfully. To save the changes, type 'end' or 'exit'.
ruckus(config-wlan)# end
The WLAN service 'motoscanner' has been updated and saved.
Your changes have been saved.
ruckus(config)# end
Your changes have been saved.
ruckus#
- 5 Posts
- 2 Reply Likes
I have exactly the same issue (and the very same application is being used here also) [Michael.. could you confirm your encryption settings that you are using.. i.e. WPA or WPA2 for example?]
Currently tunnelled wlan with wpa/tkip is failing at one of our sites (the other site is setup identically without the random drop outs.
It appears that some of the devices will work fine when being used but when idle for x amount of time (CAM mode on and CPU performance activated) the devices stop passing IP traffic but both the unit and the zone director say they are connected with an IP address still visible but with failed pings. if you deleted the device from the monitor - currently active clients page the device reconnects instantly and allows in this case the telnet session to work (and pings!)
I will try and update the wlan profile to match the above post and report my findings tomorrow....
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
They are running latest 9.7 LCS and were already tunnelling with ofdm-only enabled. I have asked them to set bss-min rate to 12 to see if that helps and they were also going to test smart roam.
- 1 Post
- 0 Reply Likes
What was your resolution to this issue? I am currently experiencing the same.
I have another customer reporting similar issue with Windows CE Mobile 6.5 / Motorola MC9190. It seems when roaming between AP’s as they frequently do it upsets a Telnet connection to a server located externally through the internet. I have to renew their IP to get them communicating again although the ZD thinks they are still connected with excellent signal strength.
They are running latest 9.7 LCS and were already tunnelling with ofdm-only enabled. I have asked them to set bss-min rate to 12 to see if that helps and they were also going to test smart roam.
- 7 Posts
- 0 Reply Likes
First two assumptions are correct
I have updated the BSS and I will get back in 2 days.
- 6 Posts
- 0 Reply Likes
joe statter, Employee
- 2 Posts
- 0 Reply Likes
Michael Brado, Official Rep
- 3089 Posts
- 444 Reply Likes
if you were on a patch or LCS build. Frequent roaming and a hostonly, loopback
detected state could result in 10s silent periods or one-way audio for VoIP devices,
certain to also break any Telnet-based applications like Citrix, or RDP. That bug fix
is in both official releases.
And maybe for a Moto only environment, but I can't advise increasing DTIM past 5.
- 30 Posts
- 1 Reply Like
We have something very simillar, we run 65 handhelds across 11 AP and a zonedrirector (9.6.1.0 build 15). The handhelds are Win CE5.0, the network cards in them are BG. We run a web-based application through the built in Internet Explorer browser and we get a lot of "web page not found", the server sit's in the warehouse for this application.
We are planning an upgrade to 9.6.2.0.13 in the next few weeks hoping this will resolve our issues.
Julius
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
- Enable OFDM only and set BSS Min Rate = 12 on the device WLAN
- Upgrade to one of the version Michael mentions with some loop fixes
- Try setting a higher DTIM value on the APs for the device WLAN (seems 5 is recommended for Moto devices). This is currently a bit painful as you can't do it via the ZD WebUI so have to CLI to every AP and check you are applying it to the correct WLAN (if you only have 1 WLAN then its designator will be the same on every AP so you could do it with the ZD CLI remote_ap_cli command)
- Enable RTS-CTS protection on the WLAN
- 30 Posts
- 1 Reply Like
-Enable ODFM
-Enable RTS-CTS
I'm assuming that I would be able to use the following command to set the DTIM on the ZD CLI: remote_ap_cli –A “set dtim-period wlan2 1”
Where wlan2 is my wlan that all handhelds are connect on and the number 1 represents the DTIM setting I want which in my case would be 5?
Thanks,
Julius
Primož Marinšek, AlphaDog
- 413 Posts
- 49 Reply Likes
set ofdm-only : set ofdm-only {enable|disable}
-- Enable/Disable OFDM-only mode (exclude 11b CCK rates)
Sure hope RW will make it a global feature, not just per WLAN
About enabling RTS-CTS, I'm not too shure, but I think it's this
set rts-thr : set rts-thr {disable|}
-- Modify Request to Send threshold
You need to set a threshold. I would set it at size just below what your handhelds are sending data at so it will kick in.
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
Login to ZD CLI - "en"able mode - "config" mode - "wlan xxx" (wlan name is case sensitive)
"ofdm-only"
"bss-minrate 12"
"end"
"show wlan" to show the configuration is set.
In relation to remote_ap_cli –A “set dtim-period wlan2 1” that looks correct (with a 5 in your case). The only issue is that depending on how the APs are provisioned with WLANs (maybe different WLAN on different AP, provisioning order) they won't all necessarily be called wlan2. Note this is not the wlan name you give the wlan, but an internal wlan identifier - 2.4Ghz start at wlan0 and 5Ghz start at wlan32 (on later code releases). You can get get the wlan name-SSID mapping using "get ssid wlanx" i.e.
rkscli: get ssid wlan0
wlan0 SSID: Test
This way you will find what wlan name to use for each AP (if you are lucky it might be the same for all APs!).
In relation to RTS-CTS as Primož says its "set rts-thr {disable|}". Again you will need to know the correct wlan identifier. Generally the advice is to set the threshold to a size larger than max single frame size as you probably don't want RTS-CTS for all packets, just the larger ones that will use more airtime. In 11g the recommendation was 2346, but since 11n aggregation it supports up to 65535. I would change the other settings first, monitor and if still having issues then try RTS-CTS at 2340.
- 30 Posts
- 1 Reply Like
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
Format is "get ssid [wlanid]" i.e.
rkscli: get ssid wlan1
wlan1 SSID: motoscanner
What you need to do is to use this command to find the wlanid for the SSID that your scanners use and then use that wlan id in the command "set dtim-period wlan1 5". The wlanid may vary per AP for the same SSID, hence why you need to do it separately on each AP.
You can also use the command "get wlanlist" to list all the wlans active on that AP - this will help you know which wlanid you need to check in the 2.4/5Ghz bands.
- 3 Posts
- 1 Reply Like
Interface
ruckus> enable
ruckus# debug
ruckus(debug)# rksap_cli -A "set dtim-period wlan0 2”
ruckus(debug)# rksap_cli -A "set dtim-period wlan1 2”
...
ruckus(debug)# rksap_cli -A "set dtim-period wlan14 2”
ruckus(debug)# rksap_cli -A "set dtim-period wlan15 2”
ruckus(debug)# quit
Primož Marinšek, AlphaDog
- 413 Posts
- 49 Reply Likes
- 6 Posts
- 0 Reply Likes
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
You will need to find the right wlan ID to SSID mapping on each AP (get ssid wlanx) and set it via AP CLI when you find it. Remember you need to do it for both bands on dual band AP.
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
Format is "get ssid [wlanid]" i.e.
rkscli: get ssid wlan1
wlan1 SSID: motoscanner
What you need to do is to use this command to find the wlanid for the SSID that your scanners use and then use that wlan id in the command "set dtim-period wlan1 5". The wlanid may vary per AP for the same SSID, hence why you need to do it separately on each AP.
You can also use the command "get wlanlist" to list all the wlans active on that AP - this will help you know which wlanid you need to check in the 2.4/5Ghz bands.
- 6 Posts
- 0 Reply Likes
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
- 30 Posts
- 1 Reply Like
So I have upgraded to 9.6.2.0.13 this morning and implemented all the recommended setting, just to recap were:
*Enable-ofdm
*BSS min rate to 12
*DTIM to 5
I went onto the warehouse floor to test with our packers and things were not looking good, the wireless signal dropped by about 30% and the devices' were dropping off the network like flies and then taking a minute or so to reconnect.
I went back to my office and disabled "Enable-ofdm", went back onto the floor with the guys and there was no improvement. Back to the office and disabled "BSS min rate", that seemed to have done some good as the signal strength was back up and the devices were responding quicker and were not dropping off.
Currently DTIM is left at 5.
I am deducing from this that BSS min rate was not agreeing with our network, why would that be?
My question to everyone is if I enable Enable-OFDM would that work without BSS min rate, would it be advantageous or should I leave it off, what advantage would enabling Enable-OFDB bring?
Thanks for everyone's help so far.
Eddie Felmer, Employee
- 9 Posts
- 1 Reply Like
BSS min rate = 12 will set management frame rate at 12Mbps - this will effectively shrink the coverage area as higher data rate packets don't travel so far and probably why you were seeing less coverage. I wouldn't expect 30% difference in coverage, so your APs must be well spaced or there is high attenuation between them already.
- 30 Posts
- 1 Reply Like
I am going to try next week to enable OFDM-only and see what that does but I will be keeping BSS min rate off. But I think that the hand held units will not like OFDM-only.
We have 8 AP's in our ware house they are about 15-20 meters apart mounted on the roof, the roof is about 10 meters high. Is that too far apart? Should we get more?
Primož Marinšek, AlphaDog
- 413 Posts
- 49 Reply Likes
I think that's your problem right there. Unplug 4 of your APs and I things should get better straight away.
Primož Marinšek, AlphaDog
- 413 Posts
- 49 Reply Likes
Minimum rate of OFDM is 6Mbps (11g). If not enabled minimum rate is 1Mbps (11b).
By rasing min-rate you try and help the 9090 to change AP at a different time, i.e. distance from the AP. What I think others here are probably thinking is that maybe the 9090 are roaming either too much or too little and that's causing issues.
So we've told you to raise bss-minrate to 12, 18, 24 or higher to provoke 9090s into a roam at a better time (read: distance from AP), however you need to be careful because you actually don't shrink AP cell size with that, just the distance a 9090 will still connect at so you 'trick' your 9090 into a roam and hopefully another AP is there with enough signal to give the handheld 18Mbps when it decides to do that.
This however is highly dependent on what your 9090 does. Since you are using archaic handhelds things probably won't work as you'd expect and enabling OFDM only and raising min-rate will probably not change anything, like you've found out.
Another thing is how APs are placed. They might be spread to thin or too close. Either way you can run into problems. That's why proper installers take allot of care in designing a WLAN network. If they are smart, they even document stuff and give you all the measurements and everything.
The only thing that would make sense in this case is your DTIM setting which if I understand is helping, which is logical since that's rate-independent.
But there are greater and greater benefits of using OFDM. It has to do with the speed that some frames are transmitted at, cell-sizing, roaming, etc. Too much for this post, but the general rule now is to use OFDM only with higher minimum rates. Not applicable everywhere, but like 95% of implementations.
- 30 Posts
- 1 Reply Like
But the hardware is new but the OS is Windows CE 5.0 and network cards prefer to run in B only even though they are capable of G, we have had to use a registry setting to make them go to G.
I think that the network cards and OFDM disagree, I will give it a try but I don't think the technologies are compatible.
Primož Marinšek, AlphaDog
- 413 Posts
- 49 Reply Likes
Define "professionally surveyed". I've seen a 100 professionals that survey with eyes and at most an InSSIDer.
- 30 Posts
- 1 Reply Like
- 102 Posts
- 49 Reply Likes
1. Statically assign the channel, mapped out for best coverage/channel spacing.
2. Set BSS min rate to 12 -> client roamed before it got out of range
3. upgrade to 9.6.2.0.13 -> No more loop detect issue
Even after that there were still a few telnet disconnects, a lot less then before but still a few every now and then. Further troubleshooting and some coordinated packet capture seems to pin point the problem with the Telnet disconnects were occurring right about the time we saw lots of ARP packet being sent directly to the handheld. The ARP were for something completely different, but it was a unicast to the handheld.
It turned out that this environment did not have many clients so the Multicast to unicast conversion was being done. I am not 100% sure why this helped, but it did, after disabling directed multicast, the handheld no longer dropped telnet. It might be the various APR packet were filing up it's ARP table entry or something but disabling Multicast to unicast conversion resolved the final issue. If you want to give it a try here is the commmand:
ruckus# config
You have all rights in this mode.
ruckus(config)# wlan HANDHELD
The WLAN service 'HANDHELD' has been loaded. To save the WLAN service, type 'end' or 'exit'.
ruckus(config-wlan)# no qos directed-multicast
The command was executed successfully. To save the changes, type 'end' or 'exit'.
ruckus(config-wlan)# end
The WLAN service 'HANDHELD' has been updated and saved.
Your changes have been saved.
ruckus(config)# end
Your changes have been saved.
ruckus#
Again this was only done once we eliminated the RF issue, the roaming issue and the Loop detected issue with an upgrade. A good coordinated packet capture would help clarify the issue.
Sid
Related Categories
-
ZoneDirector
- 2634 Conversations
- 776 Followers
-
Ruckus Indoor APs
- 1829 Conversations
- 752 Followers
-
Ruckus Outdoor APs
- 568 Conversations
- 383 Followers
-
General Wireless Questions
- 535 Conversations
- 359 Followers