Javier, Thank you. That helps. I will run the script on my setup and try to figure out the problem.
Regards, Siva. On Wed, Sep 19, 2012 at 8:00 AM, <[email protected]> wrote: > Send Devel mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Devel digest..." > > > Today's Topics: > > 1. long delay in link recovery after a link loss > (Sivateja Patibandla) > 2. Re: long delay in link recovery after a link loss (Javier Cardona) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 18 Sep 2012 17:39:50 -0400 > From: Sivateja Patibandla <[email protected]> > To: [email protected] > Subject: long delay in link recovery after a link loss > Message-ID: > <CA+LeHHHx15FcyShMJ4b2-C9NJyg93f7ypp42LjO9aUJBO3=r...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Guys, > > I'm working on setting up a mesh network with multiple unmanned aerial > vehicles. I'm working on Ubiquiti bullet 5 Ghz module. The hardware is > AR2313 with ath5k driver. I'm currently doing testing with just two > nodes (one is plane and one is ground station) being setup with . The > problem I've noticed today is as follows: If A (ground station) and B > (plane) are communicating and suddenly B goes out of range. Though, B > comes back immediately in the range. Both nodes can't communicate to > each other for at least a minute. The traffic is all UDP traffic. I > had this problem in the lab environment too. I could only get the > connection back by restarting the node B in lab environment. In the > tests that involved using proprietary firmware of Ubiquiti in access > point and station mode, there was no such delay in the link recovery > after failure at all. Any comments on this problem will be > appreciated. > > Regards, > Siva. > > > ------------------------------ > > Message: 2 > Date: Tue, 18 Sep 2012 15:41:06 -0700 > From: Javier Cardona <[email protected]> > To: [email protected] > Subject: Re: long delay in link recovery after a link loss > Message-ID: > <capjqad_ows9ess1u-xe1gnggfk0wfxupgxcxbn6b7ncpayr...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Sivateja, > > On Tue, Sep 18, 2012 at 2:39 PM, Sivateja Patibandla > <[email protected]> wrote: >> Hi Guys, >> >> I'm working on setting up a mesh network with multiple unmanned aerial >> vehicles. I'm working on Ubiquiti bullet 5 Ghz module. The hardware is >> AR2313 with ath5k driver. I'm currently doing testing with just two >> nodes (one is plane and one is ground station) being setup with . The >> problem I've noticed today is as follows: If A (ground station) and B >> (plane) are communicating and suddenly B goes out of range. Though, B >> comes back immediately in the range. Both nodes can't communicate to >> each other for at least a minute. The traffic is all UDP traffic. I >> had this problem in the lab environment too. I could only get the >> connection back by restarting the node B in lab environment. In the >> tests that involved using proprietary firmware of Ubiquiti in access >> point and station mode, there was no such delay in the link recovery >> after failure at all. Any comments on this problem will be >> appreciated. > > I have no explanation for your observations. All I can say is that > the protocol should be able to handle the scenario you describe. If > you are willing to investigate this, you could start by simulating > link losses with hwsim and you should observe that flows are > reestablished as soon as the link is recovered. > > What follows is an excerpt of one of our tests: > > for i in `seq 1 5` > do > echo -n `date +%s` Breaking link: > echo 0 > /sys/kernel/debug/ieee80211/${PHY0}/hwsim/group > ping -q -I mesh0 192.168.77.11 -c 20 -i 0.1 -w 1 | grep loss | > cut -d, -f 3 > sleep 1 > echo -n `date +%s` Restoring link: > echo 3 > /sys/kernel/debug/ieee80211/${PHY0}/hwsim/group > ping -q -I mesh0 192.168.77.11 -c 20 -i 0.1 -w 1 | grep loss > | cut -d, -f 3 > done > > And this is the output we observe: > > (...) > 10 packets transmitted, 10 received, 0% packet loss, time 905ms > rtt min/avg/max/mdev = 0.123/0.274/1.235/0.324 ms > 1348007532 Breaking link: 100% packet loss > 1348007534 Restoring link: 0% packet loss > 1348007535 Breaking link: 100% packet loss > 1348007537 Restoring link: 0% packet loss > 1348007538 Breaking link: 100% packet loss > 1348007540 Restoring link: 0% packet loss > 1348007541 Breaking link: 100% packet loss > 1348007543 Restoring link: 0% packet loss > 1348007544 Breaking link: 100% packet loss > 1348007546 Restoring link: 0% packet loss > PASS > > Hope that it helps. > > Javier > > -- > Javier Cardona > cozybit Inc. > http://www.cozybit.com > > > ------------------------------ > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel > > > End of Devel Digest, Vol 7, Issue 17 > ************************************ _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
