[Babel-users] the costs of periodic disassociation in conventional ap/sta mode

[Dave Taht]

In the new lab I ended up connecting up a bunch of machines in sta
mode over wpa... (partially because adhoc was unavailable - and
*mostly* because that's what normal homenet users would do, and lastly
because it improved throughput by 50x in some cases)

... with bad results for babel behavior in general, that I am
gradually trying to reduce the impact of (as well as observe what
happens to other protocols, tests, and daemons). It doesn't help that
I'm also trying to make a major change in how wifi is queued
underneath... Anyway, to summarize two out of three and add a new
one...

A) Powersave enabled caused stas to drop off the net by missing multicast.

There was a few patches that went by on the kernel list recently that
might have fixed a beacon offset problem, which I haven't tested.

good fixes for this problem include rigorously testing for it and
fixing on all the chipsets in the world, or having babel be aware it
is in powersave mode and using a bit of unicast, or something, to keep
itself alive.

B) Network Manager triggered scans were devastating[1],
and even after locking  to one bssid as suggested on the relevant
thread: http://blog.cerowrt.org/post/disabling_channel_scans/

[wifi]
bssid=04:F0:21:1F:36:E2
mac-address-blacklist=
mac-address-randomization=0
mode=infrastructure
seen-bssids=04:F0:21:1F:36:E2;
ssid=FQCODEL

I still had some trouble with babel, which I think I managed to see in
the small with

C) EVEN after putting this in place (which definitely makes things
better) - on anther machine I am periodically disassociating on
another interval for no reason I can discern (yet) - and since last
night, I was logging babel's behavior thoroughly... this is what that
does to babel.

I am pretty sure that events like this trigger a bit more routing
traffic and jitter of babels states, than is desirable, (and maybe not
enough, the link is essentially down on both sides) but did not
capture the traffic in these  cases, and for all I know there are
daemon or kernel mods that can make dropping out of the multicast
group, losing the local addresses, forgetting the channel, and then
coming back online a little less hard on everything.

...

Interface wlp2s0 has no link-local address.
Couldn't determine channel of interface wlp2s0: Invalid argument.
Interface wlp2s0 has no link-local address.
Couldn't determine channel of interface wlp2s0: Invalid argument.
Interface wlp2s0 has no link-local address.
Couldn't determine channel of interface wlp2s0: Invalid argument.
Interface wlp2s0 has no link-local address.
Couldn't determine channel of interface wlp2s0: Invalid argument.
Interface wlp2s0 has no link-local address.
Couldn't determine channel of interface wlp2s0: Invalid argument.
send: Cannot assign requested address
Interface wlp2s0 has no link-local address.
Couldn't determine channel of interface wlp2s0: Invalid argument.
send: Cannot assign requested address


[1] Saying the friends don't let friends use network manager is not
good enough. Documenting how to work around it, or thoroughly fixing
network manager - or the device drivers - would be better.

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org