[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CE10C2A.1050801@trash.net>
Date: Mon, 15 Nov 2010 11:32:10 +0100
From: Patrick McHardy <kaber@...sh.net>
To: Hua Zhong <hzhong@...il.com>
CC: 'Eric Paris' <eparis@...hat.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, davem@...emloft.net,
kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org,
yoshfuji@...ux-ipv6.org
Subject: Re: [RFC PATCH] network: return errors if we know tcp_connect failed
On 13.11.2010 00:14, Hua Zhong wrote:
>> On 11.11.2010 22:58, Hua Zhong wrote:
>>>> 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.
>>>
>>> I would argue that -j DROP should behave exactly as the packet is
>> dropped in the network, while -j REJECT should signal the failure to
>> the application as soon as possible (which it doesn't seem to do).
>>
>> It sends an ICMP error or TCP reset. Interpretation is up to TCP.
>
> Huh? It's the OUTPUT chain we are talking about. There is no ICMP error or
> TCP reset.
Of course there is.
ICMP (default):
iptables -A OUTPUT -p tcp -j REJECT
TCP reset:
iptables -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
The second one will cause a hard error for the connection.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists