Subject: Re: IP_HDRINCL revisited
To: Bill Fenner <fenner@parc.xerox.com>
From: Craig Metz <cmetz@inner.net>
List: tech-net
Date: 01/21/1999 17:26:50
In message <99Jan21.135012pst.177534@crevenia.parc.xerox.com>, 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
>designed".)
>
>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.

									-Craig