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,