Subject: Re: kern/27164
To: Hauke Fath <hf@spg.tu-darmstadt.de>
From: Hauke Fath <hf@spg.tu-darmstadt.de>
List: netbsd-bugs
Date: 09/14/2005 12:14:34
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