Re: [B.A.T.M.A.N.] Roaming issues in basic network

Antonio Quartulli
2014-07-04T08:13:26Z

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]