Re: Socket stuck in CLOSE_WAIT state

Philip Gladstone (philip@raptor.com)
Tue, 27 Apr 1999 14:55:25 -0400


This is a cryptographically signed message in MIME format.

--------------ms5FE9630AA950C62EECE8F5B5
Content-Type: multipart/mixed;
boundary="------------D613B2182042716362142333"

This is a multi-part message in MIME format.
--------------D613B2182042716362142333
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I found a bug that would case this in 2.0.36 and sent the fix to Alan.
However, it caused some worse problems on his platform (for reasons
that I didn't understand). The fix worked fine on my platform.

Having said that, I just looked at my fix, and it was related to
SYN_RECV problems....

I attach it (for what it is worth).

Philip

Steve Dodd wrote:
>
> On Mon, Apr 26, 1999 at 11:30:22PM +0100, Alex Buell wrote:
>
> > Seems if there's data in the queue, the socket will never close.
> > This is on 2.2.6.
> >
> > Someone else reported the same thing with 2.2.5, he had a socket in
> > CLOSE_WAIT over 7 days!
>
> I reported this to Alan in December; I had connections stuck in CLOSE_WAIT for
> a couple of weeks on 2.0.36. I'm not a TCP bod, tho', so I don't know if this
> is a bug or a feature.
>
> I quite understandably didn't get a response from Alan - either because
> I didn't provide enough info or it just got lost in the huge torrent of email
> he no doubt gets each day.
>
> I started poking around in the tcp socket guts but it will no doubt be years
> before I get up to speed on it all.

-- 
Philip Gladstone                           +1 781 530 2461
Axent Technologies, Waltham, MA
--------------D613B2182042716362142333
Content-Type: text/plain; charset=us-ascii;
 name="syn_rcv_leak.pf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="syn_rcv_leak.pf"

--- linux/net/ipv4/tcp_input.c.zz Fri Jan 8 12:07:45 1999 +++ linux/net/ipv4/tcp_input.c Fri Jan 8 15:02:08 1999 @@ -421,6 +421,8 @@ static int tcp_reset(struct sock *sk, struct sk_buff *skb) { + struct sock *lsk; + sk->zapped = 1; /* * We want the right error as BSD sees it (and indeed as we do). @@ -428,6 +430,27 @@ switch (sk->state) { case TCP_TIME_WAIT: break; + case TCP_SYN_RECV: + /* This socket was created and is queued on the listening socket */ + sk->dead = 1; + lsk = sk->listening; + if (lsk) { + /* We have to unhook and free the SYN skb */ + struct sk_buff_head * list = &lsk->receive_queue; + struct sk_buff * lskb; + + lock_sock(lsk); /* Keep the queue safe */ + for (lskb = list->next; lskb != (struct sk_buff *) list; lskb = lskb->next) { + if (lskb->sk == sk) { + /* This is the SYN for this socket */ + skb_unlink(lskb); + kfree_skb(lskb, FREE_READ); + break; + } + } + release_sock(lsk); + } + break; case TCP_SYN_SENT: sk->err = ECONNREFUSED; break;

--------------D613B2182042716362142333--

--------------ms5FE9630AA950C62EECE8F5B5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature

MIIIaQYJKoZIhvcNAQcCoIIIWjCCCFYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bi0wggLsMIICVaADAgECAgMArf4wDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYg MTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5 OTguOS4xNjAeFw05OTAzMjQxODMyNTVaFw0wMDAzMjMxODMyNTVaMGYxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxIDAeBgkqhkiG9w0BCQEWEXBoaWxpcEByYXB0b3IuY29t MSEwHwYJKoZIhvcNAQkBFhJwanNnQGl4Lm5ldGNvbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAMQ3YtRscyyQn2dK9Z52v2lHCoX33ym6m1yOkIDaeBPVAL9BVkSMeroFO4hK p2Xi72zgGOkm+amhY/N06NfM4RcL61QlbSpRRyiMuUpU2rIdDtSLSpwEoDyzzju83iIclf4A OwFEPmY5+lbwwMUdZXnoatPZwAyAlkU+lTGPIBUxAgMBAAGjVDBSMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBT+PmCca4wP sNgzxsrGHliwcTi14DANBgkqhkiG9w0BAQQFAAOBgQBZemjNn+zoyQ45PhztrBoepNW2tSi4 0MdfBblRjen40gB2H9/XvPTcFRmrC2mRzzHo3vTrwYibNcqXiiAAo2yg4WVUBlQuaxSJ89Ds FoM08CbKzmfGAxJS+87cwvDU9pB857YcO355q/6rAhOgPD6BHquPjA0sr+TvvxvHDYFulDCC AzkwggKioAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05ODA5MTYxNzU1MzRaFw0wMDA5MTUxNzU1 MzRaMIG5MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtE dXJiYW52aWxsZTEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0 ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgUlNBIElzc3VlciAxOTk4LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAMSl5dTU0F8IAu4HIX0kv6trjh7rIAcCFYRrj9CTJB8bne5osrksT+mTZxcQFx6h+UNB I7kwqnaXu/Pn/YHAtTGL9qZQJlTylSjrGaQelx6w4ribwQSaMtA8CWxP5DVP8Ha/ABMDT0UI YPP8tNCQAYoSyZy6f1LqKpM1Njw85DUvAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAw HwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEALMeC HwFDPgeP7mlcqWSC+MCWrZMry5tQ10CagcK6pnadPJVA3FXB4VWCeasKKabVDOFXKD6P+bvV 3w2TWKpbLYuPM+TdWBU1dnIVKb1C9FqSC3dfnSfbmi1OG4IGjtKNVruV3tsMZQXelZ4C3VMX vr78a8MaInoUK2G9wp9eeloxggIEMIICAAIBATCBwTCBuTELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1 NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45 LjE2AgMArf4wCQYFKw4DAhoFAKCBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw05OTA0MjcxODU1MjZaMCMGCSqGSIb3DQEJBDEWBBSBeVNMKu3rsa5yZkaM b5Sm3Zuw/DA6BgkqhkiG9w0BCQ8xLTArMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDANBgkqhkiG9w0BAQEFAASBgChi5+sRhWrEoy2ITtMUbarjt7f/PJcV wKgO2BhO7zUAsZDpAP/G8n3qUcA0PSpaLMq3M5pE/dVqj9hhv6EGb1JEIv7Zxb1ccnzvPtFJ HfXhDDB7zTSELruQ/XT2SBPikm1rSilX2lowAVZEAbebxzDi/ij+y4NodwtAfyMggYb0 --------------ms5FE9630AA950C62EECE8F5B5--

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/