Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 08 Jun 2010 14:45:24 -0400
From:      Stephen Clark <sclark46@earthlink.net>
To:        Garrett Cooper <yanefbsd@gmail.com>
Cc:        Guy Helmer <ghelmer@palisadesystems.com>, FreeBSD Stable <freebsd-stable@freebsd.org>
Subject:   Re: FreeBSD eats 169.254.x.x addressed packets
Message-ID:  <4C0E8FC4.7070009@earthlink.net>
In-Reply-To: <AANLkTikXBgxRV4OHMxg-SAPhjNFOTTPJ4JtcMDl25BQH@mail.gmail.com>
References:  <4C0E81D7.8020209@earthlink.net>	<A289320A-8306-427B-A834-2D5DCD851F0C@palisadesystems.com>	<4C0E8C59.5010202@earthlink.net> <AANLkTikXBgxRV4OHMxg-SAPhjNFOTTPJ4JtcMDl25BQH@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 06/08/2010 02:40 PM, Garrett Cooper wrote:
> On Tue, Jun 8, 2010 at 11:30 AM, Stephen Clark<sclark46@earthlink.net>  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<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
>>>> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>    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)





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C0E8FC4.7070009>