[Top] [All Lists]

[PATCH] ipv4 tcp autobind problem

To: netdev@xxxxxxxxxxx, linux-net@xxxxxxxxxxxxxxx
Subject: [PATCH] ipv4 tcp autobind problem
From: Kovacs Krisztian <hidden@xxxxxxxxxx>
Date: Mon, 29 Sep 2003 15:05:35 +0200
Sender: netdev-bounce@xxxxxxxxxxx


  While testing the tproxy (transparent proxying) patch for linux-2.4
(, Stas Grabois has
found a quite strange aspect of Linux 2.4 TCP. Imagine the following
scenario: you create a new socket (AF_INET, SOCK_STREAM), bind it to local
port 0, and try to connect() to a closed port. Of course, the peer sends
back an RST, indicating no one is listening on that port. However, if your
application does not care about the return value of connect(), and calls
send() on the not connected socket, inet_autobind() is called and a new
local port is allocated for the socket. So, besides returning an error,
there is also a side effect of the send(). The same thing happens with an
established TCP session if the peer sends an RST between two send() calls,
the second call will autobind the socket, and then return error.

  Is this behaviour intentional? Isn't rebinding a TCP socket to a new
local port a bug? I mean, possibly inet_sendmsg() should check if the
socket is SOCK_STREAM before calling inet_autobind() if sk->num is zero. The attached patch adds this check to inet_sendmsg(). We've been using it for a while, and it looks it did not break anything.

    Krisztian KOVACS

--- linux-2.4.22/net/ipv4/af_inet.c.orig        Thu Sep 18 10:02:49 2003
+++ linux-2.4.22/net/ipv4/af_inet.c     Thu Sep 18 10:03:56 2003
@@ -751,7 +751,7 @@
        struct sock *sk = sock->sk;
        /* We may need to bind the socket. */
-       if (sk->num==0 && inet_autobind(sk) != 0)
+       if (sk->num==0 && sock->type != SOCK_STREAM && inet_autobind(sk) != 0)
                return -EAGAIN;
        return sk->prot->sendmsg(sk, msg, size);
<Prev in Thread] Current Thread [Next in Thread>