>Number:         22431
>Category:       kern
>Synopsis:       TCP connection to IPv4-mapped IPv6 address advertises huge MSS
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 10 18:33:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Andreas Gustafsson
>Release:        NetBSD-current as of Aug 9, 2003
>Organization:
>Environment:
System: NetBSD 1.6W (GUITAR_KGDB) #0: Sat Aug  9 19:20:44 PDT 2003
Architecture: i386
Machine: i386
>Description:

When making an outgoing IPv4 TCP connection using an IPv6 socket and
mapped addresses (like Mozilla does), NetBSD advertises an excessively
large MSS, close to the MTU of the loopback interface, as shown by
<mss 33180> in the following tcpdump output:

  17:30:30.838490 adsl-63-197-0-204.dsl.snfc21.pacbell.net.50986 >
  turtiainen.dna.fi.www: S 3310369110:3310369110(0) win 16384 <mss 33180> (DF)

This happens regardless of the setting of net.inet.tcp.mss_ifmtu and
net.inet6.tcp6.mss_ifmtu.

Running the kernel under a debugger shows the following values in
tcp_output() at the time of the call to tcp_mss_to_advertise():

  (gdb) print tp->t_inpcb
  $9 = (struct inpcb *) 0x0
  (gdb) print tp->t_in6pcb
  $10 = (struct in6pcb *) 0xc0b1e900
  (gdb) print rt->rt_ifp->if_xname
  $14 = "lo0", '\0' <repeats 12 times>

In other words, tcp_output appears to incorrectly be using the MTU of
the loopback interface to calculate the advertised MSS, when it should
be using the MTU of the Ethernet interface used for the connection
(if net.inet.tcp.mss_ifmtu = 1) or the largest MTU of any
non-loopback interface (if net.inet.tcp.mss_ifmtu = 0).

Curiously, at the beginning of tcp_output(),
tp->t_in6pcb->in6p_route.ro_rt->rt_ifp is referring to fxp0, but after
tcp_output() calls tcp_segsize(), it has changed to refer to lo0.

>How-To-Repeat:

Using Mozilla from pkgsrc, try to visit a web page on a web server
whose TCP stack supports path MTU discovery but that does not receive
the ICMP messages needed to make it work correctly (I used
http://turtiainen.dna.fi/GPRS-HOWTO).

Notice that the HTTP transaction hangs, even though retrieving the
same page works fine using clients other than Mozilla.

>Fix:

Not known.
>Release-Note:
>Audit-Trail:
>Unformatted: