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.
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.
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.
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.
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.
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.
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.
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.
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?