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