From nobody@FreeBSD.org  Sun Oct 28 20:10:25 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 1CA7537B403
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 28 Oct 2001 20:10:25 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.4/8.11.4) id f9T4APo65440;
	Sun, 28 Oct 2001 20:10:25 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200110290410.f9T4APo65440@freefall.freebsd.org>
Date: Sun, 28 Oct 2001 20:10:25 -0800 (PST)
From: Igor M Podlesny <poige@morning.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: wrong src ip address for some ICMPs
X-Send-Pr-Version: www-1.0

>Number:         31575
>Category:       kern
>Synopsis:       wrong src ip address for some ICMPs
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    ru
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Oct 28 20:20:00 PST 2001
>Closed-Date:    Fri Dec 7 01:24:39 PST 2001
>Last-Modified:  Fri Dec 07 01:25:50 PST 2001
>Originator:     Igor M Podlesny
>Release:        4.4
>Organization:
Morning Network Ltd
>Environment:
doesn't matter. it works the same way even on 3.5 and, I suspect, all
releases before and after that.
>Description:
You  might  observe  this  bug doing traceroute  while  standing  behind  a  GW's  interface  with  several IP-addresses  (aliases).  In  this  case  you always got ICMP.TIMXCEED (time  exceeded)  coming  from  IP-address  which  is usually the first on the interface,  even  if  your  box  is  not  using this IP-address as its next-hop.  Despite  of  the  code  selecting right IP-address for this purpose  is  working  well it's being confused by wrong argument it is
being given. This patch (http://www.morning.ru/~poige/patchzone/ip_icmp.c.diff)
fixes namely this problem.

>How-To-Repeat:
You should have several ip-address on interface of NEXT-HOP router
running FreeBSD, then invoke traceroute some.where.
>Fix:
http://www.morning.ru/~poige/patchzone/ip_icmp.c.diff
>Release-Note:
>Audit-Trail:

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Igor M Podlesny <poige@morning.ru>
Cc: bug-followup@FreeBSD.org
Subject: Re: misc/31575: wrong src ip address for some ICMPs
Date: Thu, 29 Nov 2001 19:25:00 +0200

 On Sun, Oct 28, 2001 at 08:10:25PM -0800, Igor M Podlesny wrote:
 > 
 > You might observe this bug doing traceroute while standing behind
 > a GW's interface with several IP-addresses (aliases).  In this case
 > you always got ICMP.TIMXCEED (time exceeded) coming from IP-address
 > which is usually the first on the interface, even if your box is
 > not using this IP-address as its next-hop.  Despite of the code
 > selecting right IP-address for this purpose is working well it's
 > being confused by wrong argument it is being given.  This patch
 > (http://www.morning.ru/~poige/patchzone/ip_icmp.c.diff) fixes namely
 > this problem.
 > 
 Let me see if I took you correctly.  Suppose you have a gateway, GW:
 
 rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 192.168.4.115 netmask 0xffffff00 broadcast 192.168.4.255
         inet 192.168.4.200 netmask 0xffffffff broadcast 192.168.4.200
 
 And another host H on the network has the following routing table
 entry:
 
 10                 192.168.4.200      UGSc        0    16030   fxp0
 
 And you are complaining that when H sends an IP packet to the 10
 network, with TTL <= 1, gateway replies with an ICMP time exceeded
 from 192.168.4.115 instead of expected 192.168.4.200, like this:
 
 traceroute to 10.0.0.1 (10.0.0.1), 1 hops max, 40 byte packets
  1  192.168.4.115  0.448 ms
 
 Right?  But if that's the case (and I just checked for sure that
 your patch doesn't make any difference), the GW doesn't know
 which of the 192.168.4.115 or 192.168.4.220 addresses have been
 used by H, because they both map to the same MAC address on H,
 and the MAC address is what's used when forwarding:
 
 ? (192.168.4.115) at 0:c0:df:3:2d:79 on fxp0 [ethernet]
 ? (192.168.4.200) at 0:c0:df:3:2d:79 on fxp0 [ethernet]
 
 > >How-To-Repeat:
 > You should have several ip-address on interface of NEXT-HOP router
 > running FreeBSD, then invoke traceroute some.where.
 > 
 Yeah, that's exactly how I did it, and didn't notice any
 difference after applying your patch...
 
 
 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

From: Igor M Podlesny <poige@morning.ru>
To: Ruslan Ermilov <ru@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, freebsd-hackers@FreeBSD.org
Subject: Re[2]: misc/31575: wrong src ip address for some ICMPs
Date: Fri, 30 Nov 2001 11:01:56 +0700

 > On Sun, Oct 28, 2001 at 08:10:25PM -0800, Igor M Podlesny wrote:
 hm.. it seems somebody has multiplied my timezone by -1 ;-)
 
 >>
 >> You might observe this bug doing traceroute while standing behind
 >> a GW's interface with several IP-addresses (aliases).  In this case
 >> you always got ICMP.TIMXCEED (time exceeded) coming from IP-address
 >> which is usually the first on the interface, even if your box is
 >> not using this IP-address as its next-hop.  Despite of the code
 >> selecting right IP-address for this purpose is working well it's
 >> being confused by wrong argument it is being given.  This patch
 >> (http://www.morning.ru/~poige/patchzone/ip_icmp.c.diff) fixes namely
 >> this problem.
 >> 
 > Let me see if I took you correctly.  Suppose you have a gateway, GW:
 
 > rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 >         inet 192.168.4.115 netmask 0xffffff00 broadcast 192.168.4.255
 >         inet 192.168.4.200 netmask 0xffffffff broadcast 192.168.4.200
 
 > And another host H on the network has the following routing table
 > entry:
 
 > 10                 192.168.4.200      UGSc        0    16030   fxp0
 
 > And you are complaining that when H sends an IP packet to the 10
 > network, with TTL <= 1, gateway replies with an ICMP time exceeded
 > from 192.168.4.115 instead of expected 192.168.4.200, like this:
 
 > traceroute to 10.0.0.1 (10.0.0.1), 1 hops max, 40 byte packets
 >  1  192.168.4.115  0.448 ms
 
 > Right?  But if that's the case (and I just checked for sure that
 > your patch doesn't make any difference), the GW doesn't know
 > which of the 192.168.4.115 or 192.168.4.220 addresses have been
 > used by H, because they both map to the same MAC address on H,
 > and the MAC address is what's used when forwarding:
 
 > ? (192.168.4.115) at 0:c0:df:3:2d:79 on fxp0 [ethernet]
 > ? (192.168.4.200) at 0:c0:df:3:2d:79 on fxp0 [ethernet]
 
 >> >How-To-Repeat:
 >> You should have several ip-address on interface of NEXT-HOP router
 >> running FreeBSD, then invoke traceroute some.where.
 >> 
 > Yeah, that's exactly how I did it, and didn't notice any
 > difference after applying your patch...
 
 Ruslan,  sorry,  I'm  very  busy  for an unpredictable amount of time,
 cause  I'm a system administrator of ISP and recently I got a bunch of
 deeds  to  do,  so I can't respond to your analyze shown before in all
 its  details...  and  (sorry  for that) I don't feel that it is really
 needed  --  I  changed  the code in ip_icmp.c because I saw myself how
 really  were  routers  acting  before and after applying the patch. In
 addition, I suggest you to look at this
 
 http://www.sigmasoft.com/~openbsd/archive/openbsd-bugs/200110/msg00146.html
 
 P.S. The description of bug once more:
 
 
 [router]
   |
   X---->|backbone|-->
   |
   |
   Yip1----|the same media|------[some another ip-network]
   |ip2----|the same media|------|some box|
 
 Here  is "router" with FreeBSD (OpenBSD, and, probably *BSD) and "Some
 box"  doing traceroute to (for e.g.) a host which is _reachable_ _via_
 _backbone_.   X,  Y  --  NICs.  Y  has  several  IPs,  making  several
 ip-networks on "the same media".
 
 The  problem: traceroute being run on "somebox" will hear respond from
 "router"  coming  from  Y.ip1  address  which  isn't  on its (somebox)
 IP-network.  (well,  I  deem  icmp.echoreply isn't alone in this.) And
 this happens because wrong IP-addr is passed to ifaof_ifpforaddr(). My
 patch  fixes  namely  this problem -- I have worked out and applied it
 and  I  believe  I know what I'm talking about. Look at it, and you'll
 realize what I mean...
 
 You  may  ask  me  for  details,  but,  please,  don't  make different
 situations  asking  me  how  does  it  correlate  with -- damn lack of
 time...
 
 -- 
  Igor                            mailto:poige@morning.ru
                                  http://morning.ru/~poige
 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Igor M Podlesny <poige@morning.ru>
Cc: bug-followup@FreeBSD.org, net@FreeBSD.org
Subject: Re: kern/31575: wrong src ip address for some ICMPs
Date: Fri, 30 Nov 2001 12:34:57 +0200

 [Redirected to -net]
 [Category changed to "kern"]
 
 On Fri, Nov 30, 2001 at 11:01:56AM +0700, Igor M Podlesny wrote:
 [...]
 > [router]
 >   |
 >   X---->|backbone|-->
 >   |
 >   |
 >   Yip1----|the same media|------[some another ip-network]
 >   |ip2----|the same media|------|some box|
 > 
 > Here  is "router" with FreeBSD (OpenBSD, and, probably *BSD) and "Some
 > box"  doing traceroute to (for e.g.) a host which is _reachable_ _via_
 > _backbone_.   X,  Y  --  NICs.  Y  has  several  IPs,  making  several
 > ip-networks on "the same media".
 > 
 > The  problem: traceroute being run on "somebox" will hear respond from
 > "router"  coming  from  Y.ip1  address  which  isn't  on its (somebox)
 > IP-network.  (well,  I  deem  icmp.echoreply isn't alone in this.) And
 > this happens because wrong IP-addr is passed to ifaof_ifpforaddr(). My
 > patch  fixes  namely  this problem -- I have worked out and applied it
 > and  I  believe  I know what I'm talking about. Look at it, and you'll
 > realize what I mean...
 > 
 > You  may  ask  me  for  details,  but,  please,  don't  make different
 > situations  asking  me  how  does  it  correlate  with -- damn lack of
 > time...
 > 
 Yeah, now I see what's screwed up.  I even thought about this myself
 this morning (well, you know the saying we use for that :-), before
 even reading your mail.  But your fix is not quite correct, as we may
 have an individual routing table entry on "router" pointing back to
 "somebox" with a specific interface address (IFA) given, as reported
 by the "route -vn get -host <somebox>" command, and we should actually
 use that as the source.  The correct fix is a bit more complicated,
 and fortunately I have one.
 
 
 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
State-Changed-From-To: open->feedback 
State-Changed-By: ru 
State-Changed-When: Fri Nov 30 02:43:12 PST 2001 
State-Changed-Why:  
A fix was committed to 5.0-CURRENT: 

Revision  Changes    Path 
1.19      +3 -1      src/sys/netinet/icmp_var.h 
1.64      +14 -26    src/sys/netinet/ip_icmp.c 
1.185     +17 -16    src/sys/netinet/ip_input.c 
1.59      +3 -1      src/sys/netinet/ip_var.h 
1.52      +5 -0      src/usr.bin/netstat/inet.c 


Responsible-Changed-From-To: freebsd-bugs->ru 
Responsible-Changed-By: ru 
Responsible-Changed-When: Fri Nov 30 02:43:12 PST 2001 
Responsible-Changed-Why:  
MFC in 1 week. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=31575 
State-Changed-From-To: feedback->closed 
State-Changed-By: ru 
State-Changed-When: Fri Dec 7 01:24:39 PST 2001 
State-Changed-Why:  
MFC'ed. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=31575 
>Unformatted:
