Wireless Access

Hello,

We have a customer having trouble with a device (a Brother HL-2135W printer with wireless connectivity) where it drops off the network after a period of time (the user's words).  The printer is pretty woeful when it comes to getting debugging information out of it.

The SSID in use is a special one we provide for use only in that particular customer's network and is in 'forward-mode bridge' (as the traffic stays in the customer network), unlike most of our virtual APs, which are in tunnel mode.

On more careful examination, the printer remains associated (when we look at the 'show ap association ...' list) and has an IP address in 'show user-table mac ...' but doesn't seem to respond to ARP requests from other hosts.

Manually adding the host's ARP entry on another device allows it to work but stops when we remove it again.  This makes me think that the device is going into some sort of low power mode where it doesn't respond to broadcast traffic, much as a portable device such as a phone.

I've read the "Optimizing Aruba WLANs for Roaming Devices" Validated Reference Design where this mentions turning ARPs from broadcast into unicast using 'broadcast-filter arp', but this doesn't work.

Does this command only work for tunnelled VAPs, where traffic is processed on the controller, and not bridged VAPs?

(Also, as an aside, what does it do for broadcast ARP packets - do they get turned into a number of unicast packets?)

Are there any other solutions which might work?

I cannot find an option on the printer to disable the printer sleeping its wireless interface.  Pinging the printer from a client seems to be OK as I assume the ARP entry is refreshed by unicast periodically, but that only works from a particular client.

Thanks in advance,

  - Bob

For bridge-mode ssid you should not have 'broadcast-filter arp'.

I had exactly the same issue with printers as well on a customer's site who were using bridge-mode.  Pretty much exactly the same symptoms you described.

@Michael_Clarke wrote:

 

> For bridge-mode ssid you should not have 'broadcast-filter arp'.

 

What is the effect of doing this on a bridged SSID?  Do you mean it has no effect, or it actually breaks things?

 

 

> I had exactly the same issue with printers as well on a customer's site who were using bridge-mode.  Pretty much exactly the same symptoms you described.

 

So does disabling it fix things?  If so, how?  Surely turning it off just means that ARPs will remain as wireless-level broadcasts and so be ignored by the printer, when it's sleeping?

Yes, it breaks it.  This is from the CLI guide,

Do not enable this option for virtual APs configured in bridge forwarding mode. This
configuration parameter is only intended for use for virual APs in tunnel mode. In tunnel mode, all packets travel to the controller, so the controller is able to convert ARP requests directed to the broadcast address into unicast.  When a virtual AP is configured to use bridge forwarding mode, most data traffic stays local to the AP, and the controller is not able to convert that broadcast traffic.

Disabling that option on your bridge-mode ssid will fix it.

I assume by "the controller is not able to convert that broadcast traffic" means that it will be dropped as the AP can't do the conversion, not that it ignores the conversion and leaves it as broadcast traffic?  (As, if it did the latter, it would continue to work.)

Anyway - I have turned this off, as you suggested, and it seems to be working so far.  It takes a little while (perhaps overnight) for it to really prove things, so we'll see tomorrow.

I think part of what's caught me out here is that 'broadcast-filter arp' changed in 6.1.3.2 to be enabled by default: looking at our configuration, it's enable on lots of bridged mode VAPs, so they must have been set up since then.  I'm not sure why those are fine.

Thanks for your help.

I know it is enabled by default in 6.1.  What caught me out was upgrading the customers deployment from 6.0 to 6.1 a couple of years ago, which had the unwanted behaviour of enabling that on existing VAPs....some of which were bridged and purposely had that disabled.