Bug 652

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.