NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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 04:33:32 +1100

 Martin Husemann wrote:
 > On Thu, Jan 24, 2008 at 10:37:31AM +1100, matthew green wrote:
 >> i was able to fetch this file from behind a netbsd/sparc64
 >> 4.0_BETA2 system from a netbsd/i386 client.
 > 
 > I am still unable to fetch it with a router running 4.0/sparc64.
 > Maybe it's not the machine, but the mtu or something?
 
 Having looked at some tcpdump data, it would appear that either:
 (a) the packet is being truncated and the TCP header length is
      not being fixed or;
 (b) the TCP header length is being incorrectly set.
 
 The problematic packets are coming from the host being connected
 to (la.causeuse.org) and are not coming from your host.  Who is
 at fault here, I'm not sure yet...if you could run tcpdump on
 the physical NIC that you're running pppoe0 on top of, that
 might help some (i.e are the packets bad before they arrive at
 NetBSD or does something go wrong, somewhere?)
 
 What does "ipfstat -s | grep bad" show you?
 
 Darren
 



Home | Main Index | Thread Index | Old Index