[ On Saturday, September 2, 2000 at 14:41:26 (+0900), itojun@iijlab.net wrote: ]
> Subject: Re: fragmentation by NetBSD routers vs. reassembly on other systems....
>
> > My "router 1" is my 486/66 NetBSD-1.4V machine with a GIF tunnel, and it
> > does appear to successfully send fragmented packets, and most remote
> > systems do recieve those fragmented packets sucessfully and they
> > apparently reassemble them without problems.
> >
> > Other than that though your observations do appear to match my own.
> 
> 	don't you have any other (not-administered-by-you) device in the middle?
> 	when i read your original posting my impression was that you are
> 	having problem with SMTP, to far-away peers.... anyway, you may want to
> 	gather as much tcpdump traces as you can, and cross-check these to see
> 	anyone is behaving strange.

Oh, yes of course.  There's another almost identical NetBSD router at
the other end of the cable-modem "local loop" (i.e. at the other end of
the GIF tunnel).

Today we finally did some tcpdumps on its outgoing interface (i.e. not
the cable modem IF nor the tunnel GIF) which is what convinced me that
the fragments were getting out to the Internet in at least some
recognisable form.  This, combined with the fact that there were only a
select few remote sites not accepting my e-mail while all others seemed
to accept the fragments that were being sent is what convinced me that
the problem must be with the remote servers (or some invisible
application gateway in between that might be doing the reassembly), and
what convinced me that I must try harder to stop causing fragmentation
in the first place.  With the success of avoiding fragmentation what
remains is to discover what actually causes the remote side to fail to
either receive and/or reassemble the fragments.  If it turns out that
not all remote systems are quite as "liberal in what they accept" in
terms of fragments then perhaps the ultimate fix might be to make NetBSD
more strict in what it sends....  I seriously doubt NetBSD could be the
problem though.

I would guess that the only proof I will be able to obtain will be a
packet capture on the destination system that exactly (well except for
the obvious necessary changes like TTL adjustments) matches the packets
I show to be leaving my "router-2" (upstream at the remote-from-me cable
modem).  As far as I can see this would leave the only culprit to be the
TCP stack on that destination system.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>