lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 21 Jan 2008 05:52:27 -0500
From:	Jim Paris <jim@...n.com>
To:	netdev@...r.kernel.org
Subject: IPv6 problems (mtu is less than advmss?)

Hi,

When the IPv6 default route is first autoconfigured, it seems the
advertised MSS doesn't get set properly.

I have computer A connected to an external interface with IPv4 and
tunneling IPv6 using 6to4.  It runs radvd on an internal interface to
provide connectivity to my LAN.  radvd.conf contains:

  interface brint {
	AdvLinkMTU 1420;    # advertise tiny MTU due to tunnel
	AdvSendAdvert on;
	prefix 0:0:0:1::/64
	{ Base6to4Interface brext; };
  };

Computer B is on the LAN and autoconfigures an IPv6 address.  However,
I have problems with some specific hosts [1].  They're probably doing
broken ICMP/PMTU filtering or something, but I've tracked down some
weirdness in the kernel:

  computerA# /etc/init.d/radvd start

  computerB# ifconfig eth0 down
  computerB# ifconfig eth0 up
  computerB# ip -6 route
  2002:125f:205:1::/64 dev eth0  proto kernel  metric 256  expires 2592312sec mtu 1420 advmss 1360 hoplimit 4294967295
  fe80::/64 dev eth0  metric 256  expires 21334361sec mtu 1420 advmss 1360 hoplimit 4294967295
  ff00::/8 dev eth0  metric 256  expires 21334361sec mtu 1420 advmss 1360 hoplimit 4294967295
  default via fe80::230:48ff:fe8b:5df4 dev eth0  proto kernel  metric 1024  expires 1788sec mtu 1420 advmss 1440 hoplimit 64

At this point, I see the network problems.  Note how the advmss in the
last line is not only larger than all the other lines, it's even
bigger than the MTU.  I won't be able to download [1] until I manually
fix advmss, _or_ just restart radvd on the other computer:

  computerA# /etc/init.d/radvd restart

  computerB# ip -6 route
  2002:125f:205:1::/64 dev eth0  proto kernel  metric 256  expires 2592160sec mtu 1420 advmss 1360 hoplimit 4294967295
  fe80::/64 dev eth0  metric 256  expires 21334355sec mtu 1420 advmss 1360 hoplimit 4294967295
  ff00::/8 dev eth0  metric 256  expires 21334355sec mtu 1420 advmss 1360 hoplimit 4294967295
  default via fe80::230:48ff:fe8b:5df4 dev eth0  proto kernel  metric 1024  expires 1798sec mtu 1420 advmss 1360 hoplimit 64

Now the advmss is better and everything works fine.  It seems that if
it's being created for the first time, the advmss is not correctly set
based on the MTU, but if there's already a route when it gets the RA,
it reconfigures it correctly.

Computer A is 2.6.23.1 and computer B is 2.6.24-rc8, both x86_64.

Any suggestions or other debugging I can do?

-jim

[1] wget -6 http://releases.mozilla.org/pub/mozilla.org/addons/12/all-in-one_gestures-0.18.0-fx.xpi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ