This is from a customer, cannot send the whole log. One side is our communications device, another is Windows Server 2008. This happens very rarely, but we see it. Windows replies with '2470', seq is 1 instead of 0, and it is ACK instead of SYN-ACK, and it acks a packet that is never seen (not in all the previous communication either). This packet is repeated as if Windows sees duplicates. RST is ignored. The device retries and finally succeeds. Any idea what is wrong? asked 22 Feb '13, 09:54  IoT edited 22 Feb '13, 10:00 |
2 Answers:
Looking at your image, all sessions that fail are from port 1598 (I looked up picknfs in the services file). Then the session that does succeed is from port 1601 (again from the services file). So it looks like a device between you and the server was having a problem with traffic from port 1598 at the time. I have seen this behavior with a Cisco ASA firewall running old software. But it could be a problem on any device that keeps track of sessions (Firewall, Loadbalancer, Proxy, etc.). What kind of devices are in the path? answered 22 Feb '13, 23:30  SYN-bit ♦♦ I got the answer from the customer representative: the Windows server (that gives bad replies) has Windows Firewall and it also has Symantec Endpoint Protection. He will attempt to try disabling these. And here is the [whole chunk in cloudshark][1] http://www.cloudshark.org/captures/6be79d094391 (23 Feb '13, 10:02) IoT 1 I'm confused. Would anyone care to speculate why, in frames 3, 6, 9, 12, and 15, the RST packet claims to be both FROM and TO IP address 72.237.119.107, whereas the MAC addresses correspond to packets that are FROM 192.168.1.2 and TO 72.237.119.107, as does the IP TTL? Is this just an intermediate device that's completely mangling the packets? (23 Feb '13, 17:23) Jim Aragon Wow, this is big, and I did not notice this. Thank you! (23 Feb '13, 22:55) IoT 1 How are these networks connected? I notice that the round trip time is very high--well over 700 ms--even for the successful connection, and we seem to be going through some sort of DigiBoard device. (24 Feb '13, 09:36) Jim Aragon Thank you very much Jim - I just learned that our engineers identified a firmware bug that led to this behavior. Fyi, this is an over-the-air mesh network in the area of smart metering. Devices from different vendors are involved. (25 Feb '13, 11:25) IoT |
This looks like a typical case of where the application decides to refuse a session based on some setting it has. This is usually something like "only allow clients from a subnet like w.x.y.z" - the SYN comes in, and the TCP stack tells the application about it while it already acknowledges the SYN on it's own. The application realizes that it doesn't like the connection from that source IP and shuts it down by closing the socket - which results in a reset. In your case the connection works after a while, so the criteria can't be the source IP. But maybe there is some "maximum concurrent sessions" setting in the application, and it will only allow the new connection after an older one has finished and/or has timed out. Sometimes FTP server do something like this to avoid having too many connections, but they ususaly do it within the application flow, not on kinda rude socket behavior. Check if there is a limitation of any kind on the device that sends the reset. If there isn't any (meaning: someone other than you tells your there isn't any ;-)) you should try to verify this. I would capture the connections after a restart of the server and start counting concurrent sessions, which you can do with Wireshark conversation stastistics by looking at start and duration times. Oh, and by the way, the RST is not "ignored". The client just tries a new connection attempt by sending another SYN. answered 22 Feb '13, 11:03  Jasper ♦♦ Thank you very much! I will have to wait until Monday. I will also ask if it is possible to post the whole shark. (23 Feb '13, 01:57) IoT |
Thank you! Lets see, here is what happens:
I would assume Windows would reset if it could not service the connection, instead the device resets - because it gets ACK instead of SYN-ACK.....
By the way the wireshark is taken at Windows side. Any further comments?