Re: raw socket, IP_HDRINCL byteorder

>>Can someone pull together the total semantics of IP_HDR_RAW (or
>>whatever we decide to call it?)  I'd do this myself but I deleted some
>>of the earlier messages of this thread...
>>What about handling of ip_id and ip_sum?  
>
>	how about this.  all fields are in network byteorder.
>
>	outgoing:
>	ip_len: the whole IP packet length (not the payload)
>	ip_off: offset portion and MF bit has to be zero.
>	ip_id: overwritten by the kernel
>	ip_sum: overwritten by the kernel
>	ip option: ???? interaction with IP_OPTIONS?

i agree that ip_len should be in network byte order and that the
kernel should calculate ip_sum (people who wish to send packets with
invalid checksums can simply use bpf), but i wonder about the rest.

ip_id is simply a token, not something that has an endianness per se.
i understand that you may end up stepping on your own feet if you
reuse an ip_id the kernel had previously assigned, but aren't there
*tons* of ways to step on your feet via the use of raw ip?  why focus
on this one?

ip_off is used for sending fragments; why preclude a program from
sending fragmented datagrams?  raw ip sockets are about sending ip
datagrams (with valid checksums).  a fragment is a perfectly good
datagram.

ip options should, imho, be passed around in network byte order.
trying to do endian swapping on fields that may (or may not) be
aligned properly is simply pedantic.  make the application do it, if
need be.

>	incoming:
>	ip_len: the whole IP packet length (not the payload) = as is
>	ip_off: as is (same as the packet on the wire)
>	ip_id: as is (same as the packet on the wire)
>	ip_sum: as is (same as the packet on the wire)
>	ip option: as is (same as the packet on the wire)

sensible, though if you wish to prevent a program from sending ip
fragments, would it not make sense to prevent it from receiving them
as well, and reassemble packets before passing them up?

-- 
|-----< "CODE WARRIOR" >-----|
[email protected]             * "ah!  i see you have the internet
twofsonet-X5LO1RRdYLVWk0Htik3J/[email protected] (Andrew Brown)                that goes *ping*!"
werdna-aTR67+QfzahWk0Htik3J/[email protected]       * "information is power -- share the wealth."

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