Date: Tue, 21 Aug 2007 18:35:05 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Jacek Zapala <jacek@ipv6.jacek.it.pl> Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working Message-ID: <20070821163505.GA28667@insomnia.benzedrine.cx> In-Reply-To: <1187713068.3973.6.camel@localhost.localdomain> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> <1187705811.30269.5.camel@localhost.localdomain> <20070821143125.GB32421@insomnia.benzedrine.cx> <1187707117.846.3.camel@localhost.localdomain> <20070821145047.GC32421@insomnia.benzedrine.cx> <1187713068.3973.6.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070821163505.GA28667>