FreeBSD eats 169.254.x.x addressed packets
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 0xff00 broadcast 192.168.129.255 inet 169.254.1.1 netmask 0x 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 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 mtu 1500 inet 10.254.151.1 netmask 0xff00 broadcast 10.254.151.255 inet 10.255.3.30 netmask 0x broadcast 10.255.3.30 inet 10.255.4.30 netmask 0x broadcast 10.255.4.30 inet 169.254.202.1 netmask 0x 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 Thanks, Steve -- "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) ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
Guy Helmer wrote: > 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. > RFC 3927 is pretty clear that 169.254.0.0/16 traffic is not to be forwarded beyond the link. I do not understand why the OP is losing traffic, unless he's relying on pre-RFC 3927 behaviour in his network topology. The IN_LINKLOCAL() check happens after ip_input() walks the address hash looking for exact address matches. So if an interface has a link-local address, the packet should get delivered upstack as usual. When I made this change, link-local addressing couldn't be fully implemented in FreeBSD, due to the lack of support for address scopes in the FreeBSD IPv4 code. Hopefully new people can pick up on it as they wish. thanks BMS ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > 4.9 didn't? The following output would help: - ifconfig -a - netstat -rn - Contents of /etc/rc.conf Also, be aware that RELENG_6 is to be EOL'd at the end of this year: http://security.freebsd.org/ -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when 4.9 didn't? The following output would help: - ifconfig -a - netstat -rn - Contents of /etc/rc.conf Also, be aware that RELENG_6 is to be EOL'd at the end of this year: http://security.freebsd.org/ Hi Jeremy, I am not sure that information is relevant. We have two systems configured identically one using 4.9 the other 6.3. We were replacing the 4.9 system with the 6.3 system. The internal lan had been setup on the 4.9 box using dhcpd handing out ip addresses in the 169.254.202/24 range. This box had been working for years. When we replaced it with the identically configured 6.3 box we could no longer ping the internal interface which had an ip address of 169.254.202.1. So after spending about a day trouble shooting we finally realized if we changed the address to 169.253.202.1 everything worked on the 6.3 box. Investigating the 169.254.x.x address shows it is normally used when a box can't get an address using dhcp so it assigns one randomly from the 169.254.x.x address space. I don't know what happened with 6.3 but any 6.3 box we assign and address in that range then you can't ping the address. This is from another box. srmrd# ifconfig bge0 169.254.1.1 srmrd# ping 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes ^C --- 169.254.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss srmrd# netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.198.252UGS 0 2711166 fxp0 10.0.128/17link#1 UC 00 fxp0 10.0.128.1 00:30:18:a3:47:a5 UHLW1 3805 fxp0 1155 10.0.129.5 00:00:24:ca:65:ec UHLW133348 fxp0 1154 10.0.129.9100:1c:c0:94:3a:12 UHLW1 149 fxp0773 10.0.129.101 00:b0:d0:fe:89:d9 UHLW1 58lo0 127.0.0.1 127.0.0.1 UH 018437lo0 169.254link#2 UC 00 bge0 169.254.1.100:b0:d0:fe:89:da UHLW13lo0 192.168.198link#1 UC 00 fxp0 192.168.198.94 00:02:b6:36:e9:4a UHLW1 1490 fxp0 1113 192.168.198.98 00:90:c2:c7:5e:78 UHLW1 3369 fxp0255 192.168.198.10100:04:23:b6:da:8d UHLW1 1458 fxp0 1153 192.168.198.25200:30:18:a3:47:90 UHLW20 fxp0 1144 192.168.198.25300:30:18:a3:47:a3 UHLW125662 fxp0801 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 srmrd# uname -a FreeBSD srmrd.com 6.3-RELEASE-p13 FreeBSD 6.3-RELEASE-p13 #1: Tue Oct 13 09:07:05 EDT 2009 r...@srmrd..com:/usr/src/sys/i386/compile/SMP i386 ** Here I added an alias ip srmrd# ifconfig bge0 alias 169.253.1.1 srmrd# ping 169.253.1.1 PING 169.253.1.1 (169.253.1.1): 56 data bytes 64 bytes from 169.253.1.1: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 169.253.1.1: icmp_seq=1 ttl=64 time=0.055 ms 64 bytes from 169.253.1.1: icmp_seq=2 ttl=64 time=0.056 ms 64 bytes from 169.253.1.1: icmp_seq=3 ttl=64 time=0.053 ms 64 bytes from 169.253.1.1: icmp_seq=4 ttl=64 time=0.061 ms ^C --- 169.253.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.053/0.061/0.082/0.011 ms srmrd# netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.198.252UGS 0 2711166 fxp0 10.0.128/17link#1 UC 00 fxp0 10.0.128.1 00:30:18:a3:47:a5 UHLW1 3805 fxp0892 10.0.129.5 00:00:24:ca:65:ec UHLW133356 fxp0 1128 10.0.129.9100:1c:c0:94:3a:12 UHLW1 274 fxp0510 10.0.129.101 00:b0:d0:fe:89:d9 UHLW1 58lo0 127.0.0.1 127.0.0.1 UH 018437lo0 169.253link#2 UC 00 bge0 169.253.1.100:b0:d0:fe:89:da UHLW1 10lo0 169.254link#2 UC 00 bge0 169.254.1.100:b0:d0:fe:89:da UHLW13lo0 192.168.198link#1 UC 00 fxp0 192.168
Re: FreeBSD eats 169.254.x.x addressed packets
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 0xff00 broadcast 192.168.129.255
inet 169.254.1.1 netmask 0x 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 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 mtu 1500
inet 10.254.151.1 netmask 0xff00 broadcast 10.254.151.255
inet 10.255.3.30 netmask 0x broadcast 10.255.3.30
inet 10.255.4.30 netmask 0x broadcast 10.255.4.30
inet 169.254.202.1 netmask 0x 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.c15 Apr 2009 03:14:26 - 1.102.2.4.2.1
+++ in.c29 Jul 2009 15:10:42 -
@@ -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 - 1.332.2.5.2.1
+++ ip_input.c 29 Jul 2009 15:10:44 -
@@ -134,6 +134,7 @@
static struct ifqueue ipintrq;
static intipqmaxlen = IFQ_MAXLEN;
+extern int ip_fwdlinklocal;
externstruct domain inetdomain;
externstruct protosw inetsw[];
u_charip_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)
___
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"
Re: FreeBSD eats 169.254.x.x addressed packets
On Tue, 08 Jun 2010 14:30:49 -0400 Stephen Clark wrote: > Hmmm... how is not responding to pings associated with forwarding? See http://en.wikipedia.org/wiki/169.254 Link Local addresses are special. HTH -- Regards, Torfinn Ingolfsen ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On Tue, Jun 8, 2010 at 11:26 AM, Stephen Clark wrote: > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: >> >> On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: >>> >>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >>> 4.9 didn't? >> >> The following output would help: >> >> - ifconfig -a >> - netstat -rn >> - Contents of /etc/rc.conf >> >> Also, be aware that RELENG_6 is to be EOL'd at the end of this year: >> http://security.freebsd.org/ >> > Hi Jeremy, > > I am not sure that information is relevant. We have two systems configured > identically one using 4.9 the other 6.3. > > We were replacing the 4.9 system with the 6.3 system. > The internal lan had been setup on the 4.9 box using dhcpd > handing out ip addresses in the 169.254.202/24 range. > > This box had been working for years. > > When we replaced it with the identically configured 6.3 box > we could no longer ping the internal interface which had an ip > address of 169.254.202.1. So after spending about a day trouble > shooting we finally realized if we changed the address to > 169.253.202.1 everything worked on the 6.3 box. Yes... the problem is that you're handing out auto-DHCP IP addresses to clients using dhcpd .. I wouldn't expect this to work particularly well unless you have routing set up for that (especially because there is code in the kernel that is explicitly told to not route packets from this psuedo subnet due to an RFC change (look for RFC 3927 2.7 under sys/netinet/ip_input.c). Thanks, -Garrett ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2010 19:05:06, Jeremy Chadwick wrote: > On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: >> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >> 4.9 didn't? > > The following output would help: > > - ifconfig -a > - netstat -rn > - Contents of /etc/rc.conf > > Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > http://security.freebsd.org/ > 169.254.0.0/16 is reserved address space for "Dynamic Configuration of IPv4 Link-Local Addresses" -- see RFC 3927. I'm sure you know all this, as you wouldn't have any other reason to be using addresses from that range. Basically it's an IPv4 equivalent to the IPv6 rtadv/rtsol thing. The addresses from that range are non-routable, similarly to the RFC 1918 private ranges, but that's just a convention for RFC1918, and I can see there is special code to handle RFC 3927 eg in: http://lists.freebsd.org/pipermail/svn-src-head/2009-September/00.html Are you using avahi-autoipd ? Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwOjikACgkQ8Mjk52CukIyQLgCfXU3ta0DDR3igI1GowZ+SS0LM V/4AnApoNaezDb8cj3OuWOImQ90GZ9j+ =A7eE -END PGP SIGNATURE- ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
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 0xff00 broadcast 192.168.129.255
>>> inet 169.254.1.1 netmask 0x 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 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 mtu 1500
>>> inet 10.254.151.1 netmask 0xff00 broadcast 10.254.151.255
>>> inet 10.255.3.30 netmask 0x broadcast 10.255.3.30
>>> inet 10.255.4.30 netmask 0x broadcast 10.255.4.30
>>> inet 169.254.202.1 netmask 0x 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 - 1.102.2.4.2.1
>> +++ in.c 29 Jul 2009 15:10:42 -
>> @@ -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 - 1.332.2.5.2.1
>> +++ ip_input.c 29 Jul 2009 15:10:44 -
>> @@ -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 dro
Re: FreeBSD eats 169.254.x.x addressed packets
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:
>>
>>> 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 0xff00 broadcast 192.168.129.255
>>>inet 169.254.1.1 netmask 0x 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 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 mtu 1500
>>>inet 10.254.151.1 netmask 0xff00 broadcast 10.254.151.255
>>>inet 10.255.3.30 netmask 0x broadcast 10.255.3.30
>>>inet 10.255.4.30 netmask 0x broadcast 10.255.4.30
>>>inet 169.254.202.1 netmask 0x 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 - 1.102.2.4.2.1
>> +++ in.c 29 Jul 2009 15:10:42 -
>> @@ -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 - 1.332.2.5.2.1
>> +++ ip_input.c 29 Jul 2009 15:10:44 -
>> @@ -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?
>
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 c
Re: FreeBSD eats 169.254.x.x addressed packets
On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > >>4.9 didn't? > > > >The following output would help: > > > >- ifconfig -a > >- netstat -rn > >- Contents of /etc/rc.conf > > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > >http://security.freebsd.org/ > > > Hi Jeremy, > > I am not sure that information is relevant. We have two systems configured > identically one using 4.9 the other 6.3. My concern was that someone had botched something up in rc.conf or during the OS upgrade/migration, resulting in there being no loopback interface. I also wanted to verify that your routing table looked correct for what ifconfig showed. Other users pointed you to RFC 3927. Wikipedia has this to say: http://en.wikipedia.org/wiki/Link-local_address "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. However, the first and last /24 subnet (256 addresses each) in this block have been excluded from use and are reserved by the standard.[1]" I read this to mean 169.254.0.0/24 and 169.254.255.0/24. Your previous ifconfig statement shows: > $ ifconfig rl0 > rl0: flags=8843 mtu 1500 > options=8 > inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255 > inet 169.254.1.1 netmask 0x broadcast 169.254.255.255 > ether 00:30:18:ae:7c:77 > media: Ethernet autoselect (100baseTX ) > status: active With this configuration, you're using both the first and last /24 netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 for your broadcast address. You should be able to avoid this by using 169.254.1.0/24. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
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=8843mtu 1500
options=8
inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255
inet 169.254.1.1 netmask 0x 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 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=8843mtu 1500
inet 10.254.151.1 netmask 0xff00 broadcast 10.254.151.255
inet 10.255.3.30 netmask 0x broadcast 10.255.3.30
inet 10.255.4.30 netmask 0x broadcast 10.255.4.30
inet 169.254.202.1 netmask 0x 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.c15 Apr 2009 03:14:26 - 1.102.2.4.2.1
+++ in.c29 Jul 2009 15:10:42 -
@@ -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 - 1.332.2.5.2.1
+++ ip_input.c 29 Jul 2009 15:10:44 -
@@ -134,6 +134,7 @@
static struct ifqueue ipintrq;
static intipqmaxlen = IFQ_MAXLEN;
+extern int ip_fwdlinklocal;
externstruct domain inetdomain;
externstruct protosw inetsw[];
u_charip_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-unsubscr...@freebsd.org"
Re: FreeBSD eats 169.254.x.x addressed packets
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 0xff00 broadcast 192.168.129.255
>inet 169.254.1.1 netmask 0x 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 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 mtu 1500
>inet 10.254.151.1 netmask 0xff00 broadcast 10.254.151.255
>inet 10.255.3.30 netmask 0x broadcast 10.255.3.30
>inet 10.255.4.30 netmask 0x broadcast 10.255.4.30
>inet 169.254.202.1 netmask 0x 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.c15 Apr 2009 03:14:26 - 1.102.2.4.2.1
+++ in.c29 Jul 2009 15:10:42 -
@@ -67,6 +67,9 @@
struct in_ifaddr *, struct sockaddr_in *, int);
static voidin_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 - 1.332.2.5.2.1
+++ ip_input.c 29 Jul 2009 15:10:44 -
@@ -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"
Re: FreeBSD eats 169.254.x.x addressed packets
On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: > On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > > >>4.9 didn't? > > > > > >The following output would help: > > > > > >- ifconfig -a > > >- netstat -rn > > >- Contents of /etc/rc.conf > > > > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > > >http://security.freebsd.org/ > > > > > Hi Jeremy, > > > > I am not sure that information is relevant. We have two systems configured > > identically one using 4.9 the other 6.3. > > My concern was that someone had botched something up in rc.conf or > during the OS upgrade/migration, resulting in there being no loopback > interface. I also wanted to verify that your routing table looked > correct for what ifconfig showed. > > Other users pointed you to RFC 3927. Wikipedia has this to say: > > http://en.wikipedia.org/wiki/Link-local_address > > "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. > However, the first and last /24 subnet (256 addresses each) in this > block have been excluded from use and are reserved by the standard.[1]" > > I read this to mean 169.254.0.0/24 and 169.254.255.0/24. > > Your previous ifconfig statement shows: > > > $ ifconfig rl0 > > rl0: flags=8843 mtu 1500 > > options=8 > > inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255 > > inet 169.254.1.1 netmask 0x broadcast 169.254.255.255 > > ether 00:30:18:ae:7c:77 > > media: Ethernet autoselect (100baseTX ) > > status: active > > With this configuration, you're using both the first and last /24 > netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 > for your broadcast address. > > You should be able to avoid this by using 169.254.1.0/24. > RFC 3927 also has complicated rules involving when one can or should not use a link-local address on the same interface as a routable IP, so at best your configuration may not be supported anyway. One should not use a link-local address as if it were under RFC 1918 rules, in particular because link-local involves self-assigned addresses and internal conflict mitigation. -- === Peter C. Lai | Bard College at Simon's Rock Systems Administrator| 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 === ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On Tue, Jun 08, 2010 at 02:49:20PM -0400, Peter C. Lai wrote:
> On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote:
> > On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote:
> > > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote:
> > > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote:
> > > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when
> > > >>4.9 didn't?
> > > >
> > > >The following output would help:
> > > >
> > > >- ifconfig -a
> > > >- netstat -rn
> > > >- Contents of /etc/rc.conf
> > > >
> > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year:
> > > >http://security.freebsd.org/
> > > >
> > > Hi Jeremy,
> > >
> > > I am not sure that information is relevant. We have two systems configured
> > > identically one using 4.9 the other 6.3.
> >
> > My concern was that someone had botched something up in rc.conf or
> > during the OS upgrade/migration, resulting in there being no loopback
> > interface. I also wanted to verify that your routing table looked
> > correct for what ifconfig showed.
> >
> > Other users pointed you to RFC 3927. Wikipedia has this to say:
> >
> > http://en.wikipedia.org/wiki/Link-local_address
> >
> > "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses.
> > However, the first and last /24 subnet (256 addresses each) in this
> > block have been excluded from use and are reserved by the standard.[1]"
> >
> > I read this to mean 169.254.0.0/24 and 169.254.255.0/24.
> >
> > Your previous ifconfig statement shows:
> >
> > > $ ifconfig rl0
> > > rl0: flags=8843 mtu 1500
> > > options=8
> > > inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255
> > > inet 169.254.1.1 netmask 0x broadcast 169.254.255.255
> > > ether 00:30:18:ae:7c:77
> > > media: Ethernet autoselect (100baseTX )
> > > status: active
> >
> > With this configuration, you're using both the first and last /24
> > netblocks -- 169.254.0.0 for your network address, and 169.254.255.255
> > for your broadcast address.
> >
> > You should be able to avoid this by using 169.254.1.0/24.
> >
>
> RFC 3927 also has complicated rules involving when one can or should not
> use a link-local address on the same interface as a routable IP, so at
> best your configuration may not be supported anyway. One should not use
> a link-local address as if it were under RFC 1918 rules, in particular
> because link-local involves self-assigned addresses and internal
> conflict mitigation.
Thanks for the addendum, Peter. You're absolutely right.
Furthermore, I looked at the IN_LINKLOCAL() macro and relevant code:
include/netinet/in.h:#define IN_LINKLOCAL(i)(((u_int32_t)(i) & 0x)
== 0xa9fe)
- if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) {
+ if (!ip_fwdlinklocal && IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) {
I assume ip->ip_dst.s_addr is the source address of a packet destined
somewhere (in the OP's case, this would be 169.254.1.1). If my
assumption is correct, then the above macro filters out the last two
octets of the source address, leaving only the first two, comparing
those to 0xa9 and 0xfe respectively (decimal = 169 and 254). If true,
then the if() statement applies, which I assume blackholes it.
Based on that, I don't think using a smaller block like 169.254.1.0/24
would work; seems FreeBSD does what it does against the entire /16.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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"
Re: FreeBSD eats 169.254.x.x addressed packets
On 06/08/2010 02:49 PM, Peter C. Lai wrote: On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when 4.9 didn't? The following output would help: - ifconfig -a - netstat -rn - Contents of /etc/rc.conf Also, be aware that RELENG_6 is to be EOL'd at the end of this year: http://security.freebsd.org/ Hi Jeremy, I am not sure that information is relevant. We have two systems configured identically one using 4.9 the other 6.3. My concern was that someone had botched something up in rc.conf or during the OS upgrade/migration, resulting in there being no loopback interface. I also wanted to verify that your routing table looked correct for what ifconfig showed. Other users pointed you to RFC 3927. Wikipedia has this to say: http://en.wikipedia.org/wiki/Link-local_address "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. However, the first and last /24 subnet (256 addresses each) in this block have been excluded from use and are reserved by the standard.[1]" I read this to mean 169.254.0.0/24 and 169.254.255.0/24. Your previous ifconfig statement shows: $ ifconfig rl0 rl0: flags=8843 mtu 1500 options=8 inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255 inet 169.254.1.1 netmask 0x broadcast 169.254.255.255 ether 00:30:18:ae:7c:77 media: Ethernet autoselect (100baseTX) status: active With this configuration, you're using both the first and last /24 netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 for your broadcast address. You should be able to avoid this by using 169.254.1.0/24. RFC 3927 also has complicated rules involving when one can or should not use a link-local address on the same interface as a routable IP, so at best your configuration may not be supported anyway. One should not use a link-local address as if it were under RFC 1918 rules, in particular because link-local involves self-assigned addresses and internal conflict mitigation. Again what happened we had a box in the field that was running 4.9 being used as a router/nat/vpn/firewall device. It was handing out ip addresses to the internal lan using the range 169.254.202.0/24, who knows why this address range was picked. It worked great but the hardware died, so we were replacing it with our current SW which is based on 6.3 we duplicated the configuration and have been struggling trying to get it to work for the customer since Saturday with no luck. Today I finally tried to ping the internal address from the box itself and it wouldn't ping, so I started trying using other addresses on the internal interface and they worked but not 169.254.202.1. In googling I discovered that 169.254/16 was supposed to be assigned if a box couldn't obtain an ip but saw nothing about an OS dropping them. So anyway I know the reason behind the change now. -- "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) ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On 06/08/2010 03:00 PM, Stephen Clark wrote: On 06/08/2010 02:49 PM, Peter C. Lai wrote: On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when 4.9 didn't? The following output would help: - ifconfig -a - netstat -rn - Contents of /etc/rc.conf Also, be aware that RELENG_6 is to be EOL'd at the end of this year: http://security.freebsd.org/ Hi Jeremy, I am not sure that information is relevant. We have two systems configured identically one using 4.9 the other 6.3. My concern was that someone had botched something up in rc.conf or during the OS upgrade/migration, resulting in there being no loopback interface. I also wanted to verify that your routing table looked correct for what ifconfig showed. Other users pointed you to RFC 3927. Wikipedia has this to say: http://en.wikipedia.org/wiki/Link-local_address "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. However, the first and last /24 subnet (256 addresses each) in this block have been excluded from use and are reserved by the standard.[1]" I read this to mean 169.254.0.0/24 and 169.254.255.0/24. Your previous ifconfig statement shows: $ ifconfig rl0 rl0: flags=8843 mtu 1500 options=8 inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255 inet 169.254.1.1 netmask 0x broadcast 169.254.255.255 ether 00:30:18:ae:7c:77 media: Ethernet autoselect (100baseTX) status: active With this configuration, you're using both the first and last /24 netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 for your broadcast address. You should be able to avoid this by using 169.254.1.0/24. RFC 3927 also has complicated rules involving when one can or should not use a link-local address on the same interface as a routable IP, so at best your configuration may not be supported anyway. One should not use a link-local address as if it were under RFC 1918 rules, in particular because link-local involves self-assigned addresses and internal conflict mitigation. Again what happened we had a box in the field that was running 4.9 being used as a router/nat/vpn/firewall device. It was handing out ip addresses to the internal lan using the range 169.254.202.0/24, who knows why this address range was picked. It worked great but the hardware died, so we were replacing it with our current SW which is based on 6.3 we duplicated the configuration and have been struggling trying to get it to work for the customer since Saturday with no luck. Today I finally tried to ping the internal address from the box itself and it wouldn't ping, so I started trying using other addresses on the internal interface and they worked but not 169.254.202.1. In googling I discovered that 169.254/16 was supposed to be assigned if a box couldn't obtain an ip but saw nothing about an OS dropping them. So anyway I know the reason behind the change now. One final comment - I still don't understand why FreeBSD "won't" respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it "would" respond to pings. -- "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) ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On Wed, Jun 09, 2010 at 07:59:16AM -0400, Stephen Clark wrote: > On 06/08/2010 03:00 PM, Stephen Clark wrote: > >On 06/08/2010 02:49 PM, Peter C. Lai wrote: > >>On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: > >>>On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > >>4.9 didn't? > > > >The following output would help: > > > >- ifconfig -a > >- netstat -rn > >- Contents of /etc/rc.conf > > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > >http://security.freebsd.org/ > > > Hi Jeremy, > > I am not sure that information is relevant. We have two systems > configured > identically one using 4.9 the other 6.3. > >>> > >>>My concern was that someone had botched something up in rc.conf or > >>>during the OS upgrade/migration, resulting in there being no loopback > >>>interface. I also wanted to verify that your routing table looked > >>>correct for what ifconfig showed. > >>> > >>>Other users pointed you to RFC 3927. Wikipedia has this to say: > >>> > >>>http://en.wikipedia.org/wiki/Link-local_address > >>> > >>>"Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. > >>>However, the first and last /24 subnet (256 addresses each) in this > >>>block have been excluded from use and are reserved by the standard.[1]" > >>> > >>>I read this to mean 169.254.0.0/24 and 169.254.255.0/24. > >>> > >>>Your previous ifconfig statement shows: > >>> > $ ifconfig rl0 > rl0: flags=8843 mtu 1500 > options=8 > inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255 > inet 169.254.1.1 netmask 0x broadcast 169.254.255.255 > ether 00:30:18:ae:7c:77 > media: Ethernet autoselect (100baseTX) > status: active > >>> > >>>With this configuration, you're using both the first and last /24 > >>>netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 > >>>for your broadcast address. > >>> > >>>You should be able to avoid this by using 169.254.1.0/24. > >>> > >> > >>RFC 3927 also has complicated rules involving when one can or should not > >>use a link-local address on the same interface as a routable IP, so at > >>best your configuration may not be supported anyway. One should not use > >>a link-local address as if it were under RFC 1918 rules, in particular > >>because link-local involves self-assigned addresses and internal > >>conflict mitigation. > >> > >Again what happened we had a box in the field that was running 4.9 being > >used as a router/nat/vpn/firewall device. It was handing out ip addresses > >to the internal lan using the range 169.254.202.0/24, who knows why this > >address range was picked. It worked great but > >the hardware died, so we were replacing it with our current SW which is > >based on 6.3 we duplicated the configuration and have been struggling > >trying to > >get it to work for the customer since Saturday with no luck. Today I > >finally > >tried to ping the internal address from the box itself and it wouldn't > >ping, > >so I started trying using other addresses on the internal interface and > >they > >worked but not 169.254.202.1. In googling I discovered that 169.254/16 > >was supposed to be assigned if a box couldn't obtain an ip but saw > >nothing about > >an OS dropping them. > > > >So anyway I know the reason behind the change now. > > > One final comment - I still don't understand why FreeBSD "won't" respond to > pings > when it has an address like 169.254.1.1. I can ssh to the unit but it won't > respond to pings. I tried setting up a linux box with an address like > 169.254.1.2 and it "would" respond to pings. I tried to explain it as best as I could here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057191.html The IP stack (not a firewall, etc.) is basically blackholing the packet. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
One final comment - I still don't understand why FreeBSD "won't" respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it "would" respond to pings. Linux is not really any measuring stick in standard compliance... -Reko ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On 06/09/2010 08:28 AM, Reko Turja wrote: One final comment - I still don't understand why FreeBSD "won't" respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it "would" respond to pings. Linux is not really any measuring stick in standard compliance... -Reko ___ 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" But reading the RFC it says the packets should not be routed - I don't see where it says that pings should not be responded to. Think about it the RFC was for link local devices - shouldn't on device on a link be able to ping another device and get a response. -- "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) ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
On 06/09/2010 08:28, Reko Turja wrote: >> One final comment - I still don't understand why FreeBSD "won't" >> respond to pings >> when it has an address like 169.254.1.1. I can ssh to the unit but it >> won't >> respond to pings. I tried setting up a linux box with an address like >> 169.254.1.2 and it "would" respond to pings. > > Linux is not really any measuring stick in standard compliance... > I do not believe that is what he was implying by comparing this to Linux. I think he might be using Linux as a example of "They have not limited their users to only changing source code" to get the objective completed. They should have. In this case and reviewing the previous messages + remembering these: http://bit.ly/9sigji http://bit.ly/9pfE9A http://bit.ly/9CNT3K FreeBSD takes the correct action for this scenario which could proudly be used as an exemplary piece of code that other forms of OS's should use as a reference for integrity. http://bit.ly/byHBzN Regards, -- jhell ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
> > One final comment - I still don't understand why FreeBSD "won't" > > respond to pings > > when it has an address like 169.254.1.1. I can ssh to the unit but > > it won't > > respond to pings. I tried setting up a linux box with an address > > like > > 169.254.1.2 and it "would" respond to pings. > > Linux is not really any measuring stick in standard compliance... If 169.254.0.0/16 addresses are supposed to be link local then I'd definitely expect a reply to a ping from another box on the same LAN, sourced from another 169.254.0.0/16 address. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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"
Re: FreeBSD eats 169.254.x.x addressed packets
> > > One final comment - I still don't understand why FreeBSD "won't" > > > respond to pings > > > when it has an address like 169.254.1.1. I can ssh to the unit but > > > it won't > > > respond to pings. I tried setting up a linux box with an address > > > like > > > 169.254.1.2 and it "would" respond to pings. > > > > Linux is not really any measuring stick in standard compliance... > > If 169.254.0.0/16 addresses are supposed to be link local then I'd > definitely expect a reply to a ping from another box on the same > LAN, sourced from another 169.254.0.0/16 address. Having tested this in the lab I'd say FreeBSD 7.x works exactly as expected. Traffic on the same LAN works, traffic to other LANs is not routed. All is well. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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"
