From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 19:00:50 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 3CDD61065676 for ; Tue, 8 Jun 2010 19:00:50 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by mx1.freebsd.org (Postfix) with ESMTP id F176F8FC15 for ; Tue, 8 Jun 2010 19:00:49 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ErhuhQ4Ho15uHhutZCQpi9EdPjYq+Oxyud5CYmtOP+QQcH3KMYhiBr9v3Ig7Gkyx; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OM42a-0003wh-Ds; Tue, 08 Jun 2010 15:00:48 -0400 Message-ID: <4C0E935E.1020409@earthlink.net> Date: Tue, 08 Jun 2010 15:00:46 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Peter C. Lai" References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info> In-Reply-To: <20100608184919.GY63749@cesium.hyperfine.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79992e346fe85fd40ad4bbe2bf35b29c82350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: FreeBSD Stable , Jeremy Chadwick Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:00:50 -0000 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. -- "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)