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