All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: netdev <netdev@vger.kernel.org>
Subject: Send-to-self TCP connection hangs in 2.6.38-rc3.
Date: Mon, 07 Feb 2011 16:34:44 -0800	[thread overview]
Message-ID: <4D508FA4.6090500@candelatech.com> (raw)

I'm seeing something weird on the latest wireless-testing kernel
(I have some wifi hacks in here, but no modifications to the basic
networking system, no proprietary modules loaded.)
Wireless-testing is currently based on 2.6.38-rc3.
This has been happening for a while, but I'm not sure
exactly when it started.

I am sending-to-self across some virtual wifi stations.  UDP runs fine,
but TCP connections tend to hang after a while..often in only one
direction.

The ip rules seem right, I'm detecting no spurious link admin up/down.  I suspect
conn-tracking.  Notice that the dport and sport do not match the netstat output
in the entry marked 'UNREPLIED'.  What sort of thing could cause that?

Here's some conntrack output for a broken connection:

ipv4     2 tcp      6 299 ESTABLISHED src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0 
zone=0 use=2
ipv4     2 tcp      6 431687 ESTABLISHED src=33.1.2.32 dst=33.1.2.35 sport=33194 dport=33193 [UNREPLIED] src=33.1.2.35 dst=33.1.2.32 sport=33193 dport=33194 
mark=0 zone=0 use=2
ipv4     2 udp      17 179 src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0 zone=0 use=2

The 33.1.2.32 side seems unable to send to the peer, though the peer can send to .32

[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.32
tcp        0      0 33.1.2.32:33382             0.0.0.0:*                   LISTEN
tcp        0   5852 33.1.2.32:33382             33.1.2.35:33381             ESTABLISHED
tcp        0      0 33.1.2.35:33381             33.1.2.32:33382             ESTABLISHED
udp        0      0 33.1.2.32:33382             0.0.0.0:*
udp        0      0 33.1.2.32:123               0.0.0.0:*

Here's the same connection after re-starting it.  It appears to be passing traffic
properly.

[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.32
tcp        0      0 33.1.2.32:33480             0.0.0.0:*                   LISTEN
tcp        0      0 33.1.2.35:33479             33.1.2.32:33480             ESTABLISHED
tcp        0      0 33.1.2.32:33480             33.1.2.35:33479             ESTABLISHED
udp        0      0 33.1.2.32:123               0.0.0.0:*
udp        0      0 33.1.2.32:33484             0.0.0.0:*
[root@lec2010-ath9k-1 lanforge]# cat /proc/net/nf_conntrack|grep 1.2.32
ipv4     2 udp      17 179 src=33.1.2.35 dst=33.1.2.32 sport=33483 dport=33484 src=33.1.2.32 dst=33.1.2.35 sport=33484 dport=33483 [ASSURED] mark=0 zone=0 use=2
ipv4     2 tcp      6 430352 ESTABLISHED src=33.1.2.32 dst=33.1.2.35 sport=33194 dport=33193 [UNREPLIED] src=33.1.2.35 dst=33.1.2.32 sport=33193 dport=33194 
mark=0 zone=0 use=2
ipv4     2 udp      17 161 src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0 zone=0 use=2
ipv4     2 tcp      6 431999 ESTABLISHED src=33.1.2.35 dst=33.1.2.32 sport=33479 dport=33480 src=33.1.2.32 dst=33.1.2.35 sport=33480 dport=33479 [ASSURED] 
mark=0 zone=0 use=2



Here's a connection that had been running for several minutes and seems
to have been passing traffic fine.  I'm not sure about what the
CLOSE_WAIT thing is...

[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.20
tcp        0      0 33.1.2.18:33362             33.1.2.20:33361             ESTABLISHED
tcp        1      0 33.1.2.18:33202             33.1.2.20:33201             CLOSE_WAIT
tcp        0      0 33.1.2.20:33361             33.1.2.18:33362             ESTABLISHED
udp        0      0 33.1.2.20:33361             0.0.0.0:*
udp        0      0 33.1.2.20:123               0.0.0.0:*
[root@lec2010-ath9k-1 lanforge]# cat /proc/net/nf_conntrack|grep 1.2.20
ipv4     2 tcp      6 431999 ESTABLISHED src=33.1.2.20 dst=33.1.2.18 sport=33361 dport=33362 src=33.1.2.18 dst=33.1.2.20 sport=33362 dport=33361 [ASSURED] 
mark=0 zone=0 use=2
ipv4     2 udp      17 178 src=33.1.2.20 dst=33.1.2.18 sport=33361 dport=33362 src=33.1.2.18 dst=33.1.2.20 sport=33362 dport=33361 [ASSURED] mark=0 zone=0 use=2


I'll be happy to provide more details..just ask.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


                 reply	other threads:[~2011-02-08  0:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D508FA4.6090500@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.