All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Tal Kelrich <tal@musicgenome.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4/2.6 local TCP connect oddity
Date: Mon, 22 Oct 2007 05:21:45 +0200	[thread overview]
Message-ID: <20071022032145.GA14735@1wt.eu> (raw)
In-Reply-To: <20071021225329.1a971751@shodan.orpak.com>

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


      reply	other threads:[~2007-10-22  3:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

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=20071022032145.GA14735@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tal@musicgenome.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.