This is our old Q&A Site. Please post any new questions and answers at


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.

I'd appreciate any help. Thank you in advance!!

asked 21 Aug '13, 03:36

Ferran's gravatar image

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

permanent link

answered 21 Aug '13, 13:56

mrEEde's gravatar image

accept rate: 20%

edited 21 Aug '13, 22:55

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 21 Aug '13, 03:36

question was seen: 2,109 times

last updated: 21 Aug '13, 22:55

p​o​w​e​r​e​d by O​S​Q​A