Subject: tcpdump and wi(4) (was Re: ipsec, path mtu, and fragmentation)
To: Daniel Carosone <firstname.lastname@example.org>
From: Daniel Carosone <email@example.com>
Date: 02/06/2004 20:22:40
Content-Type: text/plain; charset=us-ascii
On Fri, Feb 06, 2004 at 07:36:22PM +1100, Daniel Carosone wrote:
> I've just traced really lousy wireless performance after a recent
> upgrade to this, because I protect my wireless by using ipsec. I only
> see the problem in on direction/case, which is why it took me a while
> to even realise there was an issue.
Oh, now it's just gotten much more mysterious.
Shortly after sending this mail, the fragmentation suddenly stopped,
and all my ESP packets are now 1496 bytes.
> Fiddling with net.inet.ipsec.dfbit on G seems to have no effect, not
> that I really expected it to (since that would be for other gateways
> with narrow MTU's between G and W).
I had a long-running scp of a file from L -> W, and it was running
along fast and nicely, and then suddenly throughput dropped and lo and
behold, fragmentation is back.
But it seems changing it on G *does* have an effect,=20
- changing from 0 -> 2 immediately makes the connection fast again,
if it was slow and fragmented.
- changing it from 2 -> 0 when it's fast has no effect, until some
time later, probably when TCP tries probing for a larger PMTU again.
Ok, that makes sense. What prevented me seeing this is even worse:
- during this testing I have noticed that running a tcpdump also
drops the effective throughput quite severely!=20
Of course, I was running tcpdump while playing with the .dfbit sysctl.
Looking at a gkrellm graph of wi0 traffic, I can very clearly see the
times when tcpdump was running. The attached pic shows an scp of a
large file from L to W, the flat periods of wi traffic have a tcpdump
running. This is (clearly) while the connection is fast and not
Why is tcpdump an off switch for wi(4)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
-----END PGP SIGNATURE-----