|
Bugzilla – Full Text Bug Listing |
| Summary: | False ARP cache timeouts | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Chip Webb <ns3> |
| Component: | internet | Assignee: | Tommaso Pecorella <tommaso.pecorella> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | ns-bugs |
| Priority: | P5 | ||
| Version: | ns-3.24 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
Proposed patch to arp-cache.cc and arp-cache.h
Test case for checking for false ARP cache timeouts |
||
Created attachment 2187 [details]
Test case for checking for false ARP cache timeouts
Good call, but it's a duplicate bug. About the patch, I don't really agree with the approach. It's not the lookup that should trigger the refresh, it's receiving an L4 confirmation that the party is still reachable (for TCP, it means an ACK with the right source IP address and the right source MAC address). I do agree that we should work on a patch tho. *** This bug has been marked as a duplicate of bug 2057 *** |
Created attachment 2186 [details] Proposed patch to arp-cache.cc and arp-cache.h Arp cache entries time out after 120 seconds, even if they are in use. This disrupts ongoing sessions -- particularly high-bandwidth TCP sessions and leads to confusing and non-realistic results. The attached patch causes the entries to be refreshed each time they are looked up so that they don't time out. The way I did it in this patch was to add a call to UpdateSeen inside the Lookup method. This required making the UpdateSeen method public, and that may not be desirable from an OO design perspective. So I'm OK with any other patch that eliminates the false ARP timeouts. Attached are a patch and a test case.