Question

I have a simple Python server which can handle multiple clients:

import select 
import socket 
import sys 

host = '' 
port = 50000 
backlog = 5 
size = 1024 
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
server.bind((host,port)) 
server.listen(backlog) 
input = [server,sys.stdin] 
running = 1 
while running: 
    inputready,outputready,exceptready = select.select(input,[],[]) 

    for s in inputready: 

        if s == server: 
            # handle the server socket 
            client, address = server.accept() 
            input.append(client) 

        elif s == sys.stdin: 
            # handle standard input 
            junk = sys.stdin.readline() 
            running = 0 

        else: 
            # handle all other sockets 
            data = s.recv(size) 
            if data: 
                s.send(data) 
            else: 
                s.close() 
                input.remove(s) 
server.close()

One client connects to it and they can communicate. I have a third box from where I am sending a RST signal to the server (using Scapy). The TCP state diagram does not say if an endpoint is supposed to try to recover a connection when it sees a RESET. Is there any way I can force the server to recover the connection? (I want it to send back a SYN so that it gets connected to the third client)

Answer 1

Your question doesn’t make much sense. TCP just doesn’t work like that.

1. Re “The TCP state diagram does not say if an endpoint is supposed to try to recover a connection when it sees a RESET”: RFC 793 #3.4 explicitly says “If the receiver was in any other state [than LISTEN or SYN-RECEIVED], it aborts the connection and advises the user and goes to the CLOSED state.”.

2. An RST won’t disturb a connection unless it arrives over that connection. I guess you could plausibly forge one, but you would have to know the current TCP sequence number, and you can’t get that from within either of the peers, let alone a third host.

3. If you succeeded somehow, the connection would then be dead, finished, kaput. Can’t see the point of that either.

4. I can’t attach any meaning to your requirement for the server to send a SYN to the third host, in response to an RST from the third host, that has been made to appear as though it came from the second host. TCP just doesn’t work anything like this either.

5. If you want the server to connect to the third host it will just have to call connect() like everybody else. In which case it becomes a client, of course.