RST,ACK sent from server during file transfer

retag add tags

I'm attempting to troubleshoot a RentMaster program failing to update. Full disclosure I've had a class in college that had a wireshark exercise but not much experience beyond that. I've been poring over a capture session I took of the update itself and it appears to be caused by an RST,ACK packet sent with the source IP of the server (No. 2273). I've been doing some research and found that despite the source IP being the server, this RST may not be coming from the server itself but from another device along the route.

The TTL of the RST packet is 60 whereas all the download packets in the TCP stream before this were TTL=53. I believe, from the answers on this question, that this means it did not come from the server.

Capture Session. Again, I'm not especially experienced in Wireshark but would love it if anyone could help me verify or refute this theory. In addition, could the difference in the TTL be a way of identifying the culprit? Could I, for instance, trace the route from the host machine to the server and count the hops to figure out which device is preventing this download?

harumph

asked 2018-08-24 22:42:57 +0000

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

Your theory seems to be correct, the data segments arrive with a TTL of 53 and incrementing ip.id values.
The RST packet arrives with a TTL of 60 and an ip.id of 0.
After the reset there are still 8 full-sized segments arriving, however there is a gap of 24 segments.
So the session was terminated in the middle of a download by a device presumably being 4 hops away whereas the linux server is 11 hops away .
A tracert rentmaster.net will probably show that it's the device at the edge into the NTT network.

net-165-91-128-1.net.tamu.edu  --> tamu-dlls-com.tx-bb.net

That still doesn't explain why this happens though.
It wouldn't surprise me if the session was dropped due to security / AV scanning

image description

mrEEde

answered 2018-08-25 07:04:42 +0000, updated 2018-08-25 07:22:10 +0000

edit flag offensive 0 remove flag delete link

Comments

I agree with @mrEEde with one caveat. The principal clue that the device sending the RST is not the server is the fact that the IP TTL in the RST packet is different from the IP TTL in all the other packets. I would not draw any conclusions from the fact that the IP ID is 0 instead of following the increment pattern of the other packets. IP distinguishes between "atomic" packets and "non-atomic" packets. An atomic packet is a packet that has not been fragmented and that will not be fragmented. How can we know that a packet will not be fragmented? Because every IP device is required to handle packets of at least 576 bytes. The IP ID is for fragmentation and reassembly. On an atomic packet, which will not be fragmented, the IP ID is meaningless and the IP RFC says that devices can put any number ... (more)

Jim Aragon (2018-08-25 18:20:39 +0000) edit

Fascinating, I'd not even heard of IP ID or atomic packets before. So if I'm understanding you correctly, the IP ID was 0 in this case (and out of sequence) but only because the device happens to be one that assigns 0 to all packets <576 bytes? It's possible that I may have had another device in this scenario where the IP ID just continued the incrementation of the previous packets?

Also, @mrEEde, how did you arrive 4 and 11 for the hops? Did you figure that out just from Wireshark? You're exactly right of course, I ran tracert 216.172.104.148 from the original network and it was 11 hops, 5 of which (including the probable culprit) were within a network my university manages.

harumph (2018-08-25 18:47:20 +0000) edit

"So if I'm understanding you correctly, the IP ID was 0 in this case (and out of sequence) but only because the device happens to be one that assigns 0 to all packets <576 bytes?"

Probably, although the phrase "out of sequence" is not technically meaningful for IP IDs. They are not required to follow any particular sequence, merely to be unique. However, most devices do increment regularly.

how did you arrive 4 and 11 for the hops?

The IP TTL is normally set by the operating system, although it can be overridden by applications. Knowing what typical starting values are, we can estimate how far away a device is. The TTL is decremented by one as the packet passes through each router. (The rule is actually more complicated, but that's what usually happens.) 64 is the next most common starting value higher than 53 or 60, so ... (more)

Jim Aragon (2018-08-25 20:24:05 +0000) edit

The most probable cause for a connection reset by a third device is that a malware pattern match was found and the inspection device (Intrusion Prevention System, or deep inspection firewall) terminated the session as a countermeasure. This can happen for valid and false positive malware detection, so it is possible that this abort is happening by mistake.

Jasper (2018-08-26 12:44:58 +0000) edit

If this is the case a https download might work as a circumvention https://www.rentmaster.net/support/do...

mrEEde (2018-08-26 13:47:16 +0000) edit

add a comment see more comments

RST,ACK sent from server during file transfer

Comments

1 Answer

Comments

Your Answer

RST,ACK sent from server during file transfer edit

Comments

1 Answer

Comments

Your Answer

RST,ACK sent from server during file transfer