Hello, Can you tell me what is the problem for the trame between an embedded system (IP 1923.168.0.34) and IE in a PC (IP:192.168.0.252) I don't understand why IE have not send ACK after the number 6 packet. Thanks
asked 04 Jan '13, 09:10  aamgr edited 04 Jan '13, 09:32  grahamb ♦ |
2 Answers:
There is a "Connection: Close" header in the HTTP response. This means the client (IE) will collect data until the end of the TCP session. I would have expected the TCP layer to send an ACK though for receiving data. Did you tweak any TCP settings (like enlarge the delayed ACK timeout) on the client? answered 04 Jan '13, 12:19  SYN-bit ♦♦ |
There is full a 3-way handshake and a HTTP request, so I don't think it's a network problem. So what else? The browser or some security software on the Client (Windows PC) does not like the answer of the web server (just a dump example: there is a time stamp from 2004 in the answer. That should be no problem for 'regular' software, but you never know ;-) ). Do you have any security software on that PC (Anti Virus Scanner that intercepts the HTTP data stream, IDS, Firewalls, Endpoint Protection)? If so, please disable that piece of software and try again. Does it work with other, similar clients? UPDATE: As far as I can read the screenshot, there is a "Vary:" header in the answer. After "Accept-Ranges: bytes" you see something called "Vary: Accept-Encoding". That header is not often used and might cause problems with a browser (not sure about IE) and/or security software. Recommendation: First try a different browser (Firefox). If it works, it's a problem with IE. If it does not work, it might be a problem with the type of software I mentioned. UPDATE #2: There are a lot of reports about problems with IE and the "Vary:" header. None are that strange as in your case (no ACK), but still. Regards answered 04 Jan '13, 09:56  Kurt Knochner ♦ edited 04 Jan '13, 10:01 Hello,
2.I dont have firewalls, and my anti virus is Ok 3.For firefox same result, but firefox retry 5.For help you to find the problem, the server (192.168.0.34) is a custom server, is it possible that the http trame is not good but i dont have see anything. Thanks (07 Jan '13, 01:43) aamgr
O.K. one possible reason eliminated.
O.K. so it's not a problem with the HTTP response, at least not regarding the browser. Except what @SYN-bit mentioned. But then there is no good reason why the OS would not ACK the TCP segement.
That's a configuration option of the server.
I thought it is because of some problem in the HTTP response in combination with some security software, as there is no reason why the OS would not ACK the TCP segement unless some security software dropped the frame because it was not able to handle it. If it was a problem with IE, (Vary: header) that could have caused simialar behavior, as IE is pretty deep integrated into the OS and you never know what Microsoft really does. Now, as Firefox shows the same behaviour, I'm back to the security software, as I can't see any good reason for the OS not to ACK the frame. Again some questions:
(07 Jan '13, 01:48) Kurt Knochner ♦
For my test I have in my PC 2 network card in on card i have my server and in the second, I have my society internal network . I capture in my PC. link text Thanks (07 Jan '13, 07:44) aamgr I don't see any problem in the capture file, that could cause the missing ACK. So, the only idea I have, is either a bug in the OS (a rather strange one) or some software on your PC (which I believe). some more questions:
(07 Jan '13, 08:06) Kurt Knochner ♦ |
4.The ACK time-out is already long (10s) before server send RST.
Wireshark has TCP checksum checking disabled by default because this shows a lot of errors when capturing your own traffic on a system with checksum offloading enabled (see: http://wiki.wireshark.org/CaptureSetup/Offloading).
Could you enable TCP checksum checking in the TCP protocol preferences to see whether the embedded device calculates the checksum correctly?
I followed the link to your capture file in your comment on @Kurt's answer. When I open the capture file in Wireshark and enable TCP checksum checking, it shows that the checksum is indeed wrong:
(In this case it can not caused by checksum offloading as you are not capturing on the sending host)
You will have to investigate the embedded server why it is not calculating the checksum of the response correctly.
Hello Thanks for help. Effectively, i have activated TCP checksum in Wireshark and it is bad. I have add TCP checksum in my embedded application and the result is good, the PC send the ACK. Thanks for the help
@aamgr, I moved your comment to the answer to which it applies. Please notice that this is not a "normal" forum, but a Q&A site in which the answers move up and down based on the amount of likes they get.
Also, to help other find the correct answer to the question, you can (and are encouraged) to accept the best answer by clicking on the checkmark next to it...