From patchwork Wed Nov 23 14:38:44 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 127314 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 9361F1007D4 for ; Thu, 24 Nov 2011 01:38:54 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753750Ab1KWOit (ORCPT ); Wed, 23 Nov 2011 09:38:49 -0500 Received: from mail-qy0-f174.google.com ([209.85.216.174]:62929 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752605Ab1KWOir (ORCPT ); Wed, 23 Nov 2011 09:38:47 -0500 Received: by qyd20 with SMTP id 20so426486qyd.19 for ; Wed, 23 Nov 2011 06:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=cNB+czTyXxMBW2OG/IiLzRdhF048jJQLyPnjr4qTYlU=; b=c9ulrnN5JduHuMBxdCHF0+5HyaITUPLPsjhKahymLe8IxOZX4Fb6Xofnzw0J10Qf6k zUUa+d0cpMsYR0CskS7xRrwnAlspkCqWhMeI6NvnY41VRIj+l1viPuTxrkHRNjoxDmiR Z5fC8EyiLQGzmUng/KX68dTNAn5yCh9HZKEis= Received: by 10.224.199.134 with SMTP id es6mr10947948qab.2.1322059127036; Wed, 23 Nov 2011 06:38:47 -0800 (PST) Received: from [10.150.51.211] (gw0.net.jmsp.net. [212.23.165.14]) by mx.google.com with ESMTPS id cd3sm17675863qab.5.2011.11.23.06.38.45 (version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 06:38:46 -0800 (PST) Message-ID: <1322059124.17693.24.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Subject: Re: Missing TCP SYN on loopback, retransmits after 1s From: Eric Dumazet To: Jesse Young Cc: David Miller , netdev@vger.kernel.org Date: Wed, 23 Nov 2011 15:38:44 +0100 In-Reply-To: <20111122183727.01ab6f04@telperion.jlyo.org> References: <20111122181320.38a70cf8@telperion.jlyo.org> <20111122.192338.1206677511966747729.davem@davemloft.net> <20111122183727.01ab6f04@telperion.jlyo.org> X-Mailer: Evolution 3.2.1- Mime-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Le mardi 22 novembre 2011 à 18:37 -0600, Jesse Young a écrit : > On Tue, 22 Nov 2011 19:23:38 -0500 (EST) > David Miller wrote: > > > From: Jesse Young > > Date: Tue, 22 Nov 2011 18:13:20 -0600 > > > > > What's also puzzling, is that I see no packet drop reporting in > > > $ ifconfig lo > > > lo: flags=73 mtu 16436 metric 1 > > > inet 127.0.0.1 netmask 255.0.0.0 > > > inet6 ::1 prefixlen 128 scopeid 0x10 > > > loop txqueuelen 0 (Local Loopback) > > > RX packets 276411482 bytes 15822880567 (14.7 GiB) > > > RX errors 0 dropped 0 overruns 0 frame 0 > > > TX packets 276411482 bytes 15822880567 (14.7 GiB) > > > TX errors 0 dropped 0 overruns 0 carrier 0 collisions > > > > The device driver therefore isn't even seeing the packets, they are > > being dropped elsewhere. > > > > Why is this "puzzling"? > > > > There's layers upon layers and thousands of places where packets can > > be dropped between the originating network stack and the actual device > > driver. > > Maybe puzzling isn't the best word... just some more relevant > information. Also, this is the loopback interface, there is no device > driver, PHY or DLL layer in question here (just the loopback's mock > driver/PHY/DLL). > > I presume that the drop is occuring in between the NET layer, and the sys > call interface, do you agree? Where should I begin looking? > -- Here is the patch to solve this IPv6 problem, thanks a lot for the report ! [PATCH] ipv6: tcp: fix tcp_v6_conn_request() Since linux 2.6.26 (commit c6aefafb7ec6 : Add IPv6 support to TCP SYN cookies), we can drop a SYN packet reusing a TIME_WAIT socket. (As a matter of fact we fail to send the SYNACK answer) As the client resends its SYN packet after a one second timeout, we accept it, because first packet removed the TIME_WAIT socket before being dropped. This probably explains why nobody ever noticed or complained. Reported-by: Jesse Young Signed-off-by: Eric Dumazet --- net/ipv6/tcp_ipv6.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index 36131d1..2dea4bb 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -1255,6 +1255,13 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb) if (!want_cookie || tmp_opt.tstamp_ok) TCP_ECN_create_request(req, tcp_hdr(skb)); + treq->iif = sk->sk_bound_dev_if; + + /* So that link locals have meaning */ + if (!sk->sk_bound_dev_if && + ipv6_addr_type(&treq->rmt_addr) & IPV6_ADDR_LINKLOCAL) + treq->iif = inet6_iif(skb); + if (!isn) { struct inet_peer *peer = NULL; @@ -1264,12 +1271,6 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb) atomic_inc(&skb->users); treq->pktopts = skb; } - treq->iif = sk->sk_bound_dev_if; - - /* So that link locals have meaning */ - if (!sk->sk_bound_dev_if && - ipv6_addr_type(&treq->rmt_addr) & IPV6_ADDR_LINKLOCAL) - treq->iif = inet6_iif(skb); if (want_cookie) { isn = cookie_v6_init_sequence(sk, skb, &req->mss);