In the application in question, I get this message when trying to access/download to an embedded web server: An error occurred in the secure channel support I've made a WireShark log of the communication: www.roswall.com/ws_log.zip I stumble over the following part. Any ideas to what I should be looking at or for on this PC?
asked 20 Jan '15, 17:39  benneharli |
One Answer:
In the tracefile, the client is the one closing the connection with a FIN. Sometimes after receiving the "ServerHello", sometimes even before sending the "ClientHello". This should be looked into. The TCP/RST you are seeing is not the problem itself, but is also not correct. When the client sends the FIN, it means it will not transmit data itself anymore, but it should accept data from the server. When the server sends the first part of the "Certificate" message (frame 22), the client responds with the TCP/RST (frame 22). This is not compliant to the TCP RFC. One thing that might trigger this behavior on the client is the fact that the server starts the TCP session with a window size of 0 and then after the 3-way-handshake increases the window size to a normal value. Which is compliant to the TCP RFC, but still unusual behavior. So the combination of TCP implementations might be the culprit here. answered 21 Jan '15, 01:13  SYN-bit ♦♦ edited 21 Jan '15, 01:17 |
Thanks. I'll look into this, and see what I find.
I guess this is what you refer to?
http://wiki.wireshark.org/TCP%20ZeroWindow
Yes it is, however, the article handles the case where during a data transfer, the window size decreases until it reached zero, meaning the receiver of the data is not able to fetch the data from the TCP receive buffer quickly enough.
In your case, the embedded system starts with a zero window, which is peculiar, but not forbidden. Maybe it wants to reserve resources by waiting for the 3-way handshake to complete before allocating memory buffers.