Simon, On 04/07/14 09:36, Simon Wong wrote: > I am guessing roaming might not > trigger a deauth on the client.
at least a disassoc should be sent. > In any case, we can't count on deauth > being received anyways. of course, but we should rely on the layer below being working consistently. > > Hypothesis: > It seems as if the wireless driver/hardware has an internal forwarding > rule. If the AP interface thinks it's got the client, it'll forward > data internally to it and batman never sees the data and thus can't > route it. this is exactly how AP mode is supposed to work: if source and destination are connected to the same interface unicast traffic will not be delivered to the upper layer but will directly be forwarded to the destination. > But since the roam happened and another node has picked up > the roaming client, translation tables updates are still triggered and > states are still synchronized. > > What do you think? > Looks like there is a problem at the wifi layer. batman-adv here is only playing the role of a generic Distribution System. The current behaviour would break any other backbone that you would have instead of batman-adv. The inactivity time getting reset when the client is connected to another AP is definitely a bogus behaviour and points towards a wifi problem. At this point I would suggest you to involve the linux-wireless guys (they also have their own mailing list) and to try describing the problem to them. What I can say here is that batman-adv seems to be unrelated.. Cheers, -- Antonio Quartulli
signature.asc
Description: OpenPGP digital signature
