Bug 1608 - DSR Network ACK is not handled correctly
DSR Network ACK is not handled correctly
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: dsr
ns-3-dev
All All
: P5 normal
Assigned To: Yufei Cheng
:
Depends on: 1609
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-23 10:58 UTC by Daniel L.
Modified: 2013-04-08 10:28 UTC (History)
1 user (show)

See Also:


Attachments
A simple three hop network. (5.10 KB, text/x-c++src)
2013-03-23 10:58 UTC, Daniel L.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel L. 2013-03-23 10:58:42 UTC
Created attachment 1538 [details]
A simple three hop network.

A node one hop away from the destination node has to use a DSR network ACK since the destination is not forwarding the packet (i.e. no passive ACK by overhearing). The destination node then tries to ACK directly to the source node (sends ARP looking for the source node). DSR ACK time out occurs and Unreachable Error is sent to the source by the node one hop away from the destination.

In the attached sample, three nodes are placed linearly:

[node 0] --- [node 1] --- [node 2]

UDP flows from [node 0] to [node 2].

Timing:

1.04975s [node 1] DsrRouting:AddAckReqHeader(0xe9ae80, 0xea42f0, 10.0.0.3)
...
1.12975s [node 1] DsrRouting:SendPacket(0xe9ae80, 0xea5720, 10.0.0.1, 10.0.0.3, 17)
** First DSR packet with ACKREQ
...
1.12993s Send back ACK to the earlier hop 10.0.0.1 from us 10.0.0.3
1.12993s ArpL3Protocol:Lookup(0x1f75120, 0x1f80ef0, 10.0.0.1, 0x1f68f00, 0x1f7b680)
1.12993s node=2, no entry for 10.0.0.1 -- send arp request
** [node 2] received and processed ACKREQ, tried to ACK directly to [node 0]
...
1.13004s [mac=00:00:00:00:00:03] MacLow:StartTransmission
** [node 2] sends ARP Request (too far to be received by [node 0])
...
(two more DSR packets with ACKREQ, ARP pending at [node 2])
...
1.36975s [node 1] DsrRouting:SendUnreachError(0x1f782f0, 10.0.0.3, 10.0.0.1, 10.0.0.3, 0, 17)
** ACK timeout?
...
1.37024s [mac=00:00:00:00:00:02] startTx size=96, to=00:00:00:00:00:01
** [node 1] sends DSR RERR (Unreachable) back to [node 0]
Comment 1 Daniel L. 2013-03-23 11:04:14 UTC
This scenario results in DSR periodically think that the destination is unreachable and new route request will be generated periodically.
Comment 2 Tom Henderson 2013-04-08 00:51:27 UTC
see bug 1609 for patch
Comment 3 Tom Henderson 2013-04-08 10:28:10 UTC
fix in this changeset:  854e085e1a01