[Ns-bugs] [Bug 1189] Send RREQ bcast request Id duplicate check is missing

[code@nsnam.ece.gatech.edu]

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1189

--- Comment #4 from John Abraham <jabraham3 at mail.gatech.edu> 2011-06-28 15:49:39 EDT ---
At first glance I am guessing the below

1. Although the trace indicates node 0 receiving the packet, this may not imply
the RREQ was processed to any great extent by AODV-RP  (Node 0 will process its
own RREQs and check if they are duplicates in RecvRequest early in the
function)
2. As the hop count gets bumped up , these packets could be forwards by other
nodes within range.
In this case the trace might help if the MAC was displayed




(In reply to comment #3)
> Here is the side effect created.  Here is the intended initial packet flow
> (from src/aodv/test/aodv-regression.h):
> 
>            1       2       3       4       5
>     <------|------>|       |       |       |        RREQ (orig 10.1.1.1, dst
> 10.1.1.5, G=1, U=1, hop=0, ID=1, org_seqno=1) src = 10.1.1.1
>            |<------|------>|       |       |        RREQ (orig 10.1.1.1, dst
> 10.1.1.5, G=1, U=1, hop=1, ID=1, org_seqno=1) src = 10.1.1.2
>            |       |<------|------>|       |        RREQ (orig 10.1.1.1, dst
> 10.1.1.5, G=1, U=1, hop=2, ID=1, org_seqno=1) src = 10.1.1.3
>            |       |       |<------|------>|        RREQ (orig 10.1.1.1, dst
> 10.1.1.5, G=1, U=1, hop=3, ID=1, org_seqno=1) src = 10.1.1.4
> 
> Here is the current ns-3-dev trace for node 1.
> 
> 0.000160 IP 10.1.1.1.654 > 10.1.1.255.654:  aodv rreq 24  hops 0 id 0x00000001
>         dst 10.1.1.5 seq 0 src 10.1.1.1 seq 1
> 0.000482 IP 10.1.1.2.654 > 10.1.1.255.654:  aodv rreq 24  hops 1 id 0x00000001
>         dst 10.1.1.5 seq 0 src 10.1.1.1 seq 1
> 0.002514 ARP, Reply 10.1.1.2 is-at 00:00:00:00:00:02, length 32
> 0.002913 Acknowledgment RA:00:00:00:00:00:03 
> 0.003059 ARP, Request who-has 10.1.1.1 (ff:ff:ff:ff:ff:ff) tell 10.1.1.2,
> length 32
> 
> Here is the new trace after the patch is applied:
> 0.000160 IP 10.1.1.1.654 > 10.1.1.255.654:  aodv rreq 24  hops 0 id 0x00000001
>         dst 10.1.1.5 seq 0 src 10.1.1.1 seq 1
> 0.000482 IP 10.1.1.2.654 > 10.1.1.255.654:  aodv rreq 24  hops 1 id 0x00000001
>         dst 10.1.1.5 seq 0 src 10.1.1.1 seq 1
> 0.000606 IP 10.1.1.1.654 > 10.1.1.255.654:  aodv rreq 24  hops 2 id 0x00000001
>         dst 10.1.1.5 seq 0 src 10.1.1.1 seq 1
> 0.002514 ARP, Reply 10.1.1.2 is-at 00:00:00:00:00:02, length 32
> 0.002913 Acknowledgment RA:00:00:00:00:00:03 
> 0.003059 ARP, Request who-has 10.1.1.1 (ff:ff:ff:ff:ff:ff) tell 10.1.1.2,
> length
>  32
> 
> Note the extra RREQ at time 0.000606.  It appears that node 0 is recirculating
> its own RREQ (but node 1 suppresses the retransmission) because it didn't put
> it in the cache when originating it.
> 
> I would be fine with renaming to "CheckDupAndAdd" as you suggest.  But I would
> also be fine with leaving it alone since it is documented correctly and seems
> to not be a bug.

-- 
Configure bugmail: https://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.