Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Aug 2000 15:03:27 +0300
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        committers@FreeBSD.org, net@FreeBSD.org
Cc:        Garrett Wollman <wollman@FreeBSD.org>, Bill Fenner <fenner@FreeBSD.org>, Darren Reed <darrenr@FreeBSD.org>, Kannan Varadhan <kannanv@malgudi.research.bell-labs.com>, Frank Volf <volf@oasis.IAEhv.nl>
Subject:   [Call for review] ICMP error generation fixes
Message-ID:  <20000830150327.C69333@sunbay.com>
In-Reply-To: <200008292032.HAA19847@avalon.reed.wattle.id.au>; from darrenr@reed.wattle.id.au on Wed, Aug 30, 2000 at 06:32:40AM %2B1000
References:  <20000829192913.A39253@sunbay.com> <200008292032.HAA19847@avalon.reed.wattle.id.au>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi!

The patch is ready for your review that addresses almost all issues with
broken ICMP error generation and eliminates some other inconsistencies.
The bugs are easily discovered by `tcpdump -nvvx' on ICMP error messages
generated by a FreeBSD router.  They could also be used by nmap-like
utilities for remote OS recognition.


I have put my patch (264 lines) here:

http://people.FreeBSD.org/~ru/icmp-fixes.2

If everything goes OK I intend to commit my patch on Friday, September 1.

Here are the details of what has been fixed:

1. icmp_error() now does not add IP header length.  This fixes the problem
   when icmp_error() is called from ip_forward().  In this case the ip_len
   of part of the original IP datagram returned in ICMP error message was
   computed incorrectly.

2. icmp_error() expects all three fields, ip_len, ip_id and ip_off in host
   byte order and converts them to network byte order.  This fixes the
   problem described in PR 16240 and PR 20877, when ip_id field was returned
   in a host byte order.

3. TTL decrement operation in ip_forward() was moved down to make sure that
   this change does not corrupt the part of original IP packet passed later
   to icmp_error().

4. A copy of a part of original IP packet (mcopy) in ip_forward() was made
   a real (read-write, independent) copy.  This fixes the problem I first
   reported to Garrett Wollman and Bill Fenner and later in PR 16240, when
   ip_output() sometimes(!!!) converts the fields of original packet to a
   network byte order, but because `mcopy' and `m' share the same cluster,
   this also corrupts the copy `mcopy'.

5. Following the suggestion from Darren Reed, ip_output() now expects all
   three fields, ip_len, ip_off and ip_id(!) in host byte order.  It was
   a headache for years.  The only compatibility issue here I can think
   of is the raw IP socket case with IP_HDRINCL socket option and ip_id
   field being non-zero, but ip.4 manual page is unclear on whether in
   this case ip_id field should be in host byte order or not.  I see two
   alternatives here: either convert ip_id in rip_output() back to a host
   byte order for backwards compatibility, or add a HISTORY entry to the
   ip.4 manual describing this change.  I personally like the second.


Cheers,
-- 
Ruslan Ermilov		Oracle Developer/DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000830150327.C69333>