NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: weird IPv6 packet dropping with 6to4
Date: Sat, 5 Sep 2009 19:47:49 +0100
From: Matthias Scheler <tron%zhadum.org.uk@localhost>
Why should it? Your HTTP request is small, the gateway routing to your
tunnel would to do that. The main point is that you should not use
MSS clamping.
If NetBSD receives packets inbound packets from the outside world that
are too large for the MTU of stf0, I presume that it would reply with
ICMP6 packet-too-big. But in any case, I've turned off MSS clamping
on the stf0 interface, since it doesn't improve the situation on or
off.
Well, that could be your main problem. With an MTU of 1280 on stf0 the
incoming packets should not exceed 1300 bytes which does fit into the
MTU of 1492 bytes of pppoe0.
It looks to me as if there's a broken 6to4 relay router somewhere
out there.
How could I detect that? Is it, I presume, supposed to hand back an
ICMP6 packet-too-big reply to the remote host rather than sending IPv4
fragments to my host? Can you suggest another 6to4 relay router to
use? I'm using the usual anycast address, 192.88.99.1.
Does access to http://zhadum.org.uk/ over IPv6 work better for you?
My A-DSL router has an outgoing 6to4 tunnel with an MTU of 1280
which should avoid fragementation problems.
No. I can fetch the main page OK, but if I attempt to download, say,
<http://zhadum.org.uk/wp-content/uploads/2009/08/bsd-tent-large.jpg>,
it stalls partway through just like with <http://www.ietf.org/>.
Still I see TCP retransmissions on fxp0 (external) and stf0, but not
on ex0 (internal). I don't see anything interesting about the packets
that don't get acked, though: the last few segments sent each contain
1208 bytes, so I might guess that that exceeds some limit, but there
are a number of 1208-byte segments that got through and got acked.
Home |
Main Index |
Thread Index |
Old Index