Subject: FW: IFF_NOARP, RTM_RESOLVE ...
To: 'email@example.com' <firstname.lastname@example.org>
From: Sundstrom, Per <Per.Sundstrom@compaq.com>
Date: 05/04/2000 21:28:41
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
(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 ??
From: Sundstrom, Per
Sent: den 3 maj 2000 00:20
Subject: IFF_NOARP, RTM_RESOLVE ...
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
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.
Add checks for the IFF_NOARP in the arp code.
Move the generation of RTM_RESOLVE for interface routes to
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 ?...