linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi,
	jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net
Subject: [RFC PATCH] network: return errors if we know tcp_connect failed
Date: Thu, 11 Nov 2010 16:03:41 -0500	[thread overview]
Message-ID: <20101111210341.31350.86916.stgit@paris.rdu.redhat.com> (raw)

THIS PATCH IS VERY POSSIBLY WRONG!  But if it is I want some feedback.

Basically what I found was that if I added an iptables rule like so:

iptables -A OUTPUT -p tcp --dport 80 -j DROP

And then ran a web browser like links it would just hang on 'establishing
connection.'  I expected that the application would immediately, or at least
very quickly, get notified that the connect failed.   This waiting for timeout
would be expected if something else dropped the SYN or if we were dropping the
SYN/ACK packet coming back, but I figured if we knew we threw away the SYN we knew
right away that the connection was denied and we should be able to indicate
that to the application.  Yes, I realize this is little different than if the
SYN was dropped in the first network device, but it is different because we
know what happened!  We know that connect() call failed and that there isn't
anything coming back.

What I discovered was that we actually had 2 problems in making it possible.
For userspace to quickly realize the connect failed.  The first was a problem
in the netfilter code which wasn't passing errors back up the stack correctly,
due to what I believe to be a mistake in precedence rules.

http://marc.info/?l=netfilter-devel&m=128950262021804&w=2

And the second was that tcp_connect() was just ignoring the return value from
tcp_transmit_skb().  Maybe this was intentional but I really wish we could
find out that connect failed long before the minutes long timeout.  Once I
fixed both of those issues I find that links gets denied (with EPERM)
immediately when it calls connect().  Is this wrong?  Is this bad to tell
userspace more quickly what happened?  Does passing this error code back up
the stack here break something else?  Why do some functions seem to pay
attention to tcp_transmit_skb() return codes and some functions just ignore
it?  What do others think?

NOT-AT-ALL-SIGNED-OFF-BY
---

 net/ipv4/tcp_output.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index e961522..67b8535 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2592,6 +2592,7 @@ int tcp_connect(struct sock *sk)
 {
 	struct tcp_sock *tp = tcp_sk(sk);
 	struct sk_buff *buff;
+	int ret;
 
 	tcp_connect_init(sk);
 
@@ -2614,7 +2615,7 @@ int tcp_connect(struct sock *sk)
 	sk->sk_wmem_queued += buff->truesize;
 	sk_mem_charge(sk, buff->truesize);
 	tp->packets_out += tcp_skb_pcount(buff);
-	tcp_transmit_skb(sk, buff, 1, sk->sk_allocation);
+	ret = tcp_transmit_skb(sk, buff, 1, sk->sk_allocation);
 
 	/* We change tp->snd_nxt after the tcp_transmit_skb() call
 	 * in order to make this packet get counted in tcpOutSegs.
@@ -2626,7 +2627,7 @@ int tcp_connect(struct sock *sk)
 	/* Timer for repeating the SYN until an answer. */
 	inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
 				  inet_csk(sk)->icsk_rto, TCP_RTO_MAX);
-	return 0;
+	return ret;
 }
 EXPORT_SYMBOL(tcp_connect);
 


             reply	other threads:[~2010-11-11 21:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11 21:03 Eric Paris [this message]
2010-11-11 21:14 ` [RFC PATCH] network: return errors if we know tcp_connect failed Eric Dumazet
2010-11-11 21:58 ` Hua Zhong
2010-11-12  7:36   ` Patrick McHardy
2010-11-12 23:14     ` Hua Zhong
2010-11-15 10:32       ` Patrick McHardy
2010-11-15 15:47         ` Eric Paris
2010-11-15 15:57           ` Patrick McHardy
2010-11-15 16:04             ` Patrick McHardy
2010-11-15 16:36             ` Patrick McHardy
2010-11-15 16:46               ` David Miller
2010-11-15 20:00           ` Alexey Kuznetsov
2010-11-12 16:08   ` Eric Paris
2010-11-12 16:15     ` Eric Dumazet
2010-11-12 16:35       ` David Lamparter
2010-11-12 16:53         ` Eric Paris
2010-11-12 16:54         ` Patrick McHardy
2010-11-12 17:57           ` a problem tcp_v4_err() Alexey Kuznetsov
2010-11-12 18:12             ` Eric Dumazet
2010-11-12 18:21               ` Eric Dumazet
2010-11-12 18:27                 ` Eric Dumazet
2010-11-12 18:31                   ` Alexey Kuznetsov
2010-11-12 18:29               ` Alexey Kuznetsov
2010-11-12 18:33                 ` Eric Dumazet
2010-11-12 19:22                   ` David Miller
2010-11-12 21:18                     ` Eric Dumazet
2010-11-12 21:36                       ` David Miller
2010-11-12 21:16           ` [RFC PATCH] network: return errors if we know tcp_connect failed David Lamparter
2010-11-12 21:18             ` David Miller
2010-11-12 17:46 ` Alexey Kuznetsov
2010-11-12 19:28   ` David Miller

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=20101111210341.31350.86916.stgit@paris.rdu.redhat.com \
    --to=eparis@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jmorris@namei.org \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pekkas@netcore.fi \
    --cc=yoshfuji@linux-ipv6.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).