Omg I love you!! I've seen you on the David Bombal chanell and I absolutely love the fact that you're such a positive person - I can feel that you're passionate about it. Also, has anybody told you that you look similar to Woody Harrelson?
One thing that would be important to remember here is that each sequence number is equivalent to one byte of transferred data. That really clarified a lot to me as I was learning about how TCP works.
That is it exactly. Each incremented sequence number represents one byte of transmitted data, with the important exception of the SYN and FINs, which count as a ghost byte.
I’m troubleshooting a TCP connection between a server and a group of PLCs. I’m closing in on the root of the problem and it seems that the PLCs fail to respond to the server when it coincides with a pair of TCP acked unseen segment + TCP spurious retransmission packets. Your videos are helping me a lot on building the knowledge I need to understand this. So thank you very much for doing them 👍🏻👍🏻👍🏻
Some sites says next seqnumber is not the length of data, but rather byte number of the first byte of data in the TCP packet sent. So it can only go up to 256? Which one is correct?
Hello - Next sequence number is the present sequence number + the bytes of data in payload. Since the sequence number is a 4 byte value, technically the integer can go up to 4,294,967,296 (2 to the 32nd power).
How does the sender keep track of the last sequence number sent? I see its part of the packet sent out to the receiver, but the next time the sender needs to send, from where does it pull the last sequence number sent (which it then uses to determine the new sequence number)?
I'm bit confused with "TCP Segment Len: " and "Total Len in IP Header" . Total Len in IP header is Actual data + IP header ? what about TCP Segment Len?
The push bit in the flags field (put simply) tells the TCP socket on the sending side to immediately send data without waiting for more data from the application, and the receiving TCP socket to send data up to the application without waiting for more. "Push" the data out and up without waiting. Actually it's a great idea for a video. Thanks!
@@ChrisGreer Thank you for the great video. I am a novice at Wireshark but it has helped me troubleshoot our Subway sign system. A source of confusion for me is, is there a difference between a filter when you are capturing vs. a filter after you stop capturing? That could be a video idea. I’ll let you know if I have any more.
I get why Wireshark has an option for relative sequence numbers, but why doesn't the TCP spec use them? What purpose does the initial value have and why doesn't it start at 0?
"Each endpoint of a TCP connection establishes a starting sequence number for packets it sends, and sends this number in the SYN packet that it sends as part of establishing a connection. There is no requirement for either end to follow a particular procedure in choosing the starting sequence number. The operating system is free to use any mechanism it likes, but generally it's best if it chooses a random number, as this is more secure. From that starting point, each packet sent by either end contains two sequence numbers - one to specify where in the stream the packet is, and an ACK sequence number which signifies the number of bytes received. Both numbers are offset by the starting sequence number" "2 In 4.4BSD (and most Berkeley-derived implementations) when the system is initialized the initial send sequence number is initialized to 1. This practice violates the Host Requirements RFC. (A comment in the code acknowledges that this is wrong.) This variable is then incremented by 64,000 every half-second, and will cycle back to 0 about every 9.5 hours. (This corresponds to a counter that is incremented every 8 microseconds, not every 4 microseconds.) Additionally, each time a connection is established, this variable is incremented by 64,000. "
Thank you for not making this a long and painful video - it was instead very clear and concise. Great work Chris!
Thanks Kareem - I don't like sitting through long boring videos any more than you do!
angel voice+ great instructor = Chris Greer
Perfect lesson... Now I'm clear on sequence numbers.
Excellent!
Huge thanks man. Best video about tcp what i seen so far on youtube.
Thanks for the comment! Glad you found the channel.
I find your voice very soothing, also thanks for explaining it so expansively.
Thanks for the comment!
Your video is being used in my university class!!!
Wow really? That is awesome. Thank your professor for me.
Ah, finally makes sense. Nicely explained, thanks!
Awesome - thank you for the comment!
Must say, you did it in really great way,...... your way is highway.. definitely.. keep it up Chris..
Thanks a ton!
You are a very good speaker. Wish my professor spoke as clear as you.
Thanks for dropping by the channel Eric!
thank you very much, this really helped me to understand this concept in an easy way.
Glad it helped! Thanks Julio.
Oh my god, you made more sense of this in 6 min than my professor made in 30 min (and he does presentations for DHS, FEMA, etc). Great job!
thank you! Glad it helped!
Thanks, finally someone explained this as it is supposed to be explained
Thanks for the comment!
Omg I love you!! I've seen you on the David Bombal chanell and I absolutely love the fact that you're such a positive person - I can feel that you're passionate about it. Also, has anybody told you that you look similar to Woody Harrelson?
One thing that would be important to remember here is that each sequence number is equivalent to one byte of transferred data.
That really clarified a lot to me as I was learning about how TCP works.
That is it exactly. Each incremented sequence number represents one byte of transmitted data, with the important exception of the SYN and FINs, which count as a ghost byte.
@@ChrisGreer and thus the sequence number isn't increment?
explained perfectly and your videos are very informative. thank you
You are welcome!
Amazing voice, Amazing explaination = Well done. 10/10 thank you
I’m troubleshooting a TCP connection between a server and a group of PLCs. I’m closing in on the root of the problem and it seems that the PLCs fail to respond to the server when it coincides with a pair of TCP acked unseen segment + TCP spurious retransmission packets. Your videos are helping me a lot on building the knowledge I need to understand this. So thank you very much for doing them 👍🏻👍🏻👍🏻
Thank you so much. This helped me do my assignment.
I might just learn with this videos for my exam :D
great vid man thanks
Thanks for the comment!
well explained and great pace in your explanation. Thank you :)
I get it now! Thank you Chris
Nice explanation. Thanks man!!
Thanks a lot really
Thanks very much! Excellent explication. I finally understood how SEQ and ACK works.
Fantastic explanation. Thank you so much!
Great video! I hope to be seeing more content soon! Thank you!
Thank you very much this helped me with my a-level coursework.
Thanks for this video!! You saved a person's brain from imploding
Some sites says next seqnumber is not the length of data, but rather byte number of the first byte of data in the TCP packet sent. So it can only go up to 256? Which one is correct?
Hello - Next sequence number is the present sequence number + the bytes of data in payload. Since the sequence number is a 4 byte value, technically the integer can go up to 4,294,967,296 (2 to the 32nd power).
this was awesome
Great videos! Could you sort the video in the playlist from easy to hard, or just in the order of publication?
great explain sir, all doubts clear can you pleas provide the pcap for better analyse.
Great explanation. Thank you, sir.
How does the sender keep track of the last sequence number sent? I see its part of the packet sent out to the receiver, but the next time the sender needs to send, from where does it pull the last sequence number sent (which it then uses to determine the new sequence number)?
!!!!!!!!!GURU !!!!!!!
The size of the packet which we add to the sequence number to get the next sequence number...is in bytes or bits?
That number is always in bytes - thanks Sam
Thank you
thank you so much
great video
Thanks!
Could you share the trace file with us Chris ?
If you can turn on google subtitles, more people can understand the content!thanks
Great idea, I have been meaning to work on the subtitles for my videos. Thanks for the feedback.
@@ChrisGreer
this one already have auto subtitles,not sure how to turn on...thanks
th-cam.com/video/HCHFX5O1IaQ/w-d-xo.html
I'm bit confused with "TCP Segment Len: " and "Total Len in IP Header" . Total Len in IP header is Actual data + IP header ? what about TCP Segment Len?
Chandra Sekhar Phani Sharma tcp segment length is tcp payload length. It is calculated by wireshark using (total packet length - Ethernet header (14 bytes) - IPv4 header size (20 bytes assume no option) - tcp header size (20 bytes))
@@dhhsncnd6107 tcp segment len is nothing but payload data without any (IP, Ethernet and tcp headers) it's is only the segmented data!!
thank you!
Thank you much, very nicely explained.
Can you attach the corresponding dump files? that would be awesome to follow up along with you.
Hello Doc - you can just send me an email at packetpioneer@gmail.com and I will send it to you. Thanks for the comment!
thank u
I'm having a problem, on wireshark i can't get an interface
Waiting for video on TCP Dup ACK & Retransmission
Thanks for the comment Manoz. I am working on it. Both are tough to fit into 5 minute videos but I think it can be done!
Perfect
What does PSH mean?
The push bit in the flags field (put simply) tells the TCP socket on the sending side to immediately send data without waiting for more data from the application, and the receiving TCP socket to send data up to the application without waiting for more. "Push" the data out and up without waiting. Actually it's a great idea for a video. Thanks!
@@ChrisGreer Thank you for the great video. I am a novice at Wireshark but it has helped me troubleshoot our Subway sign system. A source of confusion for me is, is there a difference between a filter when you are capturing vs. a filter after you stop capturing? That could be a video idea. I’ll let you know if I have any more.
@@mmaranta785 I like it! definitely a difference between a capture filter and display filter. Feel free to mention any other ideas.
i love you mate, you saved my ass lol thanks
Awesome! Thanks for the comment.
awesome
I get why Wireshark has an option for relative sequence numbers, but why doesn't the TCP spec use them? What purpose does the initial value have and why doesn't it start at 0?
"Each endpoint of a TCP connection establishes a starting sequence number for packets it sends, and sends this number in the SYN packet that it sends as part of establishing a connection.
There is no requirement for either end to follow a particular procedure in choosing the starting sequence number. The operating system is free to use any mechanism it likes, but generally it's best if it chooses a random number, as this is more secure.
From that starting point, each packet sent by either end contains two sequence numbers - one to specify where in the stream the packet is, and an ACK sequence number which signifies the number of bytes received. Both numbers are offset by the starting sequence number"
"2
In 4.4BSD (and most Berkeley-derived implementations) when the system is initialized the initial send sequence number is initialized to 1. This practice violates the Host Requirements RFC. (A comment in the code acknowledges that this is wrong.) This variable is then incremented by 64,000 every half-second, and will cycle back to 0 about every 9.5 hours. (This corresponds to a counter that is incremented every 8 microseconds, not every 4 microseconds.) Additionally, each time a connection is established, this variable is incremented by 64,000.
"
мужик, спасибо
Thank you!