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

Simon Wong
2014-07-04T07:36:09Z

Antonio,

I haven't tried monitoring for deauths yet, but I have tried another
device for the AP interface (a USB stick using ath9k_htc, on wlan2). I
am able to repeat the same inter-AP roaming problem.

I was thinking this could have been a problem with the ath5k drivers,
but that seems less likely.

Another observation:
Let's say I'm roaming client 2 is attached to node A. I am monitoring
client 2 on node A via `iw wlan1 station dump`. If I turned off client
2 WiFi or switched SSID, client 2 disappears from the station list as
expected - a deauth probably got sent. I am guessing roaming might not
trigger a deauth on the client. In any case, we can't count on deauth
being received anyways.

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. 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?

Thanks,
- Simon

On Tue, Jul 1, 2014 at 11:22 PM, Antonio Quartulli
<antonio@meshcoding.com> wrote:
>
>
> On 02/07/14 07:58, Antonio Quartulli wrote:
>> Simon,
>>
>> On 02/07/14 03:24, Simon Wong wrote:
>>>
>>> - Even more strange with 'iw station get' during the problem:
>>> interacting with the Telnet connection from Client 2 to Node A will
>>> also reset the inactive time count for Client 2, and this is while
>>> Client 2 is roamed to node B. On node A, only the tx {bytes, packets}
>>> counters will increase. rx counts do not. On node B, the tx/rx counts
>>> increase as expected.
>>
>>
>> very stupid question: but the two nodes have different MAC addresses for
>> wlan1, right ?
>
> ehm, here I meant wlan0 (the AP interface where client connect to).
>
> --
> Antonio Quartulli
>