public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.4/2.6 local TCP connect oddity
@ 2007-10-21 15:53 Tal Kelrich
  2007-10-21 17:29 ` Willy Tarreau
  0 siblings, 1 reply; 4+ messages in thread
From: Tal Kelrich @ 2007-10-21 15:53 UTC (permalink / raw)
  To: linux-kernel

Hi,

I've run into a problem where a process trying to connect to a local
port within the local port range eventually ends up connected to itself,
with source port = dest port.

similar behavior can be gotten by running netcat as follows:
nc -p 1025 localhost 1025

I'm not really sure if that's a bug, but the original case was at least
unexpected.

Regards,
	Tal Kelrich

-- 
Tal Kelrich
PGP fingerprint: 3EDF FCC5 60BB 4729 AB2F  CAE6 FEC1 9AAC 12B9 AA69
Key Available at: http://www.hasturkun.com/pub.txt
----
Administration:  An ingenious abstraction in politics, designed to
receive the kicks and cuffs due to the premier or president.
-- Ambrose Bierce
----


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.4/2.6 local TCP connect oddity
  2007-10-21 15:53 2.4/2.6 local TCP connect oddity Tal Kelrich
@ 2007-10-21 17:29 ` Willy Tarreau
  2007-10-21 20:53   ` Tal Kelrich
  0 siblings, 1 reply; 4+ messages in thread
From: Willy Tarreau @ 2007-10-21 17:29 UTC (permalink / raw)
  To: Tal Kelrich; +Cc: linux-kernel

Hi,

On Sun, Oct 21, 2007 at 05:53:37PM +0200, Tal Kelrich wrote:
> Hi,
> 
> I've run into a problem where a process trying to connect to a local
> port within the local port range eventually ends up connected to itself,
> with source port = dest port.
> 
> similar behavior can be gotten by running netcat as follows:
> nc -p 1025 localhost 1025
> 
> I'm not really sure if that's a bug, but the original case was at least
> unexpected.

It is not a bug, it is caused by the "simultaneous connect" feature of
TCP. Although rarely used, in TCP you can connect two clients together.
They just have to exchange their SYN, SYN/ACK then ACK and bingo, they're
connected. In fact, you found the easiest way to achieve it, by using the
same port. To demonstrate the feature, I'm used to either temporarily
block SYNs with iptables, or by unplugging the cable between two machines.

I personally dislike this feature as it can be exploited to prevent any
client from connecting to the outside by flooding it with SYN packets to
its guessed source port. Anyway, most stateful firewalls don't let this
pass through.

> Regards,
> 	Tal Kelrich

Regards,
Willy


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.4/2.6 local TCP connect oddity
  2007-10-21 17:29 ` Willy Tarreau
@ 2007-10-21 20:53   ` Tal Kelrich
  2007-10-22  3:21     ` Willy Tarreau
  0 siblings, 1 reply; 4+ messages in thread
From: Tal Kelrich @ 2007-10-21 20:53 UTC (permalink / raw)
  To: Willy Tarreau; +Cc: linux-kernel

On Sun, 21 Oct 2007 19:29:02 +0200
Willy Tarreau <w@1wt.eu> wrote:

> Hi,
> 
> On Sun, Oct 21, 2007 at 05:53:37PM +0200, Tal Kelrich wrote:
> > Hi,
> > 
> > I've run into a problem where a process trying to connect to a local
> > port within the local port range eventually ends up connected to
> > itself, with source port = dest port.
> > 
> > similar behavior can be gotten by running netcat as follows:
> > nc -p 1025 localhost 1025
> > 
> > I'm not really sure if that's a bug, but the original case was at
> > least unexpected.
> 
> It is not a bug, it is caused by the "simultaneous connect" feature of
> TCP. Although rarely used, in TCP you can connect two clients
> together. They just have to exchange their SYN, SYN/ACK then ACK and
> bingo, they're connected. In fact, you found the easiest way to
> achieve it, by using the same port. To demonstrate the feature, I'm
> used to either temporarily block SYNs with iptables, or by unplugging
> the cable between two machines.
> 

Hi,

It still seems confusing that a connect against localhost may
randomly succeed.

Here's a better example, if somewhat violent. eventually succeeds.
(p=$((`cat /proc/sys/net/ipv4/ip_local_port_range|cut -f1`+1)); while
true ; do nc -v -v 127.0.0.1 $p ; done)

Regards,
	Tal

-- 
Tal Kelrich
PGP fingerprint: 3EDF FCC5 60BB 4729 AB2F  CAE6 FEC1 9AAC 12B9 AA69
Key Available at: http://www.hasturkun.com/pub.txt
----
We are each entitled to our own opinion, but no one is entitled to his
own facts.
		-- Patrick Moynihan
----

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.4/2.6 local TCP connect oddity
  2007-10-21 20:53   ` Tal Kelrich
@ 2007-10-22  3:21     ` Willy Tarreau
  0 siblings, 0 replies; 4+ messages in thread
From: Willy Tarreau @ 2007-10-22  3:21 UTC (permalink / raw)
  To: Tal Kelrich; +Cc: linux-kernel

On Sun, Oct 21, 2007 at 10:53:29PM +0200, Tal Kelrich wrote:
> On Sun, 21 Oct 2007 19:29:02 +0200
> Willy Tarreau <w@1wt.eu> wrote:
> 
> > Hi,
> > 
> > On Sun, Oct 21, 2007 at 05:53:37PM +0200, Tal Kelrich wrote:
> > > Hi,
> > > 
> > > I've run into a problem where a process trying to connect to a local
> > > port within the local port range eventually ends up connected to
> > > itself, with source port = dest port.
> > > 
> > > similar behavior can be gotten by running netcat as follows:
> > > nc -p 1025 localhost 1025
> > > 
> > > I'm not really sure if that's a bug, but the original case was at
> > > least unexpected.
> > 
> > It is not a bug, it is caused by the "simultaneous connect" feature of
> > TCP. Although rarely used, in TCP you can connect two clients
> > together. They just have to exchange their SYN, SYN/ACK then ACK and
> > bingo, they're connected. In fact, you found the easiest way to
> > achieve it, by using the same port. To demonstrate the feature, I'm
> > used to either temporarily block SYNs with iptables, or by unplugging
> > the cable between two machines.
> > 
> 
> Hi,
> 
> It still seems confusing that a connect against localhost may
> randomly succeed.
> 
> Here's a better example, if somewhat violent. eventually succeeds.
> (p=$((`cat /proc/sys/net/ipv4/ip_local_port_range|cut -f1`+1)); while
> true ; do nc -v -v 127.0.0.1 $p ; done)

Of course, for the same reason. If you reduce the ip_local_port_range, it
will even succeed more often. This is because the source port is choosen
before the first packet is sent, so when it is sent, it reaches a pending
connection (itself).

I can understand that it is confusing when you see it as a single
connection, but try to imagine (or reproduce) with 2 machines, then
translate that to the localhost with a single and same connection.
You may even draw the exchanges on paper, an you will notice that
"each end" of the connection gets its SYN-SYN/ACK-ACK sequence.

You may also tcpdump on loopback if that helps.

Regards,
Willy


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-10-22  3:21 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-21 15:53 2.4/2.6 local TCP connect oddity Tal Kelrich
2007-10-21 17:29 ` Willy Tarreau
2007-10-21 20:53   ` Tal Kelrich
2007-10-22  3:21     ` Willy Tarreau

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox