From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 12:16:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C5211065670 for ; Wed, 9 Jun 2010 12:16:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE218FC1A for ; Wed, 9 Jun 2010 12:16:39 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta05.emeryville.ca.mail.comcast.net with comcast id TnB01e0031Y3wxoA5oGfc0; Wed, 09 Jun 2010 12:16:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id ToGe1e0093S48mS8boGeii; Wed, 09 Jun 2010 12:16:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 447A99B418; Wed, 9 Jun 2010 05:16:38 -0700 (PDT) Date: Wed, 9 Jun 2010 05:16:38 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20100609121638.GA36975@icarus.home.lan> References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info> <4C0E935E.1020409@earthlink.net> <4C0F8214.3090104@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0F8214.3090104@earthlink.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Peter C. Lai" , FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 12:16:40 -0000 On Wed, Jun 09, 2010 at 07:59:16AM -0400, Stephen Clark wrote: > On 06/08/2010 03:00 PM, Stephen Clark wrote: > >On 06/08/2010 02:49 PM, Peter C. Lai wrote: > >>On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: > >>>On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > >>>>On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > >>>>>On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > >>>>>>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > >>>>>>4.9 didn't? > >>>>> > >>>>>The following output would help: > >>>>> > >>>>>- ifconfig -a > >>>>>- netstat -rn > >>>>>- Contents of /etc/rc.conf > >>>>> > >>>>>Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > >>>>>http://security.freebsd.org/ > >>>>> > >>>>Hi Jeremy, > >>>> > >>>>I am not sure that information is relevant. We have two systems > >>>>configured > >>>>identically one using 4.9 the other 6.3. > >>> > >>>My concern was that someone had botched something up in rc.conf or > >>>during the OS upgrade/migration, resulting in there being no loopback > >>>interface. I also wanted to verify that your routing table looked > >>>correct for what ifconfig showed. > >>> > >>>Other users pointed you to RFC 3927. Wikipedia has this to say: > >>> > >>>http://en.wikipedia.org/wiki/Link-local_address > >>> > >>>"Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. > >>>However, the first and last /24 subnet (256 addresses each) in this > >>>block have been excluded from use and are reserved by the standard.[1]" > >>> > >>>I read this to mean 169.254.0.0/24 and 169.254.255.0/24. > >>> > >>>Your previous ifconfig statement shows: > >>> > >>>>$ ifconfig rl0 > >>>>rl0: flags=8843 mtu 1500 > >>>>options=8 > >>>>inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 > >>>>inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 > >>>>ether 00:30:18:ae:7c:77 > >>>>media: Ethernet autoselect (100baseTX) > >>>>status: active > >>> > >>>With this configuration, you're using both the first and last /24 > >>>netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 > >>>for your broadcast address. > >>> > >>>You should be able to avoid this by using 169.254.1.0/24. > >>> > >> > >>RFC 3927 also has complicated rules involving when one can or should not > >>use a link-local address on the same interface as a routable IP, so at > >>best your configuration may not be supported anyway. One should not use > >>a link-local address as if it were under RFC 1918 rules, in particular > >>because link-local involves self-assigned addresses and internal > >>conflict mitigation. > >> > >Again what happened we had a box in the field that was running 4.9 being > >used as a router/nat/vpn/firewall device. It was handing out ip addresses > >to the internal lan using the range 169.254.202.0/24, who knows why this > >address range was picked. It worked great but > >the hardware died, so we were replacing it with our current SW which is > >based on 6.3 we duplicated the configuration and have been struggling > >trying to > >get it to work for the customer since Saturday with no luck. Today I > >finally > >tried to ping the internal address from the box itself and it wouldn't > >ping, > >so I started trying using other addresses on the internal interface and > >they > >worked but not 169.254.202.1. In googling I discovered that 169.254/16 > >was supposed to be assigned if a box couldn't obtain an ip but saw > >nothing about > >an OS dropping them. > > > >So anyway I know the reason behind the change now. > > > One final comment - I still don't understand why FreeBSD "won't" respond to pings > when it has an address like 169.254.1.1. I can ssh to the unit but it won't > respond to pings. I tried setting up a linux box with an address like > 169.254.1.2 and it "would" respond to pings. I tried to explain it as best as I could here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057191.html The IP stack (not a firewall, etc.) is basically blackholing the packet. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |