Hi Siva,

On Fri, Oct 5, 2012 at 9:24 AM, Sivateja Patibandla
<[email protected]> wrote:
> Hi,
>
> I've made another observation about my link recovery problem. The following
> is the script that I used.
>
> while :
> do
>         time=$(iw dev wlan0 station dump | grep -A 1 '00:15:6d:ec:32:cd' |
> grep 'inactive time' | cut -d ':' -f2 | awk '{print $1}' | head -2)
>         if [ $time -gt 1000 ]
>         then
>                 echo "Link Lost"
>         prev_time=0
>         while :
>         do
>                 time=$(iw dev wlan0 station dump | grep -A 1
> '00:15:6d:ec:32:cd' | grep 'inactive time' | cut -d ':' -f2 | awk '{print
> $1}' | head -2)
>                 if [ $time -lt 500 ]
>                 then
>                         echo "Link Back"
>                         echo $prev_time
>                         break
>                 else
>                         prev_time=$time
>                 fi
>         done
>         fi
> done
>
> Case1:
> When the two nodes are connected in mesh mode. If I do "wifi restart" on a
> node which is connected to another node. Then the two nodes will be
> connected back again in less than 1 sec.
>
> Case2:
> When the nodes move away from each other so that the RSSi is over -102 dbm.
> Then there is no longer a link until node comes back in the range. The link
> recovery is really quick when it comes back in the range. This is when there
> is no UDP packets being sent. That is, no traffic. I've tested this by the
> above script. Where in, I monitor the "inactive time" continuously.
>
> Case3:
> I the presence of UDP traffic. When the nodes move away from each other so
> that RSSi is over 102 dbm. There is no longer a link, like in above case,
> until the node comes back in the range. But, the special problem here is
> that, although the node2 (which moved out of range) comes back really quick
> in less than 5 sec. The link is not recovered until 1 min.
>
> The same tests when done with AP and STA mode in openwrt, the link recovery
> happens pretty fast. Both in the presence and absence of UDP traffic. So,
> the summary of above tests is that, when the nodes are configured in mesh
> mode and when there is UDP traffic flowing through the nodes. The link
> recover is slow when the nodes move out of range of each other and comes
> back in range. Link recovery when there is no UDP traffic is fast. Also,
> link recovery when then nodes are restarted is also fast.
>
> Any suggestions would be really appreciated.

When one peer moves away without any data flowing, the peering  state
is not actually moved  from ESTAB. Can you verify this by checking the
"mesh plink:" output from the station dump? If not, we should probably
expire a peer we haven't seen any beacons from in a while.

On each transmitted unicast frame, ieee80211s_update_metric() is
invoked from net/mac80211/status.c. If there are enough failed
transmissions (with a weighted average), the peer link is broken with
mesh_plink_broken(). However, It looks like this function deactivates
the mpath, but doesn't actually reset the peer link either! LIkely
your problem is in how we deactivate, then reactivate the mpaths.
Please supply more clues with 'iw mesh0 mpath dump' once a peer moves
away.

Thanks!
Thomas
_______________________________________________
Devel mailing list
[email protected]
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel

Reply via email to