Date: Wed, 09 Jun 2010 07:59:16 -0400 From: Stephen Clark <sclark46@earthlink.net> To: sclark46@earthlink.net Cc: "Peter C. Lai" <peter@simons-rock.edu>, FreeBSD Stable <freebsd-stable@freebsd.org>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: FreeBSD eats 169.254.x.x addressed packets Message-ID: <4C0F8214.3090104@earthlink.net> In-Reply-To: <4C0E935E.1020409@earthlink.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >>>> options=8<VLAN_MTU> >>>> 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<full-duplex>) >>>> 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. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C0F8214.3090104>