Bug 31575
| Summary: | wrong src ip address for some ICMPs | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Igor M Podlesny <poige> |
| Component: | kern | Assignee: | ru <ru> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Igor M Podlesny
2001-10-29 04:20:00 UTC
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 > 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 [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 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 MFC in 1 week. State Changed From-To: feedback->closed MFC'ed. |
