I have several customers who have problems setting up Zebra QL220 Plus printers on their Cisco Wireless network running 1231ag ap's. These printers are "passive" devices which do not actively send data. If you setup the printers with dhcp, they will work because they send arp broadcasts out to request an ip address. If you set them up with static ip addresses, the printers never generate any network traffic and the access point will never see the device. Zebra support says its a Cisco problem with passive devices and to contact Cisco. To my knowledge this is a true statement since this does not happen to any other ap manufacturer. Zebra has a workaround that installs a "ping" utility on the printer which actually generates arp traffic and the printer will then work. Does anyone have an idea what a true solution would be to have a passive device work on the newer cisco ap's.
Yes, we had this exact same issue that was a result of bug CSCse63908. After working with an engineer from Zebra he provided us with a workaround. The solution was to a custom INDEXWMK.WML and PING.LBL file that were set to send a ping out from the wireless printer to a bogus address every 10 seconds when the LCD screen refreshed.
The Zebra case number for this incident was # 555892
We have not upgraded to 188.8.131.52 which is suppose to fix the problem. After an e-mail conversation with our Cisco SE this afternoon, he is still recommending that 184.108.40.206 is the most stable code for our needs. We are currently still using the workaround provided by Zebra in December.
Thanks for responding. Yes the "workaround" from Zebra seems to be the only thing that works for now. The current site having the issue has updated their wlc 4400 to 220.127.116.11 and this did not fix the problem. They have a conference call with Cisco tomorrow where they are going to look at the controller config. I'll give an update tomorrow afternoon.
Cisco worked with the Wireless LAN Controller for two and half hours on Thursday and couldn't get it to work. I think were stuck with the Zebra "cisco bug" workaround.
Thanks for the update. What version of code do you happen to be running? We are running on 18.104.22.168 our goals to upgrade have been put on hold since 22.214.171.124 didn't work well with our Spectralink wireless phones. I have not been very trusting of new code releases to 'experiment' with a 4.0 version for production.
I recently dealt with a customer and reseller that experienced the same issue where the printers worked with DHCP but not Static IP. Below is the solution that was provided by Cisco--
Here is the complete workaround for your ready reference:
config macfilter add
Example: config macfilter add 00:01:02:03:04:05 1 my_interface "Zebra Printer" 126.96.36.199
config advanced macfiltering authentication disable
and on the WLAN
Enable mac filtering
Enable aaa override
The macfiltering and AAA_override have to be enabled on the controller WLAN profile, even though the AAA is not used.
A caveat to this is if your are using MAC Authentication then do not disable it in the CLI as recommended above.
The fix that Cisco implemented was to allow the IP Address to be assigned to the MAC. That fix was implemented in Controller code 4.1.171.x and up. Another possible resolution is to use DHCP with IP reservations on the DHCP server.
I am having the same issue. I am running 188.8.131.52 code on a 2106. I added a DHCP reservation for each printer and that seems to be a quick work around. But I am getting extreme latency and some dropped packets. Anyone else have this problem with Zebras?
Try manipulating the user idle timeout and the arp timer timeout. This will extend the duration between failures but not solve the problem overall. The issue is with the nature of "passive devices". PDs do not generate traffic unless used. Similar to passive RFID tags which use exciters to trigger traffic. In this case the traffic is triggered by a print job and the if the printer has not recently associated it can not print. The latency mentioned above is a direct result of a reassociation and reauthentication to the network. Up the user idle time out to 28800 and the arp to 1200. These should help with your problem.
Worked for me. My QL420 + Zebras are working good so far.
Used DHCP reservation instead of static
changed radius server timeout to 5 sec
changed user idle timeout to 28800
ARP to 900 (had problems with 1200)
unchecked- "enable session timeout" "require DHCP" and "Aironet IE"