Showing results for 
Search instead for 
Did you mean: 

Zebra Printers Passive Device Newer Cisco AP's


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 which is suppose to fix the problem. After an e-mail conversation with our Cisco SE this afternoon, he is still recommending that 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 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.

thanks again,



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 our goals to upgrade have been put on hold since 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.


The site is now running with no luck with the printers.


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 [interface name] [description] [STA IP address]"

Example: config macfilter add 00:01:02:03:04:05 1 my_interface "Zebra Printer"

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


Has anyone tried extending the controller's User Idle Timeout or WLAN Session Timeout to address this issue?


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.

My summary:

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"

Content for Community-Ad