Subject: kern/27093: ipf4 return-rst sometimes returns improper RST in ipv6
To: None <gnats-bugs@gnats.NetBSD.org>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: netbsd-bugs
Date: 09/30/2004 23:43:35
>Number:         27093
>Category:       kern
>Synopsis:       ipf4 return-rst sometimes returns improper RST in ipv6
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 30 21:44:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Manuel Bouyer
>Release:        NetBSD 2.0_RC1 20040926 snapshot
>Organization:

>Environment:
	
System: NetBSD antioche.lip6.fr 2.0_RC1 NetBSD 2.0_RC1 (ANTIOCHE) #0: Tue Sep 28 23:15:17 CEST 2004 bouyer@pop.lip6.fr:/local/pop1/bouyer/tmp/i386/obj/local/pop1/bouyer/netbsd-2-0-clean/src/sys/arch/i386/compile/ANTIOCHE i386
Architecture: i386
Machine: i386
>Description:
ipf in 2.0 doens't always return a proper RST packet when return-rst is
used. I have the following rules:
23:35:59.893517 2001:660:3302:282a:204:75ff:fe9f:9e11.27 > 2001:7a8:242c:1::1.50232: P 566:613(47) ack 3077 win 33120 <nop,nop,timestamp 3 3> [flowlabel 0xa8996block return-rst in on ex0 proto tcp from any to any port = 109 flags S/SA
pass in on ex0 proto tcp from 2001:660:3302:2820::/60 to any port = 109

telnet to port 109 gives a timeout instead of "connection refused".
tcpdump shows:
23:38:57.668157 2001:7a8:242c:1::1.50228 > 2001:660:3302:282a:204:75ff:fe9f:9e11.109: S 163834573:163834573(0) win 32768 <mss 1432,nop,wscale 0,nop,nop,timestamp 0 0> [flowlabel 0xf230b]
23:38:57.668219 2001:660:3302:282a:204:75ff:fe9f:9e11.109 > 2001:7a8:242c:1::1.50228: R 0:0(0) ack 163834574 win 32768

This RST packet is generated by the kernel (no filter on port 109) and produce
the expected result on the client side:
23:18:17.694998 2001:7a8:242c:1::1.50257 > 2001:660:3302:282a:204:75ff:fe9f:9e11.109: S 736531734:736531734(0) win 32768 <mss 1432,nop,wscale 0,nop,nop,timestamp 0 0> [flowlabel 0x12f8f]
23:18:17.695108 2001:660:3302:282a:204:75ff:fe9f:9e11.109 > 2001:7a8:242c:1::1.50257: R 0:0(0) ack 736531735 win 0 [flowlabel 0x5332f]

Differences are the flowlabel (missing in the RST generated by ipfilter)
and the window size (original size in the RST generated by ipfilter, 0 in
the one generated by the kernel). 
A tcpdump on the client host shows that the RST is never received on the client
host, it's blocked by some router in the path. So I suspect the missing
flowlabel to be the problem.

>How-To-Repeat:
	setup the above filter, telnet to the blocked port.
>Fix:
	unknown.
>Release-Note:
>Audit-Trail:
>Unformatted: