From owner-freebsd-net Wed Aug 30 5: 3:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id D8C2837B423; Wed, 30 Aug 2000 05:03:31 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id PAA70532; Wed, 30 Aug 2000 15:03:27 +0300 (EEST) Date: Wed, 30 Aug 2000 15:03:27 +0300 From: Ruslan Ermilov To: committers@FreeBSD.org, net@FreeBSD.org Cc: Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf Subject: [Call for review] ICMP error generation fixes Message-ID: <20000830150327.C69333@sunbay.com> Mail-Followup-To: committers@FreeBSD.org, net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf References: <20000829192913.A39253@sunbay.com> <200008292032.HAA19847@avalon.reed.wattle.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i 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 +1000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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