Hi Yile, On Thu, Apr 12, 2012 at 3:26 PM, Yile Ku <[email protected]> wrote: > I have 4 nodes A,B,C, & D. I have A set to not directly connect to D. > Attached to D I have a web based camera. I have a laptop hooked to > node A that I can log into the camera using a browser. I can > connect to the camera okay going through node B. I shut off node B > and the video session dies. I assume that 802.11s would switch the > route of traffic to go through node C, but it doesn't appear to do > that. I tried settting the root node flag on both A and D but that > did not help. > > I tried pinging directly from A to the camera attached to D. Here is > a list of ping times: > 64 bytes from 192.168.0.224: seq=63 ttl=64 time=1.950 ms > 64 bytes from 192.168.0.224: seq=64 ttl=64 time=1.992 ms > 64 bytes from 192.168.0.224: seq=65 ttl=64 time=2.877 ms > 64 bytes from 192.168.0.224: seq=66 ttl=64 time=1.963 ms > 64 bytes from 192.168.0.224: seq=67 ttl=64 time=526.659 ms > 64 bytes from 192.168.0.224: seq=68 ttl=64 time=6.892 ms > 64 bytes from 192.168.0.224: seq=69 ttl=64 time=1.979 ms > 64 bytes from 192.168.0.224: seq=70 ttl=64 time=2.867 ms > 64 bytes from 192.168.0.224: seq=71 ttl=64 time=1.968 ms > 64 bytes from 192.168.0.224: seq=72 ttl=64 time=1.961 ms > 64 bytes from 192.168.0.224: seq=77 ttl=64 time=506.990 ms > 64 bytes from 192.168.0.224: seq=78 ttl=64 time=3.043 ms > 64 bytes from 192.168.0.224: seq=79 ttl=64 time=1.954 ms > 64 bytes from 192.168.0.224: seq=80 ttl=64 time=3.768 ms > 64 bytes from 192.168.0.224: seq=81 ttl=64 time=3.913 ms > 64 bytes from 192.168.0.224: seq=82 ttl=64 time=4.725 ms > 64 bytes from 192.168.0.224: seq=83 ttl=64 time=57.908 ms > 64 bytes from 192.168.0.224: seq=84 ttl=64 time=6.435 ms > 64 bytes from 192.168.0.224: seq=85 ttl=64 time=1.968 ms > 64 bytes from 192.168.0.224: seq=86 ttl=64 time=1.974 ms > 64 bytes from 192.168.0.224: seq=87 ttl=64 time=1.956 ms > 64 bytes from 192.168.0.224: seq=88 ttl=64 time=1.960 ms > 64 bytes from 192.168.0.224: seq=89 ttl=64 time=1.994 ms > 64 bytes from 192.168.0.224: seq=90 ttl=64 time=2.010 ms > 64 bytes from 192.168.0.224: seq=91 ttl=64 time=2.848 ms > 64 bytes from 192.168.0.224: seq=92 ttl=64 time=22.417 ms > 64 bytes from 192.168.0.224: seq=93 ttl=64 time=3.196 ms > 64 bytes from 192.168.0.224: seq=94 ttl=64 time=1.975 ms > 64 bytes from 192.168.0.224: seq=95 ttl=64 time=12.603 ms > 64 bytes from 192.168.0.224: seq=96 ttl=64 time=9.577 ms > 64 bytes from 192.168.0.224: seq=97 ttl=64 time=2.065 ms > 64 bytes from 192.168.0.224: seq=98 ttl=64 time=9.883 ms > 64 bytes from 192.168.0.224: seq=99 ttl=64 time=8.772 ms > 64 bytes from 192.168.0.224: seq=100 ttl=64 time=8.407 ms > 64 bytes from 192.168.0.224: seq=101 ttl=64 time=7.967 ms > 64 bytes from 192.168.0.224: seq=102 ttl=64 time=9.332 ms > 64 bytes from 192.168.0.224: seq=103 ttl=64 time=6.949 ms > ^C > --- 192.168.0.224 ping statistics --- > 104 packets transmitted, 72 packets received, 30% packet loss > round-trip min/avg/max = 1.917/32.764/526.659 ms > root@OpenWrt:/# ping 192.168.0.224 > PING 192.168.0.224 (192.168.0.224): 56 data bytes > 64 bytes from 192.168.0.224: seq=0 ttl=64 time=2.238 ms > 64 bytes from 192.168.0.224: seq=1 ttl=64 time=1.965 ms > 64 bytes from 192.168.0.224: seq=2 ttl=64 time=7.304 ms > 64 bytes from 192.168.0.224: seq=3 ttl=64 time=2.824 ms > 64 bytes from 192.168.0.224: seq=8 ttl=64 time=425.330 ms > 64 bytes from 192.168.0.224: seq=9 ttl=64 time=3.783 ms > 64 bytes from 192.168.0.224: seq=10 ttl=64 time=2.353 ms > 64 bytes from 192.168.0.224: seq=11 ttl=64 time=2.337 ms > > > The ping times vary greatly. why?
This is likely related to the path refresh timer. While an mpath is refreshing, it is marked as deactivated. We try to pre-empt this and it seems to work most of the time, but perhaps starting the path refresh 1 second before deactivating is not enough time? See mesh_nexthop_lookup() and hwmp_rann_frame_process(). > Also how can I get it to switch fast from B to C when routing from A to D? Does A never switch from B to C, or does it just take a while? If B never sent a peering close when shutting down, A will tear down the peer link after ~15 failed transmissions. Depending on the type of traffic, this might take a while. See ieee80211s_update_metric() in net/mac80211/status.c Patches welcome. Thomas _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
