FreeBSD eats 169.254.x.x addressed packets

[Stephen Clark]

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 at 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?

-- 

"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)