Re: kern/25702 (ftp transfer from client panics 2.0 NAT router)

[Darren Reed <darrenr%netbsd.org@localhost>]

The following reply was made to PR kern/25702; it has been noted by GNATS.

From: Darren Reed <darrenr%netbsd.org@localhost>
To: Martin Husemann <martin%duskware.de@localhost>
Cc: matthew green <mrg%eterna.com.au@localhost>, 
gnats-bugs%NetBSD.org@localhost, 
 ipf-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
 netbsd-bugs%netbsd.org@localhost, Hauke Fath 
<hauke%Espresso.Rhein-Neckar.DE@localhost>
Subject: Re: kern/25702 (ftp transfer from client panics 2.0 NAT router)
Date: Tue, 29 Jan 2008 10:32:29 +1100

 Your connection to 193.155.17.9 behaves very strangely...
 
 Firstly, the remote web server does not appear to be
 using PMTU discovery for you.  (I also see this.)
 
 Secondly, because of PMTU discovery not being active,
 there is fragmentation *BUT* fragmentation for pppoe is
 just bizarre: the first packet is 44 (20+24) bytes long,
 the second 1448 (20+8+1420), splitting the TCP header
 (32 bytes long) across the two packets.  It feels like
 someone is trying to put all of the TCP header in one
 fragment (but failing) so that all of the TCP data goes
 in another fragment, however that is pure speculation.
 
 The remote is also offering an MSS much lower than yours,
 1420 vs 1452, but with NATs sometimes messing about with
 this field, it is hard to know which one(s) are the real
 MSS's being advertised.  The smaller advertisement feels
 like artificial adjustments to take into account something
 else being broken (and the fragmentation above definitely
 suggests something bizarre is going on.)
 
 Are you logging all packets that get blocked by ipf?
 
 Darren