Subject: Re: IP_HDRINCL revisited
To: Bill Fenner <firstname.lastname@example.org>
From: Craig Metz <email@example.com>
Date: 01/21/1999 17:26:50
In message <99Jan21.firstname.lastname@example.org>, you write:
>The red daemon book says "The raw IP socket interface attempts to
>provide an identical interface to the one a protocol would have if it
>were resident in the kernel." The current raw socket interface is
>neither a bug nor an oversight. (Although I'll concede to "poorly
>The decision about swapping on input is the thing that always makes me
>shy away when I think about whether or not to try changing things.
>It's (relatively) easy on output since you can accomplish binary
>compatibility e.g. with a versioned IP_HDRINCL option. However,
>there's no parallel for input - there's no way to provide compatibility
>for a program that receives raw IP and doesn't set IP_HDRINCL.
One possible way to do this would be to define a new value for IPPROTO_RAW,
hopefully this time one that is less than zero or greater than 255 so as to not
conflict with real protocol numbers.
Getting rid of the random byte-swapping and twiddling of the packet mbuf in
the input processing would be nice. In my case, I'm thinking in terms of the
grief it causes me in writing foo_input() for IPsec related values of foo where
I have to put the packet back the way it came, do stuff, then put it back the
way the rest of the kernel wants.