From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 06:58:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BCC85B3A for ; Fri, 19 Jul 2013 06:58:33 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by mx1.freebsd.org (Postfix) with ESMTP id 88FF338A for ; Fri, 19 Jul 2013 06:58:33 +0000 (UTC) Received: from [2001:5c0:1400:a::7a5] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V04e5-0004Tw-38; Fri, 19 Jul 2013 08:58:29 +0200 Message-ID: <51E8E393.50504@gont.com.ar> Date: Fri, 19 Jul 2013 08:58:27 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Matt Miller Subject: Re: TCP Loopback Connections with the Same Src/Dest Port References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 06:58:33 -0000 Hi, Matt, Please heck this IETF Internet-Draft: Some comments: On 07/17/2013 01:08 PM, Matt Miller wrote: > > Some questions we had: > > - Has anyone else ever seen these same src/dest address/port TCP > connections created? Does anyone know of a legitimate reason why they > should be allowed? Could be used for TCP-based IPC. > - If there are no known use cases for this type of connection, does > anyone have more context/insight on the design here: should this type > of inpcb creation be prevented in the kernel or is it the > application's responsibility to ensure it never creates this type of > socket? It should be allowed -- although some systems have been known to fail to handle this scenarios gracefully. > For those interested, more details of the issue seen follow. The > connection seems to get stuck in swi_net sending and receiving pure > FIN/ACKs to itself: > > #12 0xffffffff804372ce in ip_output (m=0xffffff0003ccf300, > opt=, ro=0xffffff8020c2b6a0, flags=0, imo=0x0, > inp=0xffffff0019933968) at ../../../../sys/netinet/ip_output.c > #13 0xffffffff804423dc in tcp_output (tp=0xffffff0019de2370) at > ../../../../sys/netinet/tcp_output.c > #14 0xffffffff8043ef5d in tcp_do_segment (m=0xffffff0019af1200, > th=0x100200, so=0xffffff011ac59570, tp=0xffffff0019de2370, > drop_hdrlen=52, tlen=0, iptos=0 '\000', ti_locked=3) at > ../../../../sys/netinet/tcp_input.c > #15 0xffffffff80440311 in tcp_input (m=0xffffff0019af1200, > off0=) at ../../../../sys/netinet/tcp_input.c > #16 0xffffffff8043530b in ip_input (m=0xffffff0019af1200) at > ../../../../sys/netinet/ip_input.c > #17 0xffffffff8040889f in netisr_process_workstream_proto > (proto=, nwsp=) at > ../../../../sys/net/netisr.c > #18 swi_net (arg=0xffffffff80f59800) at ../../../../sys/net/netisr.c > > swi_net() just continues in this loop, ad nauseam: [...] This results in a packet war, right? (one segment sent after another, with no delays in between). > I've noticed that we don't yet have this patch in our code: > > http://svnweb.freebsd.org/base?view=revision&revision=239672 > > Which seems like it could be relevant here to the general case of both > ends of the connection entering FIN_WAIT_1 at the same time and > sending FIN/ACKs repeatedly (though our connections are a bizarre case > of this where both ends of the connection are actually the same > connection). Last time I checked, FreeBSD was handlind this case properly... so this is probably the result of the patch you're referring to. Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1