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 r...@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;
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
