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 /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)
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/