From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:45:28 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 4ED6D106566B for ; Tue, 8 Jun 2010 18:45:28 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 0F2F78FC16 for ; Tue, 8 Jun 2010 18:45:27 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ndrx/5ePrCGPJV3gcUEJedZqPCSLpQFVviQVCiU5QMkseRWEeutl5nQNDMZdYiQq; 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-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OM3ni-0001xa-JO; Tue, 08 Jun 2010 14:45:26 -0400 Message-ID: <4C0E8FC4.7070009@earthlink.net> Date: Tue, 08 Jun 2010 14:45:24 -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: Garrett Cooper References: <4C0E81D7.8020209@earthlink.net> <4C0E8C59.5010202@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec7956b157d5929fa9add300e76972c4c21b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: Guy Helmer , 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 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 18:45:28 -0000 On 06/08/2010 02:40 PM, Garrett Cooper wrote: > On Tue, Jun 8, 2010 at 11:30 AM, Stephen Clark wrote: >> On 06/08/2010 02:21 PM, Guy Helmer wrote: >>> >>> On Jun 8, 2010, at 12:45 PM, Stephen Clark wrote: >>> >>>> Hi, >>>> >>>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >>>> 4.9 didn't? >>>> >>>> ***** 6.3 ***** >>>> $ sudo ipfstat -nio >>>> empty list for ipfilter(out) >>>> empty list for ipfilter(in) >>>> Z2984:~ >>>> $ 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 >>>> Z2984:~ >>>> $ ping 169.254.1.1 >>>> PING 169.254.1.1 (169.254.1.1): 56 data bytes >>>> ^C >>>> --- 169.254.1.1 ping statistics --- >>>> 4 packets transmitted, 0 packets received, 100% packet loss >>>> Z2984:~ >>>> $ uname -a >>>> FreeBSD Z2984.netwolves.com 6.3-RELEASE-p15 FreeBSD 6.3-RELEASE-p15 #17: >>>> Fri Apr 16 12:51:57 EST 2010 >>>> >>>> **** 4.9 ***** >>>> FreeBSD H101494.com 4.9-STABLE FreeBSD 4.9-STABLE #59: Thu Mar 30 >>>> 13:42:10 EST 2006 root@A1234.com:/mnt2/src/sys/compile/ i386 >>>> H101494# ipf -Fa >>>> H101494# ipfstat -nio >>>> empty list for ipfilter(out) >>>> empty list for ipfilter(in) >>>> H101494# ifconfig rl0 >>>> rl0: flags=8843 mtu 1500 >>>> inet 10.254.151.1 netmask 0xffffff00 broadcast 10.254.151.255 >>>> inet 10.255.3.30 netmask 0xffffffff broadcast 10.255.3.30 >>>> inet 10.255.4.30 netmask 0xffffffff broadcast 10.255.4.30 >>>> inet 169.254.202.1 netmask 0xffff0000 broadcast 169.254.255.255 >>>> ether 00:30:18:a3:49:b5 >>>> media: Ethernet autoselect (none) >>>> status: no carrier >>>> H101494# ping 169.254.202.1 >>>> PING 169.254.202.1 (169.254.202.1): 56 data bytes >>>> 64 bytes from 169.254.202.1: icmp_seq=0 ttl=64 time=0.052 ms >>>> 64 bytes from 169.254.202.1: icmp_seq=1 ttl=64 time=0.080 ms >>>> 64 bytes from 169.254.202.1: icmp_seq=2 ttl=64 time=0.081 ms >>>> ^C >>>> --- 169.254.202.1 ping statistics --- >>>> 3 packets transmitted, 3 packets received, 0% packet loss >>>> round-trip min/avg/max/stddev = 0.052/0.071/0.081/0.013 ms >>>> >>>> >>> >>> >>> That was a feature added to sys/netinet/in.c and ip_input.c back in 2007 >>> to obey RFC 3927 not to output datagrams destined for 169.254.0.0/16. >>> >>> On a system that needed to be able to send datagrams to 169.254.0.0/16 >>> addresses, I wrote this patch to add a sysctl knob net.inet.fwd_link_local >>> to dynamically allow a system to send those datagrams: >>> >>> >>> Index: in.c >>> =================================================================== >>> RCS file: /home/ncvs/src/sys/netinet/in.c,v >>> retrieving revision 1.102.2.4.2.1 >>> diff -u -r1.102.2.4.2.1 in.c >>> --- in.c 15 Apr 2009 03:14:26 -0000 1.102.2.4.2.1 >>> +++ in.c 29 Jul 2009 15:10:42 -0000 >>> @@ -67,6 +67,9 @@ >>> struct in_ifaddr *, struct sockaddr_in *, int); >>> static void in_purgemaddrs(struct ifnet *); >>> >>> +int ip_fwdlinklocal = 0; >>> +SYSCTL_INT(_net_inet_ip, OID_AUTO, fwd_link_local, CTLFLAG_RW, >>> +&ip_fwdlinklocal, 0, "Forward link-local addresses"); >>> static int subnetsarelocal = 0; >>> SYSCTL_INT(_net_inet_ip, OID_AUTO, subnets_are_local, CTLFLAG_RW, >>> &subnetsarelocal, 0, "Treat all subnets as directly connected"); >>> @@ -129,7 +132,8 @@ >>> register u_long i = ntohl(in.s_addr); >>> register u_long net; >>> >>> - if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || IN_LINKLOCAL(i)) >>> + if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || >>> + (!ip_fwdlinklocal&& IN_LINKLOCAL(i))) >>> return (0); >>> if (IN_CLASSA(i)) { >>> net = i& IN_CLASSA_NET; >>> Index: ip_input.c >>> =================================================================== >>> RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v >>> retrieving revision 1.332.2.5.2.1 >>> diff -u -r1.332.2.5.2.1 ip_input.c >>> --- ip_input.c 15 Apr 2009 03:14:26 -0000 1.332.2.5.2.1 >>> +++ ip_input.c 29 Jul 2009 15:10:44 -0000 >>> @@ -134,6 +134,7 @@ >>> static struct ifqueue ipintrq; >>> static int ipqmaxlen = IFQ_MAXLEN; >>> >>> +extern int ip_fwdlinklocal; >>> extern struct domain inetdomain; >>> extern struct protosw inetsw[]; >>> u_char ip_protox[IPPROTO_MAX]; >>> @@ -532,7 +533,7 @@ >>> } >>> } >>> /* RFC 3927 2.7: Do not forward datagrams for 169.254.0.0/16. */ >>> - if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { >>> + if (!ip_fwdlinklocal&& IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { >>> ipstat.ips_cantforward++; >>> m_freem(m); >>> return; >>> >>> >> >> Hmmm... how is not responding to pings associated with forwarding? > > Depends on where the box is located that you're pinging from and > to (network topology). It looks like that section of code (and ones > following it in the same function) just drops the packet on the floor > if people attempt to route packets to/from 169.254.x.x. > Thanks, > -Garrett > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Thanks to all that replied. I now have a better understanding of what is happening. -- "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)