Motorola MC9090 handhelds and 7363 Access Points with Zone Director

  • 4
  • Question
  • Updated 3 years ago
I have 4 motorola handheld guns roaming between 6 overlapping 7363 access points with Zone Director 1100. The guns are running a simple wavelink telnet application. They are sitting on a separate open WLAN with no authenticaion but with an MAC ACL. Intermittently, the guns are having problems re-establishing a link to the access point(bars that indicate signal strength go from full to none, and the handheld indicates that it lost connection with the server), even though they are within the range of them. It doesn't happen often but its annoying enough. It usually takes 10 - 20 seconds to re establish a link. What settings should I check? Thank you!

I
Photo of Michael Daracz

Michael Daracz

  • 7 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 4
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
I would save a debug log, and AP logs and open a case at ruckus, but I'd also turn on a packet capture and try and analyze some packets.

I'd say it's a Motorola problem. It usually is.
Photo of Ray

Ray

  • 6 Posts
  • 0 Reply Likes
I am have the same thing going on with the Motorola MC9090 handhelds and have not found a way to get it working. Any help would be nice.
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
Do you have ChannelFly enabled? If so the Moto devices don't support the 802.11h pre-emptive channel change notification and so when the AP changes channel the symptoms are that the device will lose wireless connectivity for 20-30 seconds. If this is the cause then either just use background scanning for channel change of static channel plan (of course you should know your RF environment to do this so that you are not placing APs on channels where there is interference!).

Devices like iOS and Android do support .11h and seamlessly follow channel changes when ChannelFly is enabled.
Photo of Michael Brado

Michael Brado, Official Rep

  • 1893 Posts
  • 269 Reply Likes
If the scanners only support channels 1/6/11, only use Background Scanning.
For intermittent packet drops, try 9.5.3.0.44 available now under Downloads.
Photo of Sid Sok

Sid Sok, Official Rep

  • 102 Posts
  • 48 Reply Likes
@Michael Daracz

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#
Photo of r0nnieb

r0nnieb

  • 5 Posts
  • 2 Reply Likes
jumping into the thread.... :)

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....
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
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.
Photo of Jamison Clark

Jamison Clark

  • 1 Post
  • 0 Reply Likes
Eddie,
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.
Photo of Michael Daracz

Michael Daracz

  • 7 Posts
  • 0 Reply Likes
@Sid Sok

First two assumptions are correct

I have updated the BSS and I will get back in 2 days.
Photo of Ray

Ray

  • 6 Posts
  • 0 Reply Likes
@Michael Daracz

Did you end up getting it working with the BSS update?:
Photo of joe statter

joe statter

  • 2 Posts
  • 0 Reply Likes
BSS Update wiil help in this case the biggest issue is the DTIM period you need to set the DTIM period to at least 5 on the WLAN the Motorola is associating to Moto recommend 10 also the short preamble could also cause issues
Photo of Michael Brado

Michael Brado, Official Rep

  • 1893 Posts
  • 269 Reply Likes
Both official ZD releases 9.6.2.0.13 (MR2) and 9.7.0.0.220 (GA) are now available
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.
Photo of Julius Kisielius

Julius Kisielius

  • 30 Posts
  • 1 Reply Like
Hi,

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
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
The things to try are:
- 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
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
You can enable OFDM only and configure the bss min rate in the ZD CLI per WLAN, rather than having to do it on the AP using set commands:
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.
Photo of Julius Kisielius

Julius Kisielius

  • 30 Posts
  • 1 Reply Like
Thanks very much Eddie and Primoz, will try these setting in the next few days, hopefully even over the weekend.
Photo of Ray

Ray

  • 6 Posts
  • 0 Reply Likes
It looks like "get ssid" is not a command.
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
Are you doing this on the AP CLI, not ZD CLI as mentioned above?
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.
Photo of Mathew sutton

Mathew sutton

  • 1 Post
  • 0 Reply Likes
Welcome to the Ruckus Wireless ZoneDirector 1100 Command Line
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
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
For excecuting commands on APs via ZD read this KB article

https://support.ruckuswireless.com/an...
Photo of Ray

Ray

  • 6 Posts
  • 0 Reply Likes
Is there any documentation in how to set the DTIM value in the command shell for the ZoneDirector?
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
You can't currently set DTIM (or RTS) via ZD, apart from remote_ap_cli which is not practical unless you know which wlan ID is on which AP as per my previous notes

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.
Photo of Ray

Ray

  • 6 Posts
  • 0 Reply Likes
It looks like "get ssid" is not a command.
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
Are you doing this on the AP CLI, not ZD CLI as mentioned above?
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.
Photo of Ray

Ray

  • 6 Posts
  • 0 Reply Likes
as stated in the first comment above it's the ZoneDirector CLI.
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
Its AP CLI command. You can't currently do it from the ZD CLI (apart from remote_ap_cli which is no use because the wlanid may vary by AP).
Photo of Julius Kisielius

Julius Kisielius

  • 30 Posts
  • 1 Reply Like
Morning everyone,

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.
Photo of Eddie Felmer

Eddie Felmer, Employee

  • 9 Posts
  • 1 Reply Like
OFDM-only will disable 11b (CCK rates) and set management rate at 6Mbps.

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.
Photo of Julius Kisielius

Julius Kisielius

  • 30 Posts
  • 1 Reply Like
Thanks Eddie,

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?
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
"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?"

I think that's your problem right there. Unplug 4 of your APs and I things should get better straight away.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
Well first you disabled OFDM, which should drop minimum bss rate from 6 to 1Mbps, so the disablement of bss-minrate shouldn't have changed anything. But I don't know what an AP actually does in this instance.

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.
Photo of Julius Kisielius

Julius Kisielius

  • 30 Posts
  • 1 Reply Like
Funny story that, our site was "professionally surveyed" and my apologies for some confusion we are not even using Motorola's we are actually using Touchstar Boston 8500 of Belgarvium fame, I am not sure if anyone is familiar with the company?

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.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
11g is OFDM (ERP-OFDM to be exact). The problem is most likely in the drivers that implement that, which is nothing new especially with handhelds and/or Win CE.

Define "professionally surveyed". I've seen a 100 professionals that survey with eyes and at most an InSSIDer.
Photo of Julius Kisielius

Julius Kisielius

  • 30 Posts
  • 1 Reply Like
;) Perhaps slightly more sophisticated than eyes only. They came in with an access point that they set up in various places and something that looked like an over sized tricorder from star trek, then they told us we will need 8 evenly distributed through our warehouse. No map, no readings, so here we are today.
Photo of Sid Sok

Sid Sok, Official Rep

  • 102 Posts
  • 48 Reply Likes
I ran into an interesting case that I just closed last week. It was also a Motorola handheld scanner and the initial problem with general disconnection, RF issue, roaming and telnet disconnects. We ran through the usual data gathering and found out the APs channel were changing, the clients were not roaming well and were leaving the old AP when the old AP can barely hear the client and so on. We even saw a "loop detected, host only mode" message and so on. To address issues as we found we did the following:

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