Newbie alert! Hello everyone! first post in this forum, hope everyone is doing great! Wanted to see if someone could shed some light got this trace, and I have been staring at them for a long time and I still can not find a conclusion my reassoning so far is that the normal 3-way handshake happened on the first 3 line entries then 1.1.1.1.1111 sends to 2.2.2.2.2222: P 1:102(101bytes) now the confusing part is line 6 1.1.1.1.1111 > 2.2.2.2.2222: . ack 1 win 46 <nop,nop,timestamp 7117339="" 517158,nop,nop,sack="" 1="" {1449:2260}=""> What is sack 1 for here? we got already that at sorry, I am a mess, still learning TCP as i go, I have read tons of documentation, seen videos, and so on and concepts are still not fitting. thank you for your help Ppcap This question is marked "community wiki". asked 05 Dec '15, 12:59  ppcap edited 06 Dec '15, 09:33  grahamb ♦ |
One Answer:
The SACK is there because a packet (or more) got lost. Line 4 says that 1.1.1.1 has sent bytes 1-102 of payload. It is ACKed by line 5 - this time without SACK because there is no gap in the data. Line 6 says that a packet carrying payload bytes 1449 - 2260 has arrived, which implies that the packet(s) carrying payload bytes 1 to 1448 have not arrived yet because it is the very first packet to carry payload since the 3-way handshake took place. Therefore, 1.1.1.1 sends a SACK, informing 2.2.2.2 about the loss and about the fact that it is enough to retransmit the missing part of the data and that there is no need to retransmit also bytes 1449 to 2260 as 1.1.1.1 has already got them. See more about SACK purpose in this illustrative blog post. As for your additional question,
it depends on the application using the tcp session how it reacts to the fact that the missing data have not been delivered within those 3 minutes. If it wasn't a forged capture (as I suspect) but a real life one, in this situation a nicely written application would terminate the session with a Reset rather than Finish, to indicate to the remote application that there was an error. answered 05 Dec '15, 13:39  sindy edited 05 Dec '15, 14:40 Thank you Sindy, it seems that after the edit, the capture was changed. http://pastebin.com/tCDh91TR 12:57:25.432924 IP 1.1.1.1.1111 > 2.2.2.2.2222: . ack 1 win 46 <nop,nop,timestamp 7117339="" 517158,nop,nop,sack="" 1="" {1449:2260}=""> so you mean that probably something went missing between line 5 and 6? (05 Dec '15, 14:05) ppcap 1 I was editing the question only so that the newlines would be shown, so the contents hasn't changed. And yes, I really mean what I've written, i.e. that a packet or more have surely, not probably, been lost between "line 4" and "line 6" of your pastebin link. Tcpdump shows clearly which range of bytes of the payload was present in each of the packets. (05 Dec '15, 14:15) sindy Thank you for sharing knowledge (05 Dec '15, 14:18) ppcap Oops... I now get what you meant by "capture was changed". No, it has not changed, I'm blind and I've thought both lines 4 and 6 were describing payload transmission in the same direction. But this mistake does not change the conclusion: between the initial 3-way handshake and the packet on line 6, there is no packet in the same direction as packet on line 6 which would carry any of bytes 1-1448 of that direction's payload. So I've edited the answer accordingly. (05 Dec '15, 14:22) sindy I guess what may be confusing for you is that the absolute seq number does not start from 1 but from a random value, so you've thought it was normal that the counting of payload bytes would not start from 1 either, but that is a misunderstanding of the seq interpretation. The SYN == 1 in the first packet says that the absolute seq value in that packet should be remembered for the lifetime of the session. The difference between the absolute seq value of each of the following packets and the absolute value from the SYN packet then makes the relative seq number of that packet. The relative seq number is in fact a counter of payload bytes, starting from 1 rather than 0 because the absolute seq is incremented by 1 during the initial 3-way handshake. Tcpdump displays the absolute seq values for the packets with SYN == 1, but it then switches over to displaying relative ones (1:102, 1449:2260 in our case). This is done for comfort of reading; it goes so far that the first value of the first:last range is actually not a value transmitted inside the packet but calculated as "last (which is the relative seq) minus payload size". (05 Dec '15, 14:54) sindy |
just in case the interface messed with the format http://pastebin.com/tCDh91TR
Thank you again
So what exactly is your question?
Christian, thanks for looking at this. What is confusing from this trace for me is line 6 1.1.1.1.1111 > 2.2.2.2.2222: . ack 1 win 46 <nop,nop,timestamp 7117339="" 517158,nop,nop,sack="" 1="" {1449:2260}="">
What does this exactly means? sack 1 means for me that we got that pkt, and now after 0:02:59.508881 2.2.2.2 closes it?
Anything you could think about?