From owner-freebsd-net@FreeBSD.ORG Fri Oct 2 23:18:27 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 8EFC71065693 for ; Fri, 2 Oct 2009 23:18:27 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 788FC8FC12 for ; Fri, 2 Oct 2009 23:18:27 +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 n92NIQbW013007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Oct 2009 16:18:26 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 066291CC0E for ; Fri, 2 Oct 2009 16:18:26 -0700 (PDT) To: net@freebsd.org Date: Fri, 02 Oct 2009 16:18:26 -0700 From: "Kevin Oberman" Message-Id: <20091002231826.066291CC0E@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-02_08:2009-09-29, 2009-10-02, 2009-10-02 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-0910020155 Cc: Subject: 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: Fri, 02 Oct 2009 23:18:27 -0000 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. Any idea if this is hard to fix? I see in on both 7.2 and 8.0. -- 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