I tried DTIM 3 (after reading that blog post), but it didn't help, the laptop's wifi chipset still just went to sleep and missed packets. Plus, some vendors (eg Meraki, Ruckus) don't let you change it anyway. One thing Ruckus does do is broadcast to unicast conversion when an SSID has 5 or fewer devices on an AP, which masks the issue.
A quick way to demonstrate the problem is to have Wireshark running on a Mac with OS X 10.10 or 10.11, and another laptop (either running OS X 10.9 or Windows) connected to the same AP, and filter by arp. The first Mac will see between 10-40% of the ARP packets of the second laptop in my testing, depending on the load. James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 ________________________________________ From: The EDUCAUSE Wireless Issues Constituent Group Listserv <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Jake Snyder <jsnyde...@gmail.com> Sent: Wednesday, 3 August 2016 8:56 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] How big are your wireless segments? There was some talk about this with IOS a while back. Something about Apple wanting a longer dtim value (3 seems to be working for a lot of folks). Dtim of 1 seemed to give some grief. http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html?m=1 Thanks Jake Snyder Sent from my iPhone >> On Aug 2, 2016, at 9:04 PM, James Andrewartha <jandrewar...@ccgs.wa.edu.au> >> wrote: >> >> On 02/08/16 04:19, Peter P Morrissey wrote: >> Given my understanding of the way arp works, not sure I understand how >> it is possible for a large subnet to cause a client arp table to become >> exhausted unless that client for some reason is directly communicating >> with all of the other endpoints on the large subnet. >> >> My understanding is that the table is only populated in response to arp >> queries that the client has initiated, even though it can “hear” >> responses from other clients that are sent as a broadcast. It is easy >> enough to verify this on Windows with an arp –a. >> >> I also don’t believe that broadcast traffic can have a material impact >> on clients these days due to increases in CPU power at the magnitude of >> Moore’s Law. > > Sadly there is no Moore's Law for batteries. OS X since 10.10 will > aggressively sleep and miss broadcast ARP packets. I have seen this on > four different AP vendors and have the wireless captures to prove it. > Generally it doesn't cause user-visible problems, and it can be worked > around by enabling proxy ARP on the APs/controller (if the vendor > supports it). > > It will most likely present problems if the clients are trying to access > servers on the same subnet and it's the *server's* ARP cache that gets > exhausted (or simply expires the client). The client will resolve the > server's MAC address OK, send the SYN packet, then the server will send > a broadcast ARP request to resolve the client's MAC address, which can > be missed by the Mac laptop. Depending on the level of broadcast > traffic, it can take a minute or more with retries before a connection > is established. > > For wireless designs where all data goes through the gateway and there's > no client communication to other devices on the same subnet you probably > won't notice a problem as the gateway's ARP cache will always be fresh. > We saw it because we have a campus-wide flat L2 network shared between > wired and wireless, and I also noticed a lot of ARP traffic from laptops > looking for Apple TV IP addresses. > > We have filed a ticket with Apple, radar://26488949 if anyone has any > contacts to escalate it. The fastest resolution we've had for any Apple > bug is 3 years, so I don't expect this to be fixed any time soon. > > -- > James Andrewartha > Network & Projects Engineer > Christ Church Grammar School > Claremont, Western Australia > Ph. (08) 9442 1757 > Mob. 0424 160 877 > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.