nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Motorola MC9090 handhelds and 7363 Access Points with Zone Director

unknown

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

Find more posts tagged with

Accepted answers

All comments

unknown

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.

unknown

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.

Eddie_Felmer

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.

michael_brado

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.

sid_sok

@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#

unknown

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....

Eddie_Felmer

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.

unknown

@Sid Sok

First two assumptions are correct

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

unknown

Did you end up getting it working with the BSS update?:

unknown

@Michael Daracz

Did you end up getting it working with the BSS update?:

joe_statter

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

michael_brado

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.

unknown

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.

unknown

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

Eddie_Felmer

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

unknown

For excecuting commands on APs via ZD read this KB article

https://support.ruckuswireless.com/an...

unknown

Thanks Eddie, I will give this ago. I just need some info how to setup the following:

-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

unknown

Enable OFDM-only (per WLAN)

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.

unknown

Is there and documentation in how to set the DTIM value in the ZoneDirector?

unknown

Is there any documentation in how to set the DTIM value in the command shell for the ZoneDirector?

Eddie_Felmer

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.

unknown

It looks like "get ssid" is not a command.

Eddie_Felmer

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.

unknown

as stated in the first comment above it's the ZoneDirector CLI.

unknown

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.

Eddie_Felmer

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.

unknown

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?

unknown

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.

unknown

"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.

unknown

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.

unknown

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.

unknown

😉 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.

sid_sok

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