hi there. i have a weird retransmission that i don't understand. 746 54197.486258 199.67.137.5 192.168.0.200 TCP 60 https > uma [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 911 60316.846670 199.67.137.5 192.168.0.200 TCP 60 [TCP Retransmission] https > uma [SYN, ACK] Seq=3669499865 Ack=1 Win=16384 Len=0 MSS=1460 as you can see, it is labeled a retransmission although the sequence number just jumped like crazy, how can that be? maybe wireshark analyzed it as sequence error? thx alot asked 20 Nov '15, 09:16  Ilya Morgens... edited 20 Nov '15, 09:29 |
One Answer:
There are two "strange" things:
Adding these two things together and without having seen the whole capture file, I would say that there was a beginning 3-way handshake at frame #746 (SYN-ACK seen), but that never completed (ACK missing). Then nothing for quite a while. Then a new connection attempt, however with the same source port (plus the SYN is either not shown or not in the capture file), and this time with a different SEQ number. That's why Wireshark (which is using relative SEQ numbers by default) is showing such a large SEQ for the SYN-ACK. It believes that this belongs to the old/first connection (same 5-Tupel). Anyway, it would be easier to do any analysis with a capture file. Would it be possible to upload the file somewhere (dropbox) and post the link here? Regards answered 20 Nov '15, 09:26  Kurt Knochner ♦ showing 5 of 9 show 4 more comments |
here you go: http://www.snaketrap.co.uk/pcaps/hbot.pcap
assuming that Kurt is in the train with no signal, I confirm his suspicion and I share his wonder where the initial SYN from the 192.168.0.200 has been lost for both the sessions?
Assuming that the 192.168.0.200 has only one interface (on which you took the capture), could it be that there is another machine in the same subnet/LAN segment and the router/firewall/NAT connecting that subnet to internet went mad, so it has sent a response to one machine's tcp SYN to another one?
i think you are right, but even if there is some kind of a new connection attempt, why does it labels it as a RETRANSMISSION. if wireshark mistakes it to be a relative SEQ number corresponding to the first connection and the new sequence number is larger than expected, it shouldn't be a RETRANSMISSION
Don't blame Wireshark here, as it does not have enough information to mimic the behaviour of the particular server (for some servers, the distance in time would be enough to treat it as a new connection, for others it would not). Wireshark protocol dissection and analysis are useful tools assisting you but you must not blindly believe them.
In this particular case (tcp analysis), it is your choice whether to treat the seq/ack numbers as relative ones or absolute ones (relative is a default setting because for most cases it is more convenient for reading); even if set to absolute, the result would be the same.
In fact, it is higher if taken as relative and assuming a rollover; if taken as absolute, it is lower, so again the "retransmission" conclusion is correct.
Even the occurrence of RST packet does not change anything about it because even if everything behaves normally, a retransmission may arrive after RST has been seen in the opposite direction, as Wireshark does not take into account at what interface the capture has been taken.
not this time :-). Shopping for dinner ;-))
BTW: I stay with my analysis. I followed the TCP stream and disabled relative SEQ numbers in Wireshark. You can see exactly what I thought. However, I don't have an explanation for this. Either that's what was on the network or the rest of the frames have not been captured.
>>Wireshark Screenshot<<
You see the same behavior for the target throughout the capture file.
There are other 'full' connections from 192.168.0.200, so this is only related to 199.67.137.5
I guess the rest of the frames have not been captured for a yet unknown reason. The behavior is so strange, I don't believe that only these frames have been on the network, unless somebody is doing some kind of 'experiment' and sends arbitrary frames into your network.
I haven't gone that deep, but it reinforces my assumption that the NAT device sends the responses from 199.67.137.5 to 192.168.0.200 instead of sending them to the initial speaker.
In extreme case it may even be that the NAT device is not guilty at all. Assume that the NAT device uses 1:1 port forwarding and does not act as a firewall, and that someone at the other side of the globe uses the public IP address of the NAT device to send its tcp requests to the 199.67.137.5. The responses from that server are then routed properly to the NAT device.
Only a capture on the public interface of the NAT device can say whether the extreme case is true or whether the NAT device went really mad.
Note that the responses from 443 come towards low port numbers on our side which should explain why the 192.168.0.200 responds with a tcp packet instead of sending icmp port unreachable. Initiating tcp sessions towards port 443 from ports IANA-assigned to distinct services is not a typical behaviour of a web browser so I'd rather suspect something evil.
I believe we are chasing a ghost here. The trace file is from the " Capture the hacker 2013 competition (by Dr. David Day of Sheffield Hallam University)" http://www.netresec.com/?page=PcapFiles So I don't think that the client where the trace was running ever sent those SYN packets.
The tracefile contains packets from several days and doesn't seem complete but edited by somebody.
hahaha +1, good find!
@Ilya: What was your intention to ask this question here? Would have been much easier, if you had mentioned the hacker competition, instead of letting us guess what could be the reason for this !!!