On Wed, May 31, 2017 at 01:25:36PM +0200, Mark Kettenis wrote: > > Date: Wed, 31 May 2017 11:53:19 +0200 > > From: Stefan Sperling <[email protected]> > > > > On Wed, May 31, 2017 at 11:23:07AM +0200, Mark Kettenis wrote: > > > Is the beacon interval always the same for all modes/hardware? > > > > It is defined by the AP. The value (in TU) is sent to clients in beacons: > > > > # tcpdump -n -i iwn0 -y IEEE802_11_RADIO -vv > > 11:50:23.170309 802.11 flags=0<>: beacon, timestamp 59648614784, interval > > 100, > > Then your change doesn't really make sense to me. Naively I'd say > that you would want to scale the missed beacon threshold based on the > interval. The current code may not do that properly, but your change > seems to move further away from that.
Sure, we can scale the value. Currently it is fixed but it need not be. I think the question of whether ieee80211com stores a beacon counter value or a time period is irrelevant to scaling. We can provide consistent behaviour across different wifi networks with either approach. Storing a counter seems easier to me because that's what the hardware reports when it sends a missed beacon event. The hardware does not report how much time has elapsed since the last beacon was seen. I'll try to come up with a diff to scale ic_bmissthres once an AP has been selected and the beacon interval is known.
