Date: Tue, 21 Aug 2007 14:11:18 +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: <20070821121118.GF27160@insomnia.benzedrine.cx> In-Reply-To: <200708211010.l7LAA6V7082258@freefall.freebsd.org> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
When filtering statefully, there is no need for a specific rule allowing ICMPv6 errors like ICMP6_PACKET_TOO_BIG. These ICMPv6 messages contain, as payload, the header of the original packet that triggered the error. pf extracts that inner header and searches for a matching state entry. If a matching state is found, the ICMPv6 error is passed without ruleset evaluation. In your case, a matching state entry (for the corresponding TCP connection) is found, but TCP sequence number checks fail: > pf: BAD ICMP 2:0 some_router -> src_addr > state: TCP src_addr[50400] src_addr[50400] dst_addr[22] > [lo=2463013638 high=2463020758 win=32844 modulator=0 wscale=1] > [lo=2412460872 high=2412526560 win=1278 modulator=0 wscale=3] > 4:4 seq=2463010534 The TCP connection is from src_addr[50400] to dst_addr[22], an outgoing connection (on some interface) for pf. I assume the ICMPv6 error is coming in on the same interface. Since some_router is sending the ICMPv6 error to src, we'd expect that the TCP packet that triggered the error on some_router was sent from src to dst. The first section in square brackets represents src's TCP window, the second one dst's. For packets src sends to dst, dst's window is relevant. For example, a TCP packet from src to dst might have th_seq 2412460873 legitimately, as that is within the window dst accepts (2412460872 to 2412526560). But th_seq of the TCP packet quoted by the ICMPv6 error is 2463010534, which is outside dst's window. Strangely, it is within src's window. I don't understand why some_router would do this. It looks like it's either quoting the wrong TCP header or sending the error to the wrong side, neither of which sounds like an easy mistake to make. Is some_router a FreeBSD 6.2 box, too? It might help if you could capture a tcpdump -s 1600 -nvvvS of one such TCP connection, including the ICMPv6 error. Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070821121118.GF27160>