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

From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: Hauke Fath <hf@spg.tu-darmstadt.de>
Cc: Darren Reed <darrenr@netbsd.org>, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/27164
Date: Wed, 14 Sep 2005 12:14:34 +0200

 Hauke Fath wrote:
 > [Mail from 2005-04-13 re-sent;
 > Darren, did you ever get around to download the tarball? I get regular 
 > GNATS feedback reminders, please reset the PR.
 > Thanks, hauke]
 > 
 > 
 >> Am 30.10.2004 um 23:50 Uhr +0200 schrieb Hauke Fath:
 >>
 >>> Am 30.10.2004 um 9:15 Uhr +0000 schrieb Darren Reed:
 >>>
 >>>> I'm not sure that "keep frags" works with Linux because (for some 
 >>>> versions
 >>>> of it, at least) they send the fragments in the reverse order to 
 >>>> that with
 >>>> which ipfilter works.
 >>>>
 >>>> Can you investigate with tcpdump and find out whether or not the
 >>>> Linux boxes are sending the last fragment first?
 >>>
 >>>
 >>> Give me a fortnight. I'm on the eurobsdcon ATM, and then on holiday 
 >>> during the next week.
 >>>
 >>> I've got an ethereal dump file around that shows the problem, and I 
 >>> can tcpdump a RH9 machine's traffic, if needed.
 >>>
 >>> But I actually came across the question - some discussion on the ipf 
 >>> mailing list a while back. And I'm pretty sure I tried nfs v2 / udp / 
 >>> 1k packets to check this, with and without "keep frags", and it 
 >>> didn't make a difference.
 >>>
 >>> The stateless rules that are currently in place, OTOH, have "keep 
 >>> frags".
 >>>
 >>> So, while the reverse order issue may be part of the picture, it's 
 >>> not everything.
 >>>
 >>> I'll get back to you with the tcpdump.
 >>
 >>
 >> Hi Darren,
 >>
 >> I sent the URL some months ago, but never heard back from you - the 
 >> issue may have been lost during your move to China.
 >>
 >> I have put a 1.3 MByte ethereal trace on 
 >> http://www.spg.tu-darmstadt.de/~hf/XXXXXXXXXXXXXXXXXXXXXXX .
 >>
 >> It contains the traffic between a RH 9 machine and a pre-2.0 NetBSD 
 >> NFS server via a filtering router (specs and RCS ids in the PR).
 >>
 >> Since there may be security sensitive data, I'd rather not submit the 
 >> URL to the Gnats db. Nevertheless, can you please update the PR state?
 >>
 >> Regards,
 >>     hauke
 
 The router in question runs netbsd-3 now (the PR is against ipfilter 
 1.3.29 as found in netbsd-1-6). The RedHat machines that triggered the 
 bug are gone from our network, so I have no means any more of 
 testing/reproducing the problem.
 
 Since Darren seems too busy to pick up the tcpdump tarball, or even 
 update the status of the pr, I ask for this PR to be closed.
 
 	hauke
 
 
 [http://www.netbsd.org/Misc/query-pr.html tells me ther is no PR 
 #27164?! Something's badly broken there...]
 
 -- 
 /~\  The ASCII Ribbon Campaign                    Hauke Fath
 \ /    No HTML/RTF in email	        Institut für Nachrichtentechnik
   X     No Word docs in email	                  TU Darmstadt
 / \  Respect for open standards              Ruf +49-6151-16-3281