This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Newbie learning TCP :) P 1:102(101) ack 1 ??

0

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

12:57:25.365277 IP 1.1.1.1.1111 > 2.2.2.2.2222: S 2848279040:2848279040(0) win 5840 <mss 1460,sackOK,timestamp 7117332 0,nop,wscale 7>   
12:57:25.368977 IP 2.2.2.2.2222 > 1.1.1.1.1111: S 1373424911:1373424911(0) ack 2848279041 win 5792 <mss 1460,sackOK,timestamp 517157 7117332,nop,wscale 7>   
12:57:25.368992 IP 1.1.1.1.1111 > 2.2.2.2.2222: . ack 1 win 46 <nop,nop,timestamp 7117332 517157>   
12:57:25.373612 IP 1.1.1.1.1111 > 2.2.2.2.2222: P 1:102(101) ack 1 win 46 <nop,nop,timestamp 7117333 517157>   
12:57:25.377440 IP 2.2.2.2.2222 > 1.1.1.1.1111: . ack 102 win 46 <nop,nop,timestamp 517158 7117333>   
12:57:25.432908 IP 2.2.2.2.2222 > 1.1.1.1.1111: P 1449:2260(811) ack 102 win 46 <nop,nop,timestamp 517164 7117333>   
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}>   
13:00:24.941805 IP 2.2.2.2.2222 > 1.1.1.1.1111: F 2260:2260(0) ack 102 win 46 <nop,nop,timestamp 535114 7117339>

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)
next 2.2.2.2.2222 tells 1.1.1.1.1111: OK ACK, he got 101 bytes he expects to see on the next seq 102
then 2.2.2.2.2222 sends 1.1.1.1.1111: P(ush)acket of 1449:2260(811bytes)

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
12:57:25.373612 IP 1.1.1.1.1111 > 2.2.2.2.2222: P 1:102(101) ack 1

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's gravatar image

ppcap
16337
accept rate: 50%

edited 06 Dec '15, 09:33

grahamb's gravatar image

grahamb ♦
19.8k330206

just in case the interface messed with the format http://pastebin.com/tCDh91TR

Thank you again

(05 Dec '15, 13:07) ppcap

So what exactly is your question?

(05 Dec '15, 13:23) Christian_R

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?

(05 Dec '15, 13:28) ppcap

One Answer:

0

What is sack 1 for here?

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,

now after 0:02:59.508881 2.2.2.2 closes it?

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's gravatar image

sindy
6.0k4851
accept rate: 24%

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