Wireless Access

Hi All,

 

We're in the middle of deploying Airprint using AOS 6.3.1.6, with AirGroup enabled. We've had mixed results in our testing since going live. Initial tests were successful, but after time we'd find the dedicated printers were no longer available for selection to various iOS devices.

 

Upon checking the Airgroup section on the Dashboard the printer was no longer displaying a hostname, just two dashes. We have our printers in a dedicated user role, plugged into AP-93H's, and when we disable then re-enable the wired port, the printer hostname comes back and on most occasions we can then print again.
.

We are not using Airgroup domains, we're just trying to establish Airprint for all users who share the same local controller as the wired printer.

 

Any experiences or advice would be appreciated.

 

Regards

 

Matt

Are these by chance HP printers? I and a few others have encountered a bug that TAC confirmed. In our case after a period of time (30 minutes I believe) the device was no longer discoverable by devices. I haven't checked to see if it's resolved in 6.3.1.7.

The printers in use are Kyocera. I'm going to test 6.3.1.7 today in our lab environment to see if it improves things.

 

cjospeh - Is there a way for us to see if this bug is affecting our scenario? Are there any show commands that we could run which would highlight this?

The symptom is like you described - The name of the printer would be replaced by other characters or another name that is usually another mac host in the network that is on the same subnet.  If you upgrade it should stop.  That is the main symptom.  We have really only seen this problem with Apple TVs, but we do not hav enough information about if it has been seen with printers;  If the name is being replaced by another, that is the biggest thing.

 

Thank you for the quick feedback. We have tried extending the idle time out in the user role, which helped the issue, but obviously this just prolongs the issue (we set it to 30mins for testing purposes).

 

I'll try the upgrade in the lab and see how we get on.

I am not sure the idle-timeout should help if you are running into the situation that is fixed in the bug.  One device sleep-proxies for another device that has wake-on-demand enabled and the record is replaced.  When we try to refresh the printer, the record is replaced by the new device and we no longer advertise information for the previous host.  

 

Information about bonjour sleep proxy is here:  http://support.apple.com/kb/ht3774   Essentially if you have a mac on the same subnet that has wake-on-demand enabled it will do that.  Normally if the record is replaced, it is replaced by the name of the device that has wake-on-demand enabled.  Turning off wake-on-demand on that mac should fix the issue without upgrading.   

 

The fix does not allow the record to be replaced for a printer or other Airgroup servers by a mac that is configured with wake-on-demand...

 

I am not sure that is what you are encountering, but based on your symptoms, that is my best guess..

Your suspicions were correct. I upgraded to 6.3.1.7 and tested, after the default 10min idle timeout the Airprint server was removed from the list. I then tried to connect to the printer again and experienced the same problem, so it does not appear to be related to this bug.

Okay.  Is the printer wireless?  If so, what type of authentication is used?

 

No the printer is connected via a wired port on an AP-93H using MAC authentication

Okay.

 

So is our challenge just trying to keep the printer in the user table?  If it gets removed from the user table, then airgroup will not work of course.   Did you experiment with putting the printer on a trusted port on the AP93H and not using mac authentication?  It is quite possible that the printer does not talk much or at all, once it comes up, so it ends up aging out.

Guys, I believe I was the first one to see the HP/AirPrint/AirGroup bug and report it to Aruba. I can't beleive that it hasn't been fixed yet. We had to resort to using Printopia until the issue is fixed.

Derbystar16,

 

Are we talking about the same thing?  The user in this thread cannot keep a device that is using wired  mac authentication in the user table.  That would be a prerequisite to using Airgroup.

 

Can you describe details of your bug and maybe the case number so we can determine if it is related to this and/or being handled?

I haven't tried removing those two, only because we require security at the port level.

 

We have found that if we ping the printer whilst it is active, during the timeout window, it will keep the printer 'alive'. We are looking at setting up a scheduled task to achieve this until we can find another way.

 

A quick search on the forum suggested we could disable the idle timeout by setting it to 0, but unfortunately this isn't true.

M-W,

 

You don't want to set the idle timer to zero because users will NEVER age out of the user table and you will get an artificailly inflated version of your network, because users will seem to be connected for days.  

 

You can type "show airgroup cache entries" a number of times to see the last time your printer checked in.  It is possible that it is getting aged out because it is not chatty, or your success role for mac caching is not permissive enough to allow the advertisements that the printer needs to stay in the cache.

Our policy allows the clients and the printers to talk to UDP 5353 on 224.0.0.251, as well as communicate to each other on any port, so it's not that restrictive. Is there any other traffic I should be aware of that could be causing the idle timeout?

 

I certainly think the devices are not very chatty. So we're having to come up with ways around that to keep them active enough not to timeout.

M-W,

 

It could be something else that is being blocked.  Please try allowall and see if there is any difference.

 

Do you have any update on this? We are seeing the same thing here. We have been testing AirPrint from two iPads, one on our production network, and one connected to a Netgear router. After the printer falls off/ages out, if we attempt to print from the Netgear router, it wakes the printer, and then we are able to print from the other iPad on our production network but not vice versa.

 

We are running 6.3.1.8 on the controller and 6.3.4.64924 on the ClearPass VM.

Hi rmcleod,

 

In the end we fixed it by polling our printers a little more often via snmp. Our print server already polled them for ink levels etc, so we brought the time to within the inacticity window and this kept them 'alive'. Not an exact fix I know, but it worked for us.

Thanks for responding. Our "printer" is actually a UniFlow print server with an AirPrint service running on it. The server itself is online all the time and never drops pings, but I will look into SNMP polling on it as there's currently none. Right now I'm stuck in the middle of the copier company and their tech support, and Aruba's. I still feel like it's a problem with the service on the server, but there's obviously something with Aruba that is either being blocked or dropped after a certain time. I'm waiting on a call back from TAC now...I'll update if I make any progress!

Bug 96236 in the ArubaOS 6.3.1.7 Release notes

 

"