TCP - Can you explain this behavior?

joehinkle wrote on Wednesday, September 28, 2016:

I’m attempting to do multiple HTTP GET’s - same IP – connection and socket closed after each GET is accomplished.

I’ve attached the pcap file for the wireshark pic below.

I make a connection using local port 55435 (FreeRtos is issuing the port number). First file fully downloaded.

Connection closed - socket closed.

New socket - new connection – this time FreeRtos provides local port 55436.

Connection is good.

I issue the GET … wireshark complains about “TCP Port Numbers Reused” — server disconnects.

If I run this … 5 times … the failure aboves occurs 4 out of the 5 – only one out of 5 does the server NOT disconnect and downloads the file.

I can’t see anything wrong – but old age and bad eyes can also do that!

Can you explain what might be causing this behavior?


Joe Hinkle

joehinkle wrote on Wednesday, September 28, 2016:


I placed a 100 msec delay after the first close and the second GET worked as expected.

I thought the hand-shaking between clint and server for open and closes were such that race conditions were not suppose to occur.

Was THAT a correct belief?



joehinkle wrote on Wednesday, September 28, 2016:


Adding the 100 msec does NOT solve the issue.

So It can’t be race?

Any thoughts?

Any ideas as to why wireshark says “TCP Port Numbers Reused”



rtel wrote on Wednesday, September 28, 2016:

I just replied to your previous post along the lines that re-using TCP port numbers should not be illegal, but could cause an issue with anything in between your client and server that is maintaining state - or possibly the server itself if the old connection is in the TIME-WAIT state. However, in this case, according to your post, you don’t seem to be re-using a port number anyway - so I cannot explain that part.

joehinkle wrote on Wednesday, September 28, 2016:

I’ve tried downloading the file using a browser and it works just fine.

I was concerned that the server might have folder/file rights getting it the way since it immediatelly RST when the GET is received - but Chrome has no issue with it. Granted, the browser test is NOT do a back-to-back file request, but my app should not cause an issue since I’m using 2 different local port number even though wireshark is detecting a port reuse issue somewhere.

heinbali01 wrote on Wednesday, September 28, 2016:

A TCP server socket has a fixed port number and it may be reused again and again.

If a TCP client socket uses the same local port number, it is very confusing.

A connection is identified by 4 numbers:

  • source IP-address
  • source port number
  • target IP-address
  • target port number

Now you try to build up connection-A, close it, and then you want a new connection-A (using the same 4 numbers).
Routers won’t like it and also the target machine may have memories of the earlier connection-A.

joehinkle wrote on Wednesday, September 28, 2016:


THAT is not what is happening (it looks like your response is associated with a different post of mine).

This post about an issue that wireshark says port numbers are resused but if you look at the wireshark data – there are TWO different port numbers – a different one for each connection.

FreeRtos TCP is providing the port numbers – I totally close a socket down between each connection and FreeRtos is providing a different local port — THAT is why I don’t understand the wireshark statement and the RST by the server.

Any thoughts – or maybe I don’t understand what you are attempting to tell me other than local port numbers must change between connections.



joehinkle wrote on Wednesday, September 28, 2016:


I changed my process to attempt to keep the connection open.

The Server has a different idea. I’m using HTTP 1.1 with Connection: keep-alive. I’m NOT iniatting the shutdown.

It turn out, the server is closing the connection after the file transfer even though I ask for a keep-alive.

I detect the server closing the socket, I close MY socket, wait 1 second, and retry the GET using a brand new socket. Many times, this second/third/forth attempt is immediately met with the server issuing a RST after I send the GET.

I count the number of retries attempt before the server actually accepts the GET and downloads the file – it is usually under 6.

I wish I could identify if this is a communication issue that I can address or something about the way this specific server is handling HTTP GET requests.

Any comments welcome.



jeanpaulh wrote on Saturday, October 01, 2016:

Hi Joe,

I think the timing in your pcap file is a bit odd. If you look for example at the start of the request:
Package 9 is a SYN request (normal behaviour) immediately followed by
Package 10 an ACK. This is odd; there is nothing to ACK?
Package 11 a GET request. But the server has not yet acknowledged any connection at this point.

At package 12 the server sends the SYN-ACK. This should occur between package 9 and package 10.
Package 13 is the ACK to the actual GET request (sequence=1, ack=99. The length of package 11 is 98 bytes so that makes sense).

But then at package 14 you acknowlegde data that has not been send yet (ack=261). Besides the sequence number is way out of sequence.

This doesn’t answer the question why the second request fails, but I’m more surprised that the first one actually succeeded.

Can you please verify the tcpdump you have made?
In the screenshot you can see the normal sequence you would expect when requesting the file.


joehinkle wrote on Saturday, October 01, 2016:


Thanks for commenting.

I’ve noticed the same behavior most of the time.

I take it that wireshark may not be processing the packets in the same order they appear on the network.

In order for may computer, running wireshark, to able able to capture packets to/from my embedded FreeRtos project, I have both the embedded project and the computer connected to a 4 port HUB - not a switch.

I’m wondering if the HUB is paying a part in the way wireshark receives the packets.

I have sent a new pcap file.


rtel wrote on Sunday, October 02, 2016:

I take it that wireshark may not be processing the packets in the same
order they appear on the network.

I think that is extremely unlikely - I have always found Wireshark to be
a very reliable tool.

I’m wondering if the HUB is paying a part in the way wireshark receives
the packets.

Again, doubtful, if it is a ‘dumb’ hug rather than router/switch it
should be transparent.

joehinkle wrote on Thursday, October 06, 2016:

If the hub is not playing with the order of the packets as seen by wireshark on the computer, and wireshark is not having a packet ordering issue with my computer’s driver, then that begs the question, why would TCP message transmissions and reception between a web server and FreeRtos’s TCP stack be goofy.

If you manually reoder some of the packets – it would appear the proper TCP handshaking is occuring – just not ordered properly for wireshark to process.

heinbali01 wrote on Thursday, October 06, 2016:


It looks like your embedded devices has a HTTP session on the Internet.
To simplify testing, would it be possible to run a web server on your laptop and connect through a LAN?