kern/115413: [ipv6] ipv6 pmtu not working

[Daniel Hartmeier]

On Tue, Aug 21, 2007 at 06:17:48PM +0200, Jacek Zapala wrote:

> I have applied the patch and it looks like it has helped.

Great, thank you!

> But I'm not sure if I understood well - you suspect that only 8 bytes of
> tcp header are copied from the original tcp packet to the icmp message
> by the router?

No, the router is only required (by the RFCs) to quote the first 8 bytes
of the TCP header. It may provide more. But pf can't rely on there being
more (another router might legally only provide the minimum, and
checking how many bytes there are would mean additional cost), so it only
looks at the first 8 bytes. Before it can look at any header fields, it
has to 'pull up' the bytes it wants to look at, making them adjacent in
memory. It only does that for the first 8 bytes.

The bug is/was that it then accessed th_flags, even though that field is
beyond the first 8 bytes, and the result was that a random byte was used
instead of the th_flags from the TCP header in the ICMP error. Hence,
what pf perceived as th_flags randomly had TH_SYN set, which made pf not
apply the window scaling factor in the sequence number check. The larger
the window scaling factors, the higher the chance that failing to apply
the factor will make the difference between allowing the packet and
dropping it.

I don't know why in your case 'random' means 'mostly/always TH_SYN set',
but that might be due to your architecture, or mbuf memory layout. Who
knows, that byte might contain a MAC address, and you happen to have a
NIC with a specific MAC address byte ;)

There's nothing wrong with the router, the bug is in pf. Let me know if
anything changes, or when you're sure that the problem is resolved.

Thanks for your help!

Daniel