Date: Tue, 8 Jun 2010 13:40:53 -0500 From: Guy Helmer <ghelmer@palisadesystems.com> To: sclark46@earthlink.net Cc: bms@freebsd.org, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: FreeBSD eats 169.254.x.x addressed packets Message-ID: <8C598A97-0F1E-44A1-BAFE-48927C143553@palisadesystems.com> In-Reply-To: <4C0E8C59.5010202@earthlink.net> References: <4C0E81D7.8020209@earthlink.net> <A289320A-8306-427B-A834-2D5DCD851F0C@palisadesystems.com> <4C0E8C59.5010202@earthlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 8, 2010, at 1:30 PM, Stephen Clark wrote:
> On 06/08/2010 02:21 PM, Guy Helmer wrote:
>> On Jun 8, 2010, at 12:45 PM, Stephen Clark wrote:
>>=20
>>> Hi,
>>>=20
>>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when
>>> 4.9 didn't?
>>>=20
>>> ***** 6.3 *****
>>> $ sudo ipfstat -nio
>>> empty list for ipfilter(out)
>>> empty list for ipfilter(in)
>>> Z2984:~
>>> $ ifconfig rl0
>>> rl0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>> options=3D8<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
>>>=20
>>> **** 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=3D8843<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=3D0 ttl=3D64 time=3D0.052 ms
>>> 64 bytes from 169.254.202.1: icmp_seq=3D1 ttl=3D64 time=3D0.080 ms
>>> 64 bytes from 169.254.202.1: icmp_seq=3D2 ttl=3D64 time=3D0.081 ms
>>> ^C
>>> --- 169.254.202.1 ping statistics ---
>>> 3 packets transmitted, 3 packets received, 0% packet loss
>>> round-trip min/avg/max/stddev =3D 0.052/0.071/0.081/0.013 ms
>>>=20
>>>=20
>>=20
>>=20
>> 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.
>>=20
>> 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:
>>=20
>>=20
>> Index: in.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> 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 *);
>>=20
>> +int ip_fwdlinklocal =3D 0;
>> +SYSCTL_INT(_net_inet_ip, OID_AUTO, fwd_link_local, CTLFLAG_RW,
>> + &ip_fwdlinklocal, 0, "Forward link-local addresses");
>> static int subnetsarelocal =3D 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 =3D ntohl(in.s_addr);
>> register u_long net;
>>=20
>> - 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 =3D i& IN_CLASSA_NET;
>> Index: ip_input.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> 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 =3D IFQ_MAXLEN;
>>=20
>> +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;
>>=20
>>=20
> Hmmm... how is not responding to pings associated with forwarding?
>=20
My previous understanding was that RFC 3927 did not allow transmitting =
datagrams involving the 169.254.0.0/16 link-local prefix; now that I've =
looked over the RFC more closely, I'm not sure that is the case.
I have cc'ed Bruce Simpson on this message in hopes that he can shed =
some light on this. I believe he committed the change that disallowed =
transmitting from 169.254.0.0/16 addresses.
Guy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C598A97-0F1E-44A1-BAFE-48927C143553>