Messages in this thread | | | Subject | Re: tcp/ip bug (2.2.12) or telnet client bug | Date | Mon, 27 Sep 1999 15:17:45 -0700 | From | Craig Milo Rogers <> |
| |
>>Note that the question isn't, "Should explicitly requested TCP >>self-connections be allowed?". Rather, it is, "Should unintentional >>TCP self-connects be prevented?" > >It happened after: > > fd= socket( AF_INET, SOCK_STREAM, 0); > ..... > /* NO BIND HERE */ > ..... > (void ) connect( fd, address, size); > >Question is: why that socket accepted connection from itself if that socket > was not in LISTEN state ???? If that happened then that is the bug.
See RFC 793 p. 66 (in the original pagination). ACK packets are allowed in SYN-SENT state; what this means is:
1) Your socket is created.
2) It sends a SYN packet to itself, and enters SYN-SENT.
3) It receives the SYN from itself and sends a SYN/ACK.
4) It receives the SYN/ACK and enters SYN-RECEIVED.
Nifty, huh? Why would anyone want to use it? Well, it's really just a byproduct of supoporting simultaneous creation of a single connection between peers. Here's one scenario:
1) Imagine a process that uses a single local port for both listening and for opening outgoing connections. This is legal TCP, and minimizes the number of ports used (FIN-WAIT may bit you, though).
2) Now a community of these processes communicating among themselves, tearing down connections after each exchange between a pair of processes. Normally, an initiating process talks to the other processes' LISTEN connection.
3) Now imagine that two of these processes tried to talk to each other at the same time. They'd each build a connection control block identifying the pair of sockets, but they'll receive a plain SYN instead of a SYN/ACK as the first packet from the remote site.
Craig Milo Rogers
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |