Bugzilla – Bug 652
no public API for IPv4 neighbor table
Last modified: 2014-09-20 18:40:48 EDT
This has not yet been implemented in class Ipv4 public API; this note is in the header file for ipv4.h: * TO DO: Add API to allow access to the Ipv4 neighbor table What I had in mind was to define some class such as Ipv4Neighbor that corresponded to Linux struct neighbour, add some methods analogous to what we do to add interfaces and addresses (e.g., Ipv4::GetNNeighbors(), Ipv4::GetNeighbor (i); Ipv4::AddNeighbor (neighbor); Ipv4::DeleteNeighbor (i);), and then add an ArpHelper class that could produce output analogous to what you get on a Linux system when you use the "arp" command.
This feature is becoming important, as I needed it for IPv6 routing tables update. I'd add the requirement to be IP-agnostic, as is to work on both IPv4 and IPv6 (if possible).
Hi What should I read to be able to work on this ? I mean should I have a check on W. Richard Stevens' "TCP/IP" or something like that. I'm interested in working on this. Please help.
(In reply to comment #2) > Hi > > What should I read to be able to work on this ? I mean should I have a check on > W. Richard Stevens' "TCP/IP" or something like that. I'm interested in working > on this. Please help. I would suggest to read 'man arp'. http://linux.die.net/man/7/arp http://linux.die.net/man/8/arp and try 'arp -a' on your system. If we can follow the development of how routing tables are printed and manipulated, we could perhaps provide similar API. From class Ipv4L3Protocol, we can GetInterface() for all Ipv4Interfaces. Then, we can GetArpCache(). What does not exist, it seems, is any method on class ArpCache to iterate on all Entry objects, or to print out the contents of the ArpCache. For the latter, I would look at how this works, in class Ipv4RoutingProtocol and its subclasses: virtual void PrintRoutingTable (Ptr<OutputStreamWrapper> stream) const = 0; So, it may be useful to be able to write examples and tests that do this: 1) add/remove entries manually 1.1) adding an entry before trying to send the first packet should suppress the Arp query 1.2) deleting an entry that hasn't expired should cause a new Arp query to be sent upon the next packet 2) print out the content of an ArpCache 3) print out the content of all ArpCaches on a node and do similar for IPv6. So, to get started, I would suggest to read the things above and propose a public API (additional public member functions) that would be able to accomplish the listed things.
Created attachment 1876 [details] protoPatch The reference command is "ip n". As an example... lenst:/home/pecos# ip n fe80::222:bdff:feec:4789 dev eth0 lladdr 00:22:bd:ec:47:89 router REACHABLE fe80::d6be:d9ff:fe98:4514 dev eth2 lladdr d4:be:d9:98:45:14 STALE fe80::a6ba:dbff:fefa:d9d9 dev eth2 lladdr a4:ba:db:fa:d9:d9 STALE fe80::3615:9eff:fe17:140 dev eth2 lladdr 34:15:9e:17:01:40 STALE 2001:760:2c05:1002::147 dev eth2 lladdr d4:be:d9:98:45:14 DELAY 192.168.11.147 dev eth2 lladdr d4:be:d9:98:45:14 REACHABLE 192.168.11.160 dev eth2 lladdr 00:26:b9:78:9d:89 STALE 192.168.200.9 dev eth1 lladdr 00:00:aa:5c:08:1d STALE 192.168.11.166 dev eth2 lladdr a4:ba:db:fa:d3:28 STALE The patch adds the functionality for ARP cache. NDISC should be similar. We need also a convenient place to store the public API. An option could be in an Helper, and in Ipv[4,6]L4Protocol for the interfaces iteration (Caches are per-interface).
Created attachment 1877 [details] IPv4 patch Why did I do this for IPv4 first ?
For the records, the output is similar to this: ARP Cache of node 0 at time 10 10.1.1.2 dev 1 lladdr 00-06-00:00:00:00:00:02 REACHABLE
Created attachment 1878 [details] Ipv4+Ipv6 patch Why this enhancement wasn't fixed before ?
To ease the tester's life: add this code just before Simulation::Run (): Ptr<OutputStreamWrapper> routingStream = Create<OutputStreamWrapper> (&std::cout); Ipv4StaticRoutingHelper rh4; rh4.PrintNeighborCacheAllAt (Seconds (10), routingStream); Ipv6StaticRoutingHelper rh6; rh6.PrintNeighborCacheAllAt (Seconds (10), routingStream);
Forgot. The printing functions are in the RoutingHelper. It seems strange, but it has a logic behind: 1) the helper already provides functions to print the routing tables. 2) neighbor cache tables are (to some extent) link-local routing informations
Comment on attachment 1878 [details] Ipv4+Ipv6 patch The patch (for real) just covers the neighbor table printing. The other required functionalities (add, remove, etc) are left for future implementation.
(In reply to Tommaso Pecorella from comment #10) > Comment on attachment 1878 [details] > Ipv4+Ipv6 patch > > The patch (for real) just covers the neighbor table printing. > The other required functionalities (add, remove, etc) are left for future > implementation. This looks ready, but could you either provide a standalone example or enhance one of our existing examples showing the table in a non-trivial state? - Tom
Comment on attachment 1878 [details] Ipv4+Ipv6 patch Pushed in changeset: 10965:14cde591d8e4 The example is wifi-simple-adhoc-grid.cc. It is very interesting, as OLSR is filling the routing table in the first 30 seconds, but the neighbor cache is created by the nodes only when the first data packet is sent (because OLSR messages are broadcasts). After the first data packet, the ARP cache is populated by each node interested in forwarding, and only by them.