Subject: Re: IP_HDRINCL revisited
To: Jun Xie <jun@qnx.com>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-net
Date: 01/22/1999 14:53:18
On Fri, 22 Jan 1999 17:47:26 -0500 (EST) 
 "Jun Xie" <jun@qnx.com> wrote:

 > 1. ip_len returned from rip_input() is not only in host byte order, but it
 > also does not reflect the length of the whole IP packet. ipintr() adjusts it
 > to not include the IP header.

That is now fixed in NetBSD-current.

 > 2. With last month's ICMP error patch, a "HTONS(ip->ip_id)" is added
 > in ip_ouput(). It's got executed for forwarded and raw output packets.
 > No problem with forwarded packets, but with raw ones that means
 > IP_HDRINCL expects host byte order ip_id from the user. And if the ip_id
 > passed by the user is 0, it is swapped twice (there's a "htons(ip_id)" in
 > rip_output() too).

I'll let Charles deal with this; he removed all swapping of ip_id (as it
is really an opaque value).

 > 3. ip_len in ICMP error returned from rip_input() is not in consistent order.
 > When it's an ICMP redirect message, ip_len is in network byte order, otherwise
 > if it's an error message like ICMP_UNREACH_PORT, ip_len is in host byte order.
 > That's because NTOHS(icp->icmp_ip.ip_len) is called when icmp_input() jumps to
 > "deliver:". It seems higher level routines never use icp->icmp_ip.ip_len.

...I think this might be fixed now, as well...

Charles?

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>