Bugzilla – Bug 564
Tags gone crazy, no clue about the issue
Last modified: 2009-06-05 12:01:23 EDT
Created attachment 436 [details] examples/stats application modified to show the "bug" Ok, maybe I'm a total newbie, maybe I found a serious bug. In the first case I'll get the shame on me. Anyway, I was trying to modify the example/stats in order to show the packet loss due to channel congestion, so I did the following things: 1) modified the sender application to send an unicast packet instead of a broadcast, 2) changed the sender application to calculate the send interval according to a fixed DataRate (more intuitive and ease the plotting), 3) changed the main simulation code to use an AP and a STA (I wanted to add more STAs). Add some more "patches" to the Receiver application in order to show is a TimeTag is missing in action (you never know). Result (with 1 AP and 2 STAs): Sending packet at 1000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 1000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 9000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 9000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 17000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 17000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns ** missing time tag ** Sending packet at 25000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 25000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 33000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 33000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns ** missing time tag ** Sending packet at 41000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 41000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns ** missing time tag ** Sending packet at 49000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns Sending packet at 49000000000ns to 192.168.0.1 -- Time Interval is: 8000000000ns ** missing time tag ** This is driving me crazy. How can an application's receive function be called with a corrupted packet ? How can a tag go missing in action ? Cheers
patch for this bug in bug 572 *** This bug has been marked as a duplicate of bug 572 ***
Could you put a breakpoint in Packet::PeekData and see if it is ever called ?
(In reply to comment #2) > Could you put a breakpoint in Packet::PeekData and see if it is ever called ? > and, if it is ever called, re-run with NS_LOG=Packet using the latest ns-3-dev and send me the output
(In reply to comment #3) > (In reply to comment #2) > > Could you put a breakpoint in Packet::PeekData and see if it is ever called ? > > > > and, if it is ever called, re-run with NS_LOG=Packet using the latest ns-3-dev > and send me the output and, ideally, you would also print on stdout a line like the one you printed in your test code "missing" together with the packet pointer so that I can relate the packet log with the actual error
I have tracked down (it seems) the bug, and it +seems+ to be kinda related to our work. As is, a bad interaction between WiFi aggregation and tags. I'm working with Mirko Banchi to a fix and, if it's really the part we've spotted, we'll send a patch.
Latest news: we tracked down the error and we definitely (we hope) wiped it. The problem was in MsduAggregator::Deaggregate. To be precise, the old implementation was wiping out all the tags associated with the aggregated packets. Bad idea indeed. Fixing that one and the Packet::PeekData did the job. All my tests confirm that the tag are again all where they should be. So, we can conclude that the problem has been fixed and the bug is no more (the patched MsduAggregator::Deaggregate is already in the ns3-dev repository).