This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Non controlled llsurfup-https packet and connection reset

0

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's gravatar image

Ferran
1111
accept rate: 0%


One Answer:

0

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: alt text

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). example: 070d0fff802d0a0b1508040d00 The last 8 bytes seems to be a time in seconds in little endian notation as it increments by ten every ten seconds.

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 alt text 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!

Port 1025 is not returning your data but just acking with increasing delays 80ms-166 ms. alt text 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,

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: tcp.stream eq 2 and frame.number lt 74 shows the new connection from a mis-behaving clients, ending up in the same sequence.

answered 21 Aug '13, 13:56

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

edited 21 Aug '13, 22:55