Bug 70827 - 2.2.19-6.2.16 TCP syn ack problem...
2.2.19-6.2.16 TCP syn ack problem...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-05 17:13 EDT by danlion
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description danlion 2002-08-05 17:13:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET 
CLR 1.0.3705)

Description of problem:
The 2.2.19-6.2.16(enterprise) kernel appears to have a problem with ack'ing 
packets.

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
1. From a machine running 2.2.19-6.2.16, ssh (for instance, or establish any 
kind of TCP connection) to another machine also running 2.2.19-6.2.16.  It 
seems to exacerbate the problem if one launches multiple ssh sessions at once. 
i.e. "ssh test@testserver.com /bin/echo yes" done 5 times at once.  (It would 
be a good idea to also use unchallenged ssh so you don't get prompted for the 
password, as well as utilizing cron or a script for automation).
2. Perform a tcpdump on both the client and server
3. At some point the client will ack with a sequence number of 1, and the ssh 
session will be hung on the client machine with broken fd's:

[root@client1 /root]# file /proc/7977/fd/*
/proc/7977/fd/0:  broken symbolic link to socket:[5946278]
/proc/7977/fd/1:  broken symbolic link to socket:[5946281]
/proc/7977/fd/2:  symbolic link to /var/tmp/webuser.log
/proc/7977/fd/21: symbolic link to /dev/null
/proc/7977/fd/3:  broken symbolic link to socket:[5946284]
/proc/7977/fd/7:  broken symbolic link to pipe:[540]
/proc/7977/fd/8:  broken symbolic link to pipe:[540]

Actual Results:  1. Client sends SYN
2. Server acknowledges SYN w/ SYN/ACK
3. Client ACKs the server with a sequence number of 1
4. Because it's not ACKing the right serial number the server continues to 
retry the SYN/ACK because it doesn't believe the client has seen the SYN/ACK 
yet

Expected Results:  1. Client sends SYN
2. Server acknowledges SYN w/ SYN/ACK
3. Client then ACKs the server with the appropriate sequence number

Additional info:

It appears that what's going on here is that the communication is only getting 
to a half-opened state.

Notice the third packet (which both client and server see so there is no 
network connectivity issue).  The client is ACKing a sequence number of 1.  It 
should be ACKing 2955418975.  Because it's not ACKing the right serial number 
the server continues to retry the SYN/ACK because it doesn't believe the 
client has seen the SYN/ACK yet.

tcpdump info
-------------

Client:

06:00:03.283362 server1.dev.kilobytes.net.19930 >
1541sjc1.cust.loudcloud.com.22: S 2955299607:2955299607(0) win 32767
<mss 1460,sackOK,timestamp 85769156 0,nop,wscale 6> (DF)

06:00:03.283718 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85524815 85769156> (DF)

06:00:03.283786 server1.dev.kilobytes.net.19930 >
client1.dev.kilobytes.net.22: . ack 1 win 65160 <nop,nop,timestamp
85769156 85524815> (DF)

06:00:06.782649 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85525165 85769156> (DF)

06:00:13.283049 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85525815 85769156> (DF)

06:00:25.783385 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85527065 85769156> (DF)

06:00:50.284339 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85529515 85769156> (DF)

06:01:38.786272 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85534365 85769156> (DF)

06:03:15.290139 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85544015 85769156> (DF)

06:05:15.794950 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85556065 85769156> (DF)

06:07:16.299749 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85568115 85769156> (DF)

06:09:16.804572 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85580165 85769156> (DF)

06:11:17.309369 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85592215 85769156> (DF)

06:13:17.814175 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85604265 85769156> (DF)

06:15:18.318984 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85616315 85769156> (DF)

06:17:18.823749 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
2955299608 win 32767 <mss 1380,sackOK,timestamp 85628365 85769156> (DF)


Server:

06:00:03.283650 server1.dev.kilobytes.net.19930 >
client1.dev.kilobytes.net.22: S 138375091:138375091(0) win 32767 <mss
1380,sackOK,timestamp 85769156 0,nop,nop,nop,nop> (DF)

06:00:03.283712 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85524815 85769156> (DF)

06:00:03.284060 server1.dev.kilobytes.net.19930 >
client1.dev.kilobytes.net.22: . ack 1 win 65160 <nop,nop,timestamp
85769156 85524815> (DF)

06:00:06.782641 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85525165 85769156> (DF)

06:00:13.282875 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85525815 85769156> (DF)

06:00:25.783376 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85527065 85769156> (DF)

06:00:50.284339 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85529515 85769156> (DF)

06:01:38.786276 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85534365 85769156> (DF)

06:03:15.290139 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85544015 85769156> (DF)

06:05:15.794932 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85556065 85769156> (DF)

06:07:16.299740 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85568115 85769156> (DF)

06:09:16.804564 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85580165 85769156> (DF)

06:11:17.309374 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85592215 85769156> (DF)

06:13:17.814162 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85604265 85769156> (DF)

06:15:18.318992 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85616315 85769156> (DF)

06:17:18.823781 client1.dev.kilobytes.net.22 >
server1.dev.kilobytes.net.19930: S 2955418974:2955418974(0) ack
138375092 win 32767 <mss 1380,sackOK,timestamp 85628365 85769156> (DF)
Comment 1 Bugzilla owner 2004-09-30 11:39:49 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.