Re: raw socket, IP_HDRINCL byteorder

>>It was actually well-defined when it was introduced; it just wasn't what
>>people expected from it.  It's now confusing because Linux and others
>>decided to "fix" it.
>
>	how did Linux fixed it? (i don't have any Linux systems around)

As far as I can tell, similarly to the way OpenBSD did later.  The mtrace
Makefile shows the results of some experimentation in 1998:

CFLAGS=         -O ${MCAST_INCLUDE}     ## SunOS, OSF1, FreeBSD, IRIX
#CFLAGS=                -O ${MCAST_INCLUDE} -DRAW_OUTPUT_IS_RAW ## OpenBSD
#CFLAGS=                -O ${MCAST_INCLUDE} -D__BSD_SOURCE -DRAW_OUTPUT_IS_RAW -DRAW_INPUT_IS_RAW       ## Linux
#CFLAGS=                -O ${MCAST_INCLUDE} -DSYSV -DSUNOS5     ## Solaris 2.x

So [at that time], OpenBSD wanted network order on the way out, but
supplied host order [for the fields that mtrace cares about] on the
way in.  Linux supplied network order on the way in and did not
subtract the IP header length from ip_len.

I don't know what has changed in these interfaces since then.

>	IP_NHDRINCL or IP_HDRINCL2, maybe?

Don't forget that this will be specifying what happens on the way
in too.  IP_HDRINCL has historically only ever been significant on
output, so I think a new name that breaks with history would be better.
But, before we argue about the name, let's get on the same page on
what the semantics should be.  I haven't thought about this very
much, but I think that the right interface is pure IP packets, no
field munging.  Whether IP options just go in the packet or you
can use the IP_OPTIONS socket option needs more thought.

  Bill

---------------------------------------------------------------------
The BSD APIs Discussion Mailing List
To unsubscribe:
send "unsubscribe bsd-api-discuss" to majordomo-DZEk9q7Sfju/3pe1ocb+swC/[email protected]