From perhov@math.ntnu.no Sat Mar 27 20:26:31 1999
Return-Path: <perhov@math.ntnu.no>
Received: from romberg.math.ntnu.no (romberg.math.ntnu.no [129.241.15.150])
	by hub.freebsd.org (Postfix) with SMTP id EB3BB14D66
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 27 Mar 1999 20:26:29 -0800 (PST)
	(envelope-from perhov@math.ntnu.no)
Received: (qmail 1109 invoked from network); 28 Mar 1999 04:26:10 -0000
Received: from fimfpc19.math.ntnu.no (129.241.15.132)
  by romberg.math.ntnu.no with SMTP; 28 Mar 1999 04:26:10 -0000
Received: (from perhov@localhost)
          by fimfpc19.math.ntnu.no (8.9.2/8.8.4)
	  id GAA95143; Sun, 28 Mar 1999 06:26:09 +0200 (CEST)
Message-Id: <199903280426.GAA95143@fimfpc19.math.ntnu.no>
Date: Sun, 28 Mar 1999 06:26:09 +0200 (CEST)
From: perhov@phys.ntnu.no
Sender: perhov@math.ntnu.no
Reply-To: perhov@phys.ntnu.no
To: FreeBSD-gnats-submit@freebsd.org
Cc: perhov@phys.ntnu.no
Subject: TCP connection looped back to itself
X-Send-Pr-Version: 3.2

>Number:         10826
>Category:       kern
>Synopsis:       TCP connection looped back to itself
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 27 20:30:00 PST 1999
>Closed-Date:    Sun Mar 28 13:06:04 PST 1999
>Last-Modified:  Sun Mar 28 13:11:20 PST 1999
>Originator:     Per Kristian Hove
>Release:        FreeBSD 3.1-STABLE i386
>Organization:
Norwegian University of Science and Technology
>Environment:

FreeBSD 3.1-STABLE as of Mon Mar 15 13:47:02 CET 1999

>Description:

On rare occations, a "telnet localhost N" (where N is an unused
port number >1024) will succeed and result in a connection looped
back to itself.

>How-To-Repeat:

Try hard enough, and you will get a connection. The connection
seems to be looped back into itself (hey, isn't that WYSIWYG?
"What You Send Is What You Get"?). The following example assumes
your shell is bash:

$ declare -i n=0
$ until telnet localhost 1234; do n=n+1; done;  echo n=$n
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
  [...]
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Connected to localhost.
Escape character is '^]'.
hi, am I talking to myself?             # I type this,
hi, am I talking to myself?             # this is the response I get


^]					# quit telnet
telnet> quit
Connection closed.
n=398
(Sometimes I have to wait until n=5000 before it occurs)

A output of 'netstat' shows that the connection is indeed looped:

# netstat
Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      0  localhost.1234         localhost.1234         ESTABLISHED
Active UNIX domain sockets
Address  Type   Recv-Q Send-Q    Inode     Conn     Refs  Nextref Addr
  [...]

This behaviour also occurs when I try to telnet to an IP address
assigned to another of the host's network interfaces (it doesn't have
to be the loopback interface).

I've never succeeded getting a connection to an unused port below 1024.

>Fix:
	
	


>Release-Note:
>Audit-Trail:

From: Chris Costello <chris@holly.dyndns.org>
To: perhov@phys.ntnu.no
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/10826: TCP connection looped back to itself
Date: Sat, 27 Mar 1999 22:45:51 -0600

 On Sat, Mar 27, 1999, perhov@phys.ntnu.no wrote:
 > (Sometimes I have to wait until n=5000 before it occurs)
 > 
 > A output of 'netstat' shows that the connection is indeed looped:
 > 
 > # netstat
 > Active Internet connections
 > Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
 > tcp        0      0  localhost.1234         localhost.1234         ESTABLISHED
 
    How is this a bug?  It behaves how it should, doesn't it?
 
 > 
 > 
 > To Unsubscribe: send mail to majordomo@FreeBSD.org
 > with "unsubscribe freebsd-bugs" in the body of the message
 > 
 

From: Per Kristian Hove <perhov@phys.ntnu.no>
To: chris@calldei.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/10826: TCP connection looped back to itself
Date: Sun, 28 Mar 1999 07:14:36 +0200 (MET DST)

 On Sat, 27 Mar 1999, Chris Costello wrote:
 
  >    How is this a bug?  It behaves how it should, doesn't it?
 
 If it does, I'm sorry I've taken up your time on something that isn't a
 bug. I'm not at all a networking guru, it just seemed strange to me to get
 a connection when nothing should be listening to that port.
 
 But when setting net.inet.tcp.log_in_vin = 1 and try to connect to port
 3434, I see in my logs
  Connection attempt to TCP 127.0.0.1:3434 from 127.0.0.1:3460
 and when I then try to connect to port 3461 (the "outgoing" port number
 increases by 1 for every connection attempt), that succeeds. So what
 seemed random, it's not random at all.
 
 I thought you had to explicitly listen() [and then accept()] in order to
 accept connections. But connect()ing on a socket makes it accept incoming
 connections? (And yes, I'm no programmer either).
 
 This is how I thought it worked:
 When I connect to the port, a port is allocated locally in the local end
 of the connection. Then a SYN is sent to the remote end, and if I get a
 (SYN | ACK) in return, I will get connected to the destination end. If I
 should get just a (SYN | ~ACK), I shouldn't get connected to the remote
 end. I only send a SYN (to myself, by accident, cause the port
 number is the same in both ends of the connection), and since I'm sending
 it to myself, I also think that I'm receiving it. But since it's just a
 SYN, and not a (SYN | ACK), I shouldn't accept that it's a valid response
 to my original SYN. It seems like FreeBSD reads the SYN as 'okay, let him
 have a connection'.
 
 
 -- 
 per kristian                                       <perhov@phys.ntnu.no>
 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Sun Mar 28 11:38:26 PST 1999 
State-Changed-Why:  
Please take this up on a mailing list that takes networking questions. 
When you think you have a bug on your hands, a good trick is to first 
say what the bug breaks for you _before_ showing how to demonstrate it 
with telnet or whatever. 
State-Changed-From-To: closed->open 
State-Changed-By: billf 
State-Changed-When: Sun Mar 28 13:03:09 PST 1999 
State-Changed-Why:  
This is not a closed issue. 
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Sun Mar 28 13:06:04 PST 1999 
State-Changed-Why:  
This is a closed issue. 

TCP has the property that it will allow "symmetric opens". 

Read various classics on the topic. 
>Unformatted:
