Subject: Re: IP_HDRINCL revisited
To: Jun Xie <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 01/22/1999 14:53:18
On Fri, 22 Jan 1999 17:47:26 -0500 (EST)
"Jun Xie" <email@example.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...
-- Jason R. Thorpe <firstname.lastname@example.org>