Hello, I've a tcp server socket application listening on 1999 port, and several devices connects to it, through their respective internet connections (routers). The problem is that serveral of this devices have an unexpected connection behaviour, that i'm going explain. Server IP -> listening on port 1999 Device IP -> send request from port 1025 Server <- Device : Send SYN to stablish the connection Server -> Device : Send SYN, ACK Server <- Device : Send ACK. Connection stablished Server <- Device : Send PUSH, ACK Send data to de server (1 packet) Server -> Device : ACK, Everything seems to be OK till here Server -> Device : PUSH some data from port 1999 to port 1025 Server -> Device : PUSH the same data than the packet before form port 1999 to port 1184 Server <- Device : ACK for the PUSH form 1999 to 1184 The push to the 1184 (llsurfup-https) is unexpected and is not controlled by my application, the correct ACK is lost and the connection is reset after 5 attempts. I have not found any suitable information in internet about (llsurfup-https) nor what could be the cause of the problem This is the trace, and the problem starts in the line 32. https://docs.google.com/file/d/0BwiWOLmOB31bbk5Cc0NIeTlMUk0/edit?usp=sharing I'd appreciate any help. Thank you in advance!! asked 21 Aug '13, 03:36  Ferran |
One Answer:
Easy one first: the "llsurfup-https" can be ignored as it is just the client's ephemeral port number that is resolved to this name. So, don't worry about finding information about it. Ok, now to the traffic that is going out of your server: Your server is sending the same 13 bytes of data on all active sockets at the same time. The ip.id delta in each batch of outbound data suggests that there are 3 additional packets (connections) sent which are not in the trace. The interval between the send()s is 10 seconds (+ ~140ms). So I doubt that "The push to the 1184 (llsurfup-https) is unexpected and is not controlled by my application" is really not controlled by your application. It is sent over (at least) 2 TCP connections simultaneously so the server must have sent it. How do the clients behave? We are talking about at least two different clients. One tcp.port==1184 responding to your data with data, the other one just acknowledging your data, not sending anything back Here the good case Port 1025 is not returning your data but just acking with increasing delays 80ms-166 ms. In packet 31 the 'client' or NAT resets the connection So from a distance it looks like the client's application doesn't know how to react on your data. The 'client' or NAT is re-using the client port numbers so it is a little tricky to filter on the next connection: answered 21 Aug '13, 13:56  mrEEde edited 21 Aug '13, 22:55 |
Port 1184 is behaving well returning also 13 bytes when it received your data. The RTT is ~31 ms and your server delay_acks this data, everyone happy!
In Packet 24 the 'client' closes the connection as a FIN is coming in. Note that the ip.ttl is 54 this time while it was 55 on all other ACK packets. In packet 26 your server closes the connection, a FIN is sent out but doesn't get an ACK so you enter retransmission with increasing intervals,