Re: refactoring ip_output() and the L2 _output()

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>>> [...] but arpresolve() deals some in routes,

>> IMO this is a misfeature - borderline bug - and is responsible for
>> at least one other botch.  [...sin_zero...]

>> Arranging for ARP entries to have nothing to do with the (IPv4)
>> routing table would be an excellent move, IMO.

> It sounds to me like we both favor a move toward greater simplicity
> and efficiency.  I'm pretty keen on doing just one table lookup per
> packet forwarded.

Well, pushing the ARP table out of the v4 routing table would mean
pushing it into somewhere else instead.  Depending on how complex that
"somewhere else" turns out to be, this may not be a net win.

My guess would be that it would be a win.  But that's just a guess.

> Insofar as ARP installs routing-table entries using a different key
> than a "standard" IPv4 address and mask, if that is what you're
> saying that it does, that seems too complicated.

Yes, that's what I think is going on.  There are 8 bytes of information
in each IPv4 routing table entry that are ignored by almost everything
that prints routes as routes.  They are the three fields struct
sockaddr_inarp has that overlay sin_zero in struct sockaddr_in, and, as
far as I can recall, only ARP code ever uses them.  However, other
interfaces accept them, since the routing table code is (perhaps
excessively) general and doesn't know they're special; this is why
sin_zero must exist and be zeroed by userland: if not, you wind up with
routes and/or addresses with garbage in the hidden 8 bytes, which don't
match when they should (because of the garbage) but are hard to detect
(because most tools don't print those bytes).  As I wrote in the change
I made in my private patch tree when I looked into this,

 * That interfaces like bind(2) or routing socket messages pay
 *  attention to what userland has in sin_zero is the real bug here.
 *  (Well, that plus the abuse of the AF_INET routing table to hold
 *  extra hidden data for structs sockaddr_inarp.)

> Do you understand what this sin_srcaddr member of sockaddr_inarp is
> for?

No.  I have a vague feeling that I understood that extra data back when
I investigated sin_zero, but I can't recall it now, and as far as I can
tell nothing uses sin_srcaddr by name.  I think ARP code uses it, but,
as I say, grep over the source tree makes me think it must do so
without using the sin_srcaddr name, which is annoying.  (For example, I
have a vague memory that there is code which creates routing-socket
messages by serializing something into the corresponding space in a
data buffer.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B