But what's the penalty on non-Apple devices?
-----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jake Snyder Sent: Wednesday, August 03, 2016 8:56 AM 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/.
