cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9170
Views
4
Helpful
17
Replies

interoperability with Symbol APs and Motorola MC9090s

we are a food production company and have many sites with Cisco 1220,1230, and 1240 APs, we recently took over a warehouse with Symbol24 AP 4121, plus a number of MC9090 terminals and other scanners. being a Cisco shop we want to move across to Cisco APs, but I have heard that there are inter-operability problems between Cisco and Symbol( Motorola) wireless.

Can anybody comment?

17 Replies 17

Alex Stuart
Level 1
Level 1

In my limited experience, the MC9090's seem to work best with the AP1242's (the Cisco recommended AP for warehousing) - There was a particular issue between the older 1200 series AP's and MC9060's with roaming, but the 1242's don't have this issue. In the two installs I have been involved in, the MC9090's with the latest fusion drivers work well with the AP1242's (aren't the Symbol cards now CCX compatible?). However, if running autonomously, the Cisco AP's need to have 802.11d turned on, something to do with the different way Cisco and Symbol implement this standard. Hope this helps.

nick-davies
Level 1
Level 1

we have install 1242AG with a 4404 controller and are having issues with the Symbol MC9090, telnet sessions are locking-up but the layer3 is ok , we have upgraded the fusion client have you deployed yet ?

No we are still at the tender stage for a new bin tracking system for the factories, but in some factories we have existing Cisco APs, most of the responses have been using Symbol APs which of course do not have any problems with MC9090, but being a Cisco shop we would like a Cisco solution

Hi All,

btw, there is an known Issue with MC9090 and other Scanners with 802.1x Authentication and Cisco WLAN Controllers:

FAQ: Why Are DS Terminals Unable to Authenticate to a Cisco WLC Using 802.1x?

Fusion based and Mobile Companion based wireless DS terminals may be unable to authenticate via 802.1x to a Cisco WLC (Wireless LAN Controller) or Cisco Aerospace Controller operating on firmware version 4.x.xxx

o There is a known issue (to Cisco support engineering); Motorola (Symbol) marketing chose not to become CCX compliant and instead decided to reengineer the radio driver supplicant code to support EAP key index 3; this code value became standard within the supplicant portion of the driver. When these terminals were integrated to the latest Cisco WLC operating on firmware version 4.x.xxx, the controller configuration was required for change to the EAP key index value from 0 (default) to 3.

The required WLC configuration change was:

Config advanced EAP key-index 3

Regards, Michael

Hi

Where is this setting on the 4404 controller ? , also did this issue cause application lockup not layer 2/3 failure

rgds

Hi Nick, this is configurable only via Controller CLI. Not sure what you mean with "application lockup", this Issue prevents you from authorizing via 802.1x. Regards, Michael

Hi Michael

Bsically the main issue is the we get an extended X-Wait telnet client accessing an AS400 system, the terminal can still be pinged on its static IP address but the telnet session locks , no disconnection happens between the controller and the client , we believe the issue to be the upper layers and not a wireless RF issue.

The sypmtom you describe can be caused by several factors. You could try the following:

These are the changes made to the RF controllers...

Security => Credentials cashing enabled (leap credentials)

Improves roaming performance

Wireless => Global RF 802.11b/g

changed 11Mbit from mandatory to supported

Apparently there is a known issue with 11Mbit beacons,

disabling them also assists in better roaming.

Also, disable the slower speeds on the network such as 2mb and 1mb. You do this similar to the 11mb setting.

Thanks Dennis

I'll give this a try

Other recommendation made from Symbol/Motorola include

(2) Potential Issue - Potentially the Wolsey Self Healing product could be causing issues with AP power being too low. This was an issue we have experienced in the past. Recommendation - Investigate Wolsey Self Healing product and remove/disable if this proves to be an issue.

(3) Potential Issue - Potential issue with Short Preamble. Recommendation - Change settings on AP's to long preamble should resolve.

(4) Potential Issue - Potential issue with Aps using DHCP rather than static IPs. Recommendation - Set AP's to Static IP addresses.

(.

Could you comment on the validation of these statements in your opinion

Preamble could be an issue but not likely. Usually what happens in this situation is that the gun roams from one AP to another and the delay in this causes problems with client server applications even though the gun stayed connected to the AP. The actual client server session times out.

I work for Plastipak Packaging. We are a very large Cisco / Symbol organization. Our warehouses use the Cisco 1242's and upgraded 1200's in lightweight mode with the 4402 WLC's. I have noticed problems with the PDT's and the VRC's that we have. This discussion has helped me out with the devices that I have here. Many of the VRC6946's, 802.11b scanners that I have here have old drivers and are quite picky in the warehouse wireless environment. I just recently did a test with the 11MBPS data rate as mandatory, the rest supported and I noticed with a packet sniffer that almost all of the encrypted packets had decrypt errors 5.5MBPS and above. In response to this I set the 2MBPS data rate to mandatory and the rest supported. All of the lock up, freezing, going to sleep, and out of range errors that I noticed on the previous config went away! Woo Hoo! Maybe it is a problem with the beacons and the higher data rates like what was mentioned previously... I'm not entirely sure, but here are the settings that I used for the 802.11BG network...

preamble = long

(some older symbol radios need this! T1 and T2 radio difference)

DTIM = 10

Aironet Extensions = OFF

Set 2MBPS data rate to mandatory, the rest supported or disabled depending on preference..

This was also with the 4.1.185 WLC code

I'm a bit shocked to hear that the MC9060's and MC9090's have a problem. I do not see the problems with mine here. I have a test MC9060G...

My problems have been with the MC9060 not roaming well into an area with 1242's. The MC9090's work fine. I'm going to try some of the data rate changes.

Wow, I'm not the only one having issues with Symbol 9060s and 9090s

I work in a tire manufacturing plant, and we recently migrated to LWAPP. Our problems began with the MC9060 "roaming" issue. This was resolved by installing the latest Mobile Companion software. The most current build is 91. You can get it from the Symbol Support site....go to the "developer zone" and from there navigate to the "BetaZone". I pushed out the package with Avalanche, and everything was fixed.

Now we are having an issue where the APs lock up...well not really. Our 9060s establish a TCP session with a server and do their thing...during the outage, 9060s will send SYN packets to get TCP started...the server responds with a SYN/ACK, but the 9060 never sees it and continues to send SYN packets. Rebooting the controller fixes the issue.

Regarding 1242 APs, I do have some on our 2nd and 3rd floors mixed in with 1231 APs. I have not had any issues with roaming on these clients. If you haven't already, I suggest upgrading Mobile Companion to Build 91.

These settings are all well and good if all you're using are Symbol handheld scanners, but they go against all of the high-performance features that a multi-purpose WLAN demands for voice and high-throughput low-latency applications. Somebody at Symbol needs to wake up, smell the new standards, and change (out) their radio hardware, or suffer the consequences of lost platform revenue.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: