Thomas, Thanks for the reply. We have the four nodes in a lab fairly close together. So the way we disable a path is by doing a block on a peer, or turning off the node. So if we turn off a node it will take 15 seconds to find another path..? We are trying to simulate node A going out of range of node B and coming into range of node C to see how long the switching of the traffic route to the camera on D takes. I will try blocking the peering of node B to D and see if that makes the switch faster to route through C. I assume this is the best way to simulate the failure of the RF connection between A and B and the gaining of the RF connection between A and C... right?
Thx Y- On Thu, Apr 12, 2012 at 5:08 PM, Thomas Pedersen <[email protected]> wrote: > 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 >
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
