Hi again all,

It was suggested to me that I should air this suggestion on the "tech-net"
mailing list before going ahead and doing any changes to the kernel in order
to
(hopefully) get the stuff into the distribution and to get as good a
implementation as possible.

Since I have yet not received a single answer I wonder if this is the
correct forum or if I should post my suggestion via some other channel ?

Anyone care to comment ??

Regards,

	/Per


-----Original Message-----
From: Sundstrom, Per 
Sent: den 3 maj 2000 00:20
To: 'tech-net@netbsd.org'
Subject: IFF_NOARP, RTM_RESOLVE ...



Gentlemen,

We have a need for a daemon based arp resolver in a firewall-like
application where we need to have full control over the arp resolution.

The idea is to 
  1) set the interface to 'ifconfig -arp'
  2) set the interface route to XRESOLVE and 
  3) use the routing sockets RTM_RESOLVE messages to
      get notification on misses and finally
  4) use the routing sockets LL address RTM_ADD to set the MAC address
      on the route after the daemon has somehow gotten hold of it.

Now, there are a few things in the networking code that breaks
this idea.

  a) the ifconfig -arp sets the IFF_NOARP flag but this is not honored
      in the code.

  b) there is currently no syncronization between a RTM_RESOLVE
      and a corresponding RTM_ADD resulting in a drop of the first
      packet sent to a specific IP address.

Suggested solution:

  Add checks for the IFF_NOARP in the arp code. 
  Move the generation of RTM_RESOLVE for interface routes to
  if_arp.c
  Use 'llinfo_arp.la_hold' to hold the pending packet and match that
  on a RTM_ADD with a LL address.

What do you think ? Doable, feasable or just plain dumb ?...

Regards,
	/Per