From nobody@FreeBSD.org  Fri Jun  8 10:43:13 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 30DB5106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  8 Jun 2012 10:43:13 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 032B28FC12
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  8 Jun 2012 10:43:13 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q58AhCfw092954
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 8 Jun 2012 10:43:12 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q58AhCJi092953;
	Fri, 8 Jun 2012 10:43:12 GMT
	(envelope-from nobody)
Message-Id: <201206081043.q58AhCJi092953@red.freebsd.org>
Date: Fri, 8 Jun 2012 10:43:12 GMT
From: Nikolay Denev <ndenev@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: FreeBSD 
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         168842
>Category:       kern
>Synopsis:       [tcp] FreeBSD hosts are sending TCP packets with FIN flag and no ACK set
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    andre
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jun 08 10:50:13 UTC 2012
>Closed-Date:    
>Last-Modified:  Mon Jun 18 03:51:28 UTC 2012
>Originator:     Nikolay Denev
>Release:        8.3-STABLE
>Organization:
>Environment:
reeBSD j3.example.com 8.3-STABLE FreeBSD 8.3-STABLE #1: Wed May  9 12:32:48 CEST 2012     root@j3.example.com:/usr/obj/usr/src/sys/KERN-CARP-PF  amd64
>Description:
It seems that our FreeBSD hosts are sending TCP packets with FIN flag and no ACK set, which is triggering
alerts on some firewalls.

[14:31]root@vpn1.location:/home/ndenev# tcpdump -s0 -vni em1 '(tcp[tcpflags] & tcp-ack == 0) && (tcp[tcpflags] & tcp-fin != 0)'
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:18:31.771578 IP (tos 0x0, ttl 62, id 44503, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.53083 > Y.Y.Y.Y.9998: Flags [F], cksum 0x29a6 (correct), seq 2205738519, win 65535, length 0
15:22:02.517922 IP (tos 0x0, ttl 62, id 56317, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.37719 > Y.Y.Y.Y.9998: Flags [F], cksum 0x192b (correct), seq 2125215587, win 65535, length 0
15:24:13.215171 IP (tos 0x0, ttl 62, id 36930, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.25125 > Y.Y.Y.Y.9998: Flags [F], cksum 0x6998 (correct), seq 1370309927, win 65535, length 0
15:25:17.010082 IP (tos 0x0, ttl 62, id 61513, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.48897 > Y.Y.Y.Y.9998: Flags [F], cksum 0x16c2 (correct), seq 2650795726, win 65535, length 0
15:29:19.979799 IP (tos 0x0, ttl 62, id 15471, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.31685 > Y.Y.Y.Y.9998: Flags [F], cksum 0x218d (correct), seq 2057063075, win 65535, length 0
15:35:50.005156 IP (tos 0x0, ttl 62, id 27760, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.50568 > Y.Y.Y.Y.9998: Flags [F], cksum 0x6df3 (correct), seq 2102571459, win 65535, length 0
15:38:28.252143 IP (tos 0x0, ttl 62, id 22995, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.30441 > Y.Y.Y.Y.9998: Flags [F], cksum 0xced9 (correct), seq 4232454280, win 65535, length 0
15:39:35.362371 IP (tos 0x0, ttl 62, id 46525, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.15067 > Y.Y.Y.Y.9998: Flags [F], cksum 0x9d94 (correct), seq 1322466127, win 65535, length 0
15:52:27.833978 IP (tos 0x0, ttl 62, id 30955, offset 0, flags [DF], proto TCP (6), length 40)
    10.16.1.5.21254 > Y.Y.Y.Y.9998: Flags [F], cksum 0x36a1 (correct), seq 3524593365, win 65535, length 0

Where 10.16.1.5 runs 8.3-STABLE

I have a PCAP that I can send privately if needed.

>How-To-Repeat:
Haven't tracked it down yet.
>Fix:
none

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->andre 
Responsible-Changed-By: andre 
Responsible-Changed-When: Wed Jun 13 13:14:40 UTC 2012 
Responsible-Changed-Why:  
Take over. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=168842 

From: Andre Oppermann <andre@freebsd.org>
To: Nikolay Denev <ndenev@gmail.com>
Subject: Re: FreeBSD 8.2-STABLE sending FIN no ACK packets. kern/168842

 Hi Nikolay
 
 please make the pcap available to me.  From the tcpdump in the PR I can't
 analyze how this stray packet may come about.
 
 While certainly a bug it is not a security issue as any compliant tcp stack
 would drop such a packet on receipt.
 
 -- 
 Andre

From: Andre Oppermann <andre@freebsd.org>
To: Nikolay Denev <ndenev@gmail.com>
Cc: freebsd-net <freebsd-net@freebsd.org>, 
 freebsd-gnats-submit@freebsd.org
Subject: Re: kern/168842: FreeBSD 8.2-STABLE sending FIN no ACK packets.
Date: Thu, 14 Jun 2012 12:35:44 +0200

 > Hi Nikolay
 >
 > please make the pcap available to me. From the tcpdump in the PR I can't
 > analyze how this stray packet may come about.
 
 OK, thanks for the pcap file which I've analyzed now.
 
 > While certainly a bug it is not a security issue as any compliant tcp stack
 > would drop such a packet on receipt.
 
 The stray FIN happens on timeout of unsuccessful connection attempts (SYN_SENT).
 
 There are a number of bugs for that case I've identified so far:
 
 1. there is bug in the SYN_SENT inpcb teardown case that causes the wrong
     FIN to be sent.  It may be a residual of T/TCP.
 2. the SYN retransmit is broken by sending the first after 3s, and then four
     in succession at 3.2s, the fifth comes at 6.2s, at 8s the application
     times out.
 3. after the third SYN retransmit we turn off the tcp options, except that
     SACK_PERM stays on.
 
 I'm working on fixes for each of these bugs.
 
 -- 
 Andre
>Unformatted:
