[Ns-bugs] [Bug 772] AODV is unable to correctly buffer packets waiting for route reply
code at nsnam.ece.gatech.edu
Wed Jan 13 21:51:18 PST 2010
--- Comment #8 from Tom Henderson <tomh at tomh.org> 2010-01-14 00:51:18 EDT ---
(In reply to comment #6)
> > Sorry for the delay in responding-- I missed your question earlier. I would be
> > fine with the tag you suggest. Did you find out how this is handled in
> > practice? Real implementations do not have the luxury of packet tags so
> > presumably they must be able to detect these locally originated packets and
> > distinguish them from duplicates.
> To my shame I didn't find any mention of 127.0.0.1 in AODV-UU sources and
> stop there. Now I see that looped back packets can be easily detected by
> incoming interface (lo). I have implemented this in the attached patch, it
> seems to fix this bug (but not 777 one) without use of tags. All reference
> traces in src/routing/aodv/test must be re-generated because of ID field in IP
> headers, I have checked that nothing else changed and new tests are Ok.
> Now I ask you to review that patch and decide whether it's worth to be pushed
> before 3.7 (I think so).
I read through this but did not step through the code. It seems like there is
no provision for recalculating checksums due to address changing in deferred
route output if Node::ChecksumEnabled is true.
Also, the code seems to assume that all packets received on the loopback are
these deferred RouteOutput packets, but what if another process is sending
packets to 127.0.0.1? This code doesn't seem to check for that case:
// Deferred route request
if (idev == m_lo)
DeferredRouteOutput (p, header, ucb, ecb);
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the Ns-bugs