I can't say thank you enough on how important is for people like me, that is just starting on networking world after working in IT +10 years, seeing you and David doing what you do! Thank you !
Currently, I am writing some TCP/IP test cases with raw sockets and your analysis help me a lot to figure out the concept. Thanks for the simplified explanations and good quality videos!
@@ChrisGreer TCP analysis is deceptively hard, I found. Even something seemingly simple like ACK numbers can throw you for a loop. At least, that the case for me.
Hay Chris, awesome vids man ! pls keep em comming, dont stop !!!! PCAP of performance / drop issues are a nightmare to troubleshoot but you make it soo easy!!!!
Hi Chris thank you for this fantastic analysis again I dont know if my understanding is correct but i think that Since the server sends the packets #14-17 out of orders that were acknowledged by packets #18-20 Maybe The Packet #22 is a response to the packet #9 when the client asked for the gap and since this packet was already sent (the server flaged it with Superious Transmission).
In the first packet (the first SYN), there is an TCP options, the MSS with a value of 1460 bytes. But each TCP packet has a Window size that is greater than the MSS for example 8192 bytes. I'm telling my link partner I can receive 8192 bytes at once but my MSS is smaller. Can you explain this point please?
Hello Yunus - that is a great question. So if you tell me your holding tank is 8192, I can't send you 8192 in one packet because our other buddies along the way will get upset (IP MTU and Link level MTU - usually 1500ish). So I have to cut this baby up into smaller chunks (1460) giving room for the TCP and IP headers before we bump our heads on the MTU. So 8192 will turn into five 1460 byte segments, with a last one of 892 (which will probably have the PSH bit set). It's almost like - let's go get a pizza Yunus. I can eat four slices (all my stomach can handle - 8192) but please put only one on my plate at a time because the plates are so small! Hope that helps.
@@ChrisGreer Good day Sir! Thanks for replying sir, Means a lot! Yes sir at the file level only, like if any bits changes means how to detect that using hamming code sir ? Actually I am doing project in *tracer & packet capturing using wireshark* when I searching for wireshark videos, I saw yours ( which contains what I need), but I didn't find the solution for my project on how to use hamming in wireshark sir! So I thought to ask you sir!
How likely the packet is not showing up in wireshark due to tcpdump or packet sniffer is not able to capture all the packets. I normally use the ip packet IP to identify gaps in my cpap. Not sure how accurate it is. Any recommendations?
Great suggestion. Short answer? I use non-relative when I'm in a dual side capture analysis scenario and I need to track a packet through a NAT or a Port Translation. Usually those boxes will leave the original raw seq alone.
Thanks for the comment! So the issue was an MTU problem on the return path from the server. It was sending segments that were too large to fit under the MTU ceiling. From the pcaps we can determine that from the behavior, but we can't tell exactly which box was doing it.
Hello Eirik, yes that is correct. Sequence number wrapping is what it is called. This is where the timestamps option can come in. If we are moving a ton of data, TCP can use the timestamp to prevent confusion about "which" sequence number it sees in the case of wrapping - a past one or a current one.
thank you, very high quality material! quick question - at minute 15:17 - how can You be sure that the server got the 4067 ack? You said that "just by looking at the packet flow we can say that it was indeed spurious". but as I see it, theoretically it's possible that the 4067 ack didn't make it to the server, don't You think?
It's most likely that the spurious retransmission was a result of the triple-double. There were three duplicate ACKS above it. The acks between, the ones you had mentioned, are fired off, and before the network roundtrip time (85mSec) we get the retransmitted data. Also, all symptoms indicate that there was packet loss of large MSS's in the direction from server back to client - not small packets (ACKS) from client to server. So it is pretty safe to assume that the server got those ACKs and was just reacting to the Triple double. This is another reason I really try to get trace files from both sides of the conversation so we can absolutely prove questions like you had. Thanks for the comment and hope that helps!
Dear Chris, thank you for your wonderful videos. Just one question, what are some protocols/captures to look for when computers are freezing/hanging when connected to the LAN on the same switch, only one switch in the building with 20+ users.
Hmmm.... great question. I would look for connectivity kind of problems - ARPs, DNS Slow or No Response, TCP SYN Retransmissions, Resets, or maybe even unusual STP activity. That is where I would start at least!
Can anyone help me I’m trying to play ps4 vanguard and I have to put a port forwarding but the TCP says : 1935, 3478-3480. What to I do with the 1935?? Where do I put that number ??? Please help
Hi Chris. thank you for this channel it really help me in my every day work. Just wondering if you can help. When I tried to upload a file in website I'm getting error. Where do I start looking in wireshark? thank you in advance.
Lots of ways you could go with that. Start with filtering on the conversations between client and server, then add in the protocol in use (is it HTTPS? SMB?) Then at the time the error flags look for resets, application hangs, or tcp delays. That is where I would start, but it is hard to say without more detail into the issue.
I was running wireshark on my Wifi and I observed that for the same source and destination it was sometimes using TCP and sometimes QUIC which is UDP based ? How is it possible ?
Right now since we are in an adoption process with QUIC, most sites support both. So you may see a TCP connection and a QUIC connection until the site goes all QUIC from the get-go. Even then, we'll probably still see TCP hanging around for some time over the web!
Hey Chris, I know you are the only one who can help me. I am running an iperf between two sites and the link is 1G. When I run with linux I get 1G either way. As soon as I install windows on it, I get 150Mbps. Not sure why am I experiencing this behavior, can share the PCAPs as well.
Hey - I saw your pcaps you sent over. You need to manually increase the window size on the iPerf test. It is only going to use 264KB as a congestion window by default. Use the -w switch and I would crank it up to 2,000,000 (2MB) in your case due to the latency.
Given your knowledge of packets and protocols, do you ever play with tools like scapy to test things? I think learning to craft packets it's awesome way to learn, so if you ever upload something like that I will double-like it haha
@@ChrisGreer awesome. love your content mate, I love cybersec and wireshark is a total must for it. Thanks for all the time you invest in this content.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
The best Wireshark tutorial on the internet, no BS and straight to the point. Thanks Chris!
I can't say thank you enough on how important is for people like me, that is just starting on networking world after working in IT +10 years, seeing you and David doing what you do! Thank you !
Thanks! I appreciate the comment.
Great explanation. First English speaking RUclipsr I have followed.
Chris keep on going the way you are! Thanks a lot for your great stuff.
Thanks, will do!
Currently, I am writing some TCP/IP test cases with raw sockets and your analysis help me a lot to figure out the concept. Thanks for the simplified explanations and good quality videos!
Doing my best to keep the content relevant and interesting. Thank you!
Amazing video again, thanks for putting these out!
Glad you like them!
@@ChrisGreer TCP analysis is deceptively hard, I found. Even something seemingly simple like ACK numbers can throw you for a loop. At least, that the case for me.
10 out of 10 rating from me. Best explanation ever.
Thank you for this great video! Made it so much easier to understand this topic, which felt really confusing to me at first as newcomer in the field.
Very useful information for troubleshooting
Glad it was helpful!
Hay Chris, awesome vids man ! pls keep em comming, dont stop !!!! PCAP of performance / drop issues are a nightmare to troubleshoot but you make it soo easy!!!!
Thank you!
Great stuff Chris, Thank you for your time and energy.
Glad you enjoyed it
Thanks Chris for all your teachings. Love from India!!
My pleasure! Thanks for the shout out from India.
Thanks Chris! enjoying your videos like a beautiful movie..
Thanks Chris.
I recently came across this series and I am glad for that. Its very helpful to dive into the packet analysis dark world 🌎 !!!
Thanks for the comment!
Excellent how you break down through thye details!!! Thanks a million man
Glad it was helpful!
Thanks man, appreciate your work.
Greetings from Manchester.
Great explanation sir
Thank you, Chris. This was very helpful. Your explanation and walk through made it so much easier.
Thanks Chris!!! I am getting know TCP better!
Great to hear!
You are always awesome when explaining difficult topics to make understand easily ... Great mentor ....Keep rocking ...
Thank you for the comment!
Thanks Chris to spread this important knowledge..
Thank you for the comment!
Awesome explanation !! Thank you so much
You are welcome!
Hi Chris can as i m preparing my CCNA it s just in time thx
Go get it! You'll pass. Keep up that study and you'll be all good.
This is great information Chris! I've learned so much watching your videos. Thanks very much!
My pleasure!
Great teaching skills Chris, really really great
Thanks Peter! I appreciate the feedback.
Chris, amazing video. Thanks a lot! The only concern is that the screen is not very clear. Its a blurred view.
Hi Chris thank you for this fantastic analysis again
I dont know if my understanding is correct but i think that Since the server sends the packets #14-17 out of orders that were acknowledged by packets #18-20
Maybe The Packet #22 is a response to the packet #9 when the client asked for the gap and since this packet was already sent (the server flaged it with Superious Transmission).
Thank you for all you videos , value contents in the video.
Glad you like them!
🔥 🔥 🔥. You are the Truth my guy…
Incredible teaching. Thanks so much
Thanks for the comment. Very happy to hear it helped.
Thanks for the videos.. Learning a lot with these..
Glad to hear it!
Amazing! Thanks for sharing
Chris thank you for crystal clear informations. I am wondering, if videos have sequence numbers, would it be better?
Good suggestion... I will see if I can sort that out.
I am a student and your videos are very helpful to me :)
Glad to hear that!
In the first packet (the first SYN), there is an TCP options, the MSS with a value of 1460 bytes.
But each TCP packet has a Window size that is greater than the MSS for example 8192 bytes.
I'm telling my link partner I can receive 8192 bytes at once but my MSS is smaller.
Can you explain this point please?
Hello Yunus - that is a great question. So if you tell me your holding tank is 8192, I can't send you 8192 in one packet because our other buddies along the way will get upset (IP MTU and Link level MTU - usually 1500ish). So I have to cut this baby up into smaller chunks (1460) giving room for the TCP and IP headers before we bump our heads on the MTU. So 8192 will turn into five 1460 byte segments, with a last one of 892 (which will probably have the PSH bit set).
It's almost like - let's go get a pizza Yunus. I can eat four slices (all my stomach can handle - 8192) but please put only one on my plate at a time because the plates are so small! Hope that helps.
Sir! Can I use hamming code in wireshark for detecting errors ?
I never have. TCP wouldn't but perhaps at the file level?
@@ChrisGreer Good day Sir! Thanks for replying sir, Means a lot! Yes sir at the file level only, like if any bits changes means how to detect that using hamming code sir ? Actually I am doing project in *tracer & packet capturing using wireshark* when I searching for wireshark videos, I saw yours ( which contains what I need), but I didn't find the solution for my project on how to use hamming in wireshark sir! So I thought to ask you sir!
Great video but you better to show the flow of sequences with UML diagram. You can do visually any scenario there, which clears things up.
Awesome stuff!
This was fantastic!
Thanks for watching!
How likely the packet is not showing up in wireshark due to tcpdump or packet sniffer is not able to capture all the packets. I normally use the ip packet IP to identify gaps in my cpap. Not sure how accurate it is. Any recommendations?
any analysis on sftp..ftp tftp ..etc
Good one ..will wait for the video where you show us non relative seq number important and use case
Great suggestion. Short answer? I use non-relative when I'm in a dual side capture analysis scenario and I need to track a packet through a NAT or a Port Translation. Usually those boxes will leave the original raw seq alone.
So Chris thanks again for the video! Nice stuff! So maybe i didn't catch this while watching but what was the problem in this trace!!?
Thanks for the comment! So the issue was an MTU problem on the return path from the server. It was sending segments that were too large to fit under the MTU ceiling. From the pcaps we can determine that from the behavior, but we can't tell exactly which box was doing it.
Beeing 4 byte (32 bit) the max sequence number would be 4,294,967,295. Does it simply wrap around?
Hello Eirik, yes that is correct. Sequence number wrapping is what it is called. This is where the timestamps option can come in. If we are moving a ton of data, TCP can use the timestamp to prevent confusion about "which" sequence number it sees in the case of wrapping - a past one or a current one.
thank you, very high quality material! quick question - at minute 15:17 - how can You be sure that the server got the 4067 ack? You said that "just by looking at the packet flow we can say that it was indeed spurious". but as I see it, theoretically it's possible that the 4067 ack didn't make it to the server, don't You think?
It's most likely that the spurious retransmission was a result of the triple-double. There were three duplicate ACKS above it. The acks between, the ones you had mentioned, are fired off, and before the network roundtrip time (85mSec) we get the retransmitted data. Also, all symptoms indicate that there was packet loss of large MSS's in the direction from server back to client - not small packets (ACKS) from client to server. So it is pretty safe to assume that the server got those ACKs and was just reacting to the Triple double. This is another reason I really try to get trace files from both sides of the conversation so we can absolutely prove questions like you had. Thanks for the comment and hope that helps!
@@ChrisGreer that's very helpful, thanks so much!
Thanx for uploading 🙏
You are welcome!
Dear Chris, thank you for your wonderful videos. Just one question, what are some protocols/captures to look for when computers are freezing/hanging when connected to the LAN on the same switch, only one switch in the building with 20+ users.
Hmmm.... great question. I would look for connectivity kind of problems - ARPs, DNS Slow or No Response, TCP SYN Retransmissions, Resets, or maybe even unusual STP activity. That is where I would start at least!
Yooooo thanks man 🔥
One question: Where is the ACK for packet 9. I see the ACK for packet 10 but no for packet 9
Learning a lot! great!
Glad to hear that!
Can anyone help me I’m trying to play ps4 vanguard and I have to put a port forwarding but the TCP says : 1935, 3478-3480. What to I do with the 1935?? Where do I put that number ??? Please help
Hi Chris. thank you for this channel it really help me in my every day work. Just wondering if you can help. When I tried to upload a file in website I'm getting error. Where do I start looking in wireshark? thank you in advance.
Lots of ways you could go with that. Start with filtering on the conversations between client and server, then add in the protocol in use (is it HTTPS? SMB?) Then at the time the error flags look for resets, application hangs, or tcp delays. That is where I would start, but it is hard to say without more detail into the issue.
@@ChrisGreer cool.. thanks for giving direction where to start looking. I was able to resolved the issue... Kudos to you!
I was running wireshark on my Wifi and I observed that for the same source and destination it was sometimes using TCP and sometimes QUIC which is UDP based ? How is it possible ?
Right now since we are in an adoption process with QUIC, most sites support both. So you may see a TCP connection and a QUIC connection until the site goes all QUIC from the get-go. Even then, we'll probably still see TCP hanging around for some time over the web!
Please upload tutorial for SSL handshake, i almost tried all the websites but no one explained clearly.
Great idea, I am actually working on a TLS Handshake video!
@@ChrisGreer I'm Waiting... :)
Hey Chris,
I know you are the only one who can help me. I am running an iperf between two sites and the link is 1G.
When I run with linux I get 1G either way. As soon as I install windows on it, I get 150Mbps.
Not sure why am I experiencing this behavior, can share the PCAPs as well.
Hey - I saw your pcaps you sent over. You need to manually increase the window size on the iPerf test. It is only going to use 264KB as a congestion window by default. Use the -w switch and I would crank it up to 2,000,000 (2MB) in your case due to the latency.
@Chris Greer I tried and it end up in an error message "socket buffer is not set correctly".
2:18 every byte has a sequence number??????
Yup. RFC793 3.3 -A fundamental notion in the design is that every octet of data sent
over a TCP connection has a sequence number.
Thank you. 👍
You are welcome!
Given your knowledge of packets and protocols, do you ever play with tools like scapy to test things? I think learning to craft packets it's awesome way to learn, so if you ever upload something like that I will double-like it haha
Hey! I haven't used it yet but it is on my punch list since I'm digging much deeper into cybersecurity these days.
@@ChrisGreer awesome. love your content mate, I love cybersec and wireshark is a total must for it. Thanks for all the time you invest in this content.
Thank! 谢谢您！
You look like an American actor who did venom 2
Thanks! I think?
Video 2
I wonder if TikTokkers appreciates what happens when they send out their trash over the internet :D
!!!!!!
Learning a lot with you. Thank you so much
Happy to hear that!
Very good explanation.