From owner-freebsd-net@FreeBSD.ORG Mon Oct 5 14:38:39 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E579106568D; Mon, 5 Oct 2009 14:38:39 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 033DA8FC19; Mon, 5 Oct 2009 14:38:39 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n95Ecb0v030599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Oct 2009 07:38:38 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C370F1CC2E; Mon, 5 Oct 2009 07:38:37 -0700 (PDT) To: Andre Oppermann In-reply-to: Your message of "Mon, 05 Oct 2009 10:24:33 +0200." <4AC9AD41.2070200@freebsd.org> Date: Mon, 05 Oct 2009 07:38:37 -0700 From: "Kevin Oberman" Message-Id: <20091005143837.C370F1CC2E@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-10-05_08:2009-09-29, 2009-10-05, 2009-10-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0910050070 Cc: net@freebsd.org Subject: Re: Unusual TCP options can cause FreeBSD to issue a reset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 14:38:39 -0000 > Date: Mon, 05 Oct 2009 10:24:33 +0200 > From: Andre Oppermann > > Kevin Oberman wrote: > > I have a system that is unable to connect to a FreeBSD system due to > > the odd formatting of the TCP options. The options contains only the > > timestamp which, if recommendations in RFC1323 are followed, are > > preceded by two NOP bytes to put the timestamp values on 4 byte > > boundaries. > > > > This system sends the 12 byte timestamp option alone, followed by two > > zero bytes to pad it. This meets the requirements of RFC793 and 1323 is > > explicit that stacks must accept this, even though it results in > > sub-optimal performance and does not meet the recommendations in 1323 > > appendix A. > > Just this alone should not cause a reset from FreeBSD. > > > Any idea if this is hard to fix? I see in on both 7.2 and 8.0. > > Can you post a detailed tcpdump of a failing connect? And please enable > net.inet.tcp.log_debug which should give a better explanation on why > FreeBSD thinks the connection is bad. Thanks!. The debug output made the issue clear and it is not a FreeBSD problem. It is with the remote system and the timestamps used, I see the following timestamps: SYN----->159082 0 SYNACK-->57062695 159082 ACK----->159082 0 Clearly, this is bogus. Sorry for the noise and the bad analysis on Friday. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751