Slightly different test, Meraki SSID, with a MBA13 running 10.10.5. I did a packet capture on the AP filtered for arp and used wireshark on the Mac with the same capture filter. I'm only tracking arp requests, since that's all I should see on the MBA. 100% arp requests sent OTA from the AP were seen by the MBA. But this is an older 11n MBA. I'll get my hands on an 11ac device tomorrow and rerun the test.
Is it possible you are in promiscuous mode in Windows? You shouldn't see the arp responses for anything that client didn't send, or in responses to the clients request unless promiscuous mode is enabled. which then isn't a fair test of what the laptop did or did not hear. Thanks Jake Snyder Sent from my iPhone > On Aug 3, 2016, at 9:47 AM, James Andrewartha <jandrewar...@ccgs.wa.edu.au> > wrote: > > 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/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
