|
Bugzilla – Full Text Bug Listing |
| Summary: | ARP Request reception : RFC 826 compliant | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Seb <sebastien.bindel> |
| Component: | internet | Assignee: | Tommaso Pecorella <tommaso.pecorella> |
| Status: | PATCH PENDING --- | ||
| Severity: | normal | CC: | ns-bugs, tomh |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://www.nsnam.org/bugzilla/show_bug.cgi?id=107 | ||
| Attachments: |
Tar archive containing modifications on arp-cache.h, arp-cache.cc and arp-l3-protocol.cc
New patch - slightly simplified New patch - slightly simplified (and working) |
||
|
Description
Seb
2016-08-23 09:40:53 UTC
Hi Sebastien, I'm currently checking this enhancement, and I have a question. Back when bug #107 was opened, the conclusion was the opposite: i.e., that the Linux kernel is ignoring the ARPs requests from unknown nodes. I'm up for re-checking this, but I'd need a clarification, since it seems that you have already gone through the kernel. We have 3 cases: 1) ARP request - actually we don't change our ARP table, and you propose to fill it instead, as RFC 826 suggests. 2) ARP reply - 2 sub-cases. 2a) ARP reply and we did a request - fill the table 2b) ARP reply and we did NOT do a request - ignore gratuitous ARP replies because they could be an ARP poisoning. About 2b I'm seriously tempted to add an attribute to change this behaviour. If the ARP poisoning is monitored by a proper IDS, the hosts shouldn't throw away gratuitous ARP replies because they could be simply from a host recovering from a NIC failure. About case 1, are you sure that the Linux kernel accepts them? It goes kinda in the opposite direction of bug 107 kernel check... Thanks, T. Created attachment 2652 [details]
New patch - slightly simplified
The new patch has the same effect, but with no changes in the ArpCache class
Created attachment 2654 [details]
New patch - slightly simplified (and working)
(In reply to Tommaso Pecorella from comment #1) > > About case 1, are you sure that the Linux kernel accepts them? It goes kinda > in the opposite direction of bug 107 kernel check... I just did a test on a Linux kernel 4.4. Reception of an ARP request puts a temporary entry in the ip neighbor table in state 'DELAY' and starts a 5 second timer. The ARP reply uses the MAC that was in the request, so it is sent immediately. However, after 5 seconds, the recipient will ARP to check the entry in state DELAY, and move it to REACHABLE if the ARP succeeds, or remove if not. So this patch makes it more RFC 826 compliant but suppresses the ARP exchange that occurs later to validate the entry. (In reply to Tom Henderson from comment #4) > (In reply to Tommaso Pecorella from comment #1) > > > > > About case 1, are you sure that the Linux kernel accepts them? It goes kinda > > in the opposite direction of bug 107 kernel check... > > I just did a test on a Linux kernel 4.4. Reception of an ARP request puts a > temporary entry in the ip neighbor table in state 'DELAY' and starts a 5 > second timer. The ARP reply uses the MAC that was in the request, so it is > sent immediately. However, after 5 seconds, the recipient will ARP to check > the entry in state DELAY, and move it to REACHABLE if the ARP succeeds, or > remove if not. > > So this patch makes it more RFC 826 compliant but suppresses the ARP > exchange that occurs later to validate the entry. Mmm... this makes sense. It is also explained here: http://linux-ip.net/html/ether-arp.html I'm just wondering if an L4 event (e.g., a successful TCP connection) could change the entry from DELAY to REACHABLE. Actually we do update the entries reachability when we receive valid L3 packets - it is a clearly described thing in IPv6 RFCs and it has been validated by experiments in IPv4. I'd ask Sebastien if he can improve the patch in this sense. |