Wireless Access

After replacing most of the Symbol AP and POE hubs in the warehouse with IAP215's controlled through the AW-25, Zebra QL320 mobile wireless printers no longer connect.  Once they're brought in range of one of the old Symbol AP's, they connect and print. 

 

We're using MAC authentication, but I added the MAC addresses from all of the 320's by clicking on the Users link on the Security tab.  Doesn't seem like an authentication issue, though.  Will this system work with devices that only use older 802.11a/b/g implementations?

See if the older system had 802.11d/h enabled.

Haven't found settings for 802.11d or h (it's a Symbol AP3141 & over ten
years old).

http://community.arubanetworks.com/t5/Controller-Based-WLANs/Why-Motorola-MC2180-bar-codes-is-unable-to-connect/ta-p/184458

Try only the 892.11d/h settings first.

Thanks, I'll give it a shot, test it, and let you know...

Enabled d/h, but it didn't help.

Any chance the problem is an authentication issue? I'd be willing to disable MAC authentication if it got them working, but I'd rather not if I didn't have to.

 

Also considering adding back a few of the old Symbol AP's to the network.  What kind of issues could doing that cause?

hard to predict, but why not just try, first an open SSID, then add WPA2, then ...

 

see where it fails or if it already fails directly

 

putting the symbols back will probably cause issue when a client jumps from them to an Aruba one.

 

also i would advise you to work with support on this, they can better troubleshoot with you then us via a forum.

What do you have for your 'mac auth profile' ?

Are you able to try for a giggle a user derivation rule based on the mac instead of the mac-auth?

 

http://www.arubanetworks.com/techdocs/ArubaOS_6_4_1_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/Firewall_Roles/User_Role_Assignments.htm%3FTocPath%3DRoles%20and%20Policies|_____3

 

 

Contacted the vendor about it, and they've opened a support case. The
vendor's stumped, too; wish it worked but somewhat relieved that they
couldn't figure it out. Don't feel like as big of a dummy if they company
that does this kind of thing for a living couldn't figure it out, either
;-).



The senior engineers are supposedly looking into it; vendor rep suspects a
code revision on the controller might be needed due to the age of the
printers...



This message has been scanned for malware by Websense. www.websense.com

Replied via email but don't see it here yet; here's what it said:

 

We contacted the vendor that sold us the system.  They couldn't resolve the problem either, and they've opened a support ticket.  According to the vendor, the senior engineers at looking into the issue.  Vendor suspects a code revision on the controller might be needed due to the age of the printers...

These are IAP 215s, right?  What version of IAP Code are you running?

 

 

show version
Aruba Operating System Software.
ArubaOS (MODEL: 215), Version 6.4.2.6-4.1.1.7
Website: http://www.arubanetworks.com
Copyright (c) 2002-2015, Aruba Networks, Inc.
Compiled on 2015-05-27 at 07:44:12 PDT (build 50209) by p4build

I know this is an old thread, but we just solved our longtime Zebra printer connecting problems.

 

We're running iAP-OS 6.4.2.6-4.1.1.8.

 

Our printers would work or not work somewhat unpredictably.

I started checking firmware versions and found that on version 20 firmware they worked on iAP 104/105 networks and failed on iAP205/275, while older version (18 or 19) work fine on either.

 

I opened a ticket with TAC to see what was different from 105 to 205 that might cause this, and they gave me this reply:

We have seen similar issue with Zebra printer running running V20  firmware version. Could you check this  and if possible try downgrading the firmware.

The "fix" of downgrading the printers works, but it impractical for us to do quickly, so we went with the "fix" from the iAP of turning on "legacy-mode" in the RF settings at those stores which have V20 and iAP 205

 

The long answer from TAC (for the technical minded):

The issue that we found in v20 was related to AMSDU frame aggregation. We saw that the v20 client did not respond to ADDBA (add block ack)request frames from Ap during BA negotiation. The fact that they worked on 105 is because AP 105 does not allow A-MSDU frame during aggregation. Other had 205 does allow this .Per standards the AP can inform this by setting the field in the ADDBA frame. This works fine on all clients but seems to be problems with v20 ones. 

You should try disabling MPDU aggregation on the AP which will most likely make them work with 205.