Hi Qasim, On Friday, June 1, 2012, Qasim Javed wrote:
> Queuing discipline functionality is only invoked from within > dev_queue_xmit. > > This function can be called in two possible cases: > > 1. When a source mesh station sends an IP packet it ends up calling > dev_queue_xmit so the queuing discipline is exercised on the source. > > 2. As a result of ieee80211_deliver_skb which in turn is invoked from > ieee80211_rx_h_data. > > So, basically when a mesh station is forwarding a frame, the qdisc > (even if installed on a mesh interface using tc) will not be > exercised. I had never thought about that. This means I cannot use > netem for introducing delay on the intermediate hops. > > Since wmediumd does not introduce delays, I guess my test case would > be probabilistic rather than deterministic. This is because, the bug > that I am trying to reproduce would only trigger if the PREQs arrive > at the target in a certain order as described previously. > > I will look some more into it and get back to you later. > > By the way, is it OK if I can show you a packet capture which clearly > demonstrates that the wrong originator sequence number is being used > in the PREP? A test script would help us ensure there are no regressions on this, but if it's going to be such a time sink, a capture will do. Adding delays to wmediumd is on the todo list. Thanks, Javier > Thanks, > -Qasim > > On Thu, May 31, 2012 at 3:24 PM, Qasim Javed <[email protected]> wrote: > > Hi Javier, > > > > I am trying to introduce delay on one of the links using netem qdisc. > > When I use netem on the source node, I can see the delay is added > > (verified using ping) but when I add it to one of the intermediate > > hops, the delay does not show up in pcap file. > > > > Logically the queuing disciplines should be invoked irrespective of > > whether a mesh node is forwarding traffic or not. > > > > I have wmediumd working fine for me, but I need a deterministic delay > > (in addition to the loss which makes the metric value for one of the > > paths higher, thus making it undesirable) on one of the paths to > > emulate the scenario in which the wrong usage of the originator > > sequence number (in a PREP) will be triggered. > > > > Any ideas? > > > > Thanks, > > -Qasim > > > > On Wed, May 30, 2012 at 7:08 PM, Qasim Javed <[email protected]> wrote: > >> Thanks. That will do. > >> > >> -Qasim > >> > >> On Wed, May 30, 2012 at 6:09 PM, Javier Cardona <[email protected]> > wrote: > >>> Hi Qasim, > >>> > >>> On Wed, May 30, 2012 at 2:55 PM, Qasim Javed <[email protected]> wrote: > >>>> Hi Javier, > >>>> > >>>> I have set up disto11s, but where do I access the existing hwsim test > >>>> cases that you have? > >>> > >>> Our test suite is not public but here is a template that should give > >>> you a jump start: > >>> https://github.com/cozybit/open80211s/wiki/HwsimTestTemplate > >>> As you will see, it is trivial to modify to test your scenario. > >>> > >>> Cheers, > >>> > >>> Javier > >>> > >>>> On Tue, May 29, 2012 at 12:59 PM, Javier Cardona <[email protected]> > wrote: > >>>>> Hi Qasim, > >>>>> > >>>>> Thanks for looking into this. If your explanation is accurate, then > >>>>> it looks like the originator and target sequence numbers are swapped > >>>>> for PREPs. That said, the scenario you describe should be easily > >>>>> testable using hwsim. In fact we have a very similar test on our > test > >>>>> suite that is currently passing. Would you consider writing a hwsim > >>>>> test case to test your patch? > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Javier > >>>>> > >>>>> PS. I've narrowed down the audience of this thread to avoid boring > >>>>> everyone in linux, netdev and linux-wireless on obscure mesh > >>>>> discussions... :) > >>>>> > >>>>> On Thu, May 24, 2012 at 10:02 PM, Qasim Javed <[email protected]> > wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I have been doing some experiments using the 802.11s functionality > in the mac80211 stack. Today I stumbled across something which I believe is > a critical bug in the usage of originator sequence number for a Path Reply > message upon the reception of a Path Request message. > >>>>>> > >>>>>> Consider the following topology: > >>>>>> > >>>>>> +---+ > >>>>>> | S | > >>>>>> +---+ > >>>>>> / \ > >>>>>> / \ > >>>>>> +---+ +---+ > >>>>>> | A | -- Javier Cardona cozybit Inc. http://www.cozybit.com
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
