Chris, you are just awesome! Do you have whole your courses available somewhere? Like you mentioned you run a few days classes. I am very keen to watch those recorded - something like what INE (and others) does.
Hello Alexander - very happy to hear that the videos are helping you. I have an on-demand training available on Udemy. TCP/IP Deep Dive with Wireshark - bit.ly/udemywireshark Check it out! It's got a ton of hands-on labs, assignments, and ways to practice on your own. I hope you like it.
I hope you know you're awesome !! The best thing is how you put 'air' into explanations and let the audience take notice of subtle things, ruminate, analyze and really understand. You have covered so many topics in this single session and made sure that everyone remembers/ retains 90% of those (I'm an app-guy and others would retain more than me). Amazing stuff !!
such a fantastic teacher and such insights into the TCP packets. I watched a 5 hour course on Wireshark from another teacher and watching this video I realized I am finally learning what the 3 way handshake is. This teacher should educate all network administrators and cyber security personnel.
Fantastic Chris! Your wait for the packet from layer 7 (1:12:00) was hilarious! You have actually inspired me to learn more on TCP. Thanks for the video.
You are one hell of a expert Sir! I learned what I could not understand even in my years of networking career and in college degree. Thanks very much, appreciated!!!!!!
Superb explanation ! Thank You Chris. As a TAC Escalation engineer I find this very useful. Will help a lot of folks who want to understand how TCP works.
oh gosh this is wonderful. clear out many things. working in ISP receiving client complaints how their replication cant be done cause they cant see full throughput. i wish i can send them this video to learn how network work and before blaming their ISP they need to check wats going on with their application.
Im not a native english and im not even so good in english but all these hard stuff with your teaching style, is so understandable. Thanks and i wish best for you.
great question! 128 means that the packet is unrouted. Once that SYN goes through the first router, the router would have decremented the TTL by 1. It would be 127, then 126, 125... Since clients almost always are the ones initiating connections to servers, we can be pretty safe to conclude that if we see an unrouted packet on a SYN, that we are capturing client-side (unless we are in a data center, etc...).
Thank you for that explanation (and the quick response - I figured I'd give it a day, so this was a welcome surprise)! What do you mean when you say "unless we are in a data center?"
@@PriestApostate No worries! It was a great question. In a data center, we would see servers communicating to other servers. So a web front-end, after receiving a request from a client, might turn around an initiate a connection to an app server or perhaps a database (unless that connection was already established). In that case the server would become the client to the other server and be the one initiating the SYN. We would only capture that however if we were sitting in the data center where the servers are communicating, or if we were capturing in the cloud environment. Hope that helps!
Hi Chris, great intro into TCP, I'll recommend it to anyone who asks me about TCP beginner talks ;-) But I think there's a small error at 1:01:17 - missing SACK options does not mean there are no fast retransmissions possible. The triple dup ack mechanism works without SACK, but it may lead to full retransmits from the gap. There are three flavors of retransmissions: time out based, fast retransmission triggered by triple duplicate ack, and SACK (which in turn doesn't even need a triple duplicate ack to signal loss)
Thanks for the comment Jasper - I hadn't seen a stack not have the option but still do fast retrans yet. But hey if it's out there I want to be correct about it!
this was a brilliant hands-on example Chris. In additional to clearly explain how TCP works and why handshakes are always so important, you have humoursly also explained why application guys and network guys keep bickering over latency issues. I am from application team and this video has enhanced my troubleshooting skills. Thank you so much for posting this!
Excellently explained, I know nothing about this but after 1h17mins I can start to see a little of what it’s all about looking forward to the rest of the series
Chris Super explanation of TCP. More window Size to you..... I have seen lot of videos for tcp but this one contains all of it most the part i would recommend everyone to watch this video instead of shuffling through the youtube bits and bytes of other tcp video
I guess you don't know how Noble work you are doing .... I really appreciate the effort you put in to learn weeds of TCP and importantly sharing your knowledge..... God Bless .Keep going
First I thought "Over an hour, that's long...". Now I think "Could have been longer!!!" :-) :-) :-) Awesome presentation. Motivates to dig in! Many thanks!!! :-)
Your courses on plural sight are the best. I've done other tutors' courses on plural sight and linked in learning which left me a bit confused since they hit the surface without much explanation. I just finished your "foundational TCP analysis with wireshark" course which is clear and the orderly step by step layout makes it easy to understand. Great job👌👌
Thank you Chris for this video, you're a great teacher. Your explanation of waiting on Layer 7 traffic to fall down to Layer 4 on the server side was hilarious. 😂
@1:10:54 you said after http get from client . server sent ACK only acknwldg previous sent data but not sending any other data, that is perfectly fine. But i have one doubt. you said if that ack is not received to client then it will re-transmit. i think client will not re-transmit. TCP-keep alive message should go in that case.
Im in the first few hours of learning to how to become a pen tester. If im honsest, this tcp thing looks relatively easy. I'm mostly worried about the command's i have to remember. A whole new language. Including phyton. But this is super interesting. Do you have tips and tricks, I've get what ipv4/ipv6, subnetting what a /20 a /24 network is. And how and why it's different, and what routing is, what a gre and ipsec tunnels is. What an handshake is, and what the window sizes and the multiplier is, The package size. I'm curious how to continue. Looking forward to learn way more about networking, testing kali, linux, understanding and writing code, discovering that I don't understand anything of this. And learning to understand. Love this journey so far... Thank you for this video and the collaborations you did with david bombal, and many others... Cheers!
Hi Chris, thanks foe the nice and informative video, watched it couple of times and using it as a reference. I have a question which I couldn't find any answer for that. What does "windows scaling factor -1 [unknown] means and is it a problem ? Thanks in advance.
54:00 I dont get the difference between MTU size and Window Size. Window size value is 64240 (bits? bytes? what?) and MTU 1460 Bytes I mean, if the MTU size is 1460 how the window size could be bigger? there is something that I'm not getting... thanks in advance
@Chris you are amazing man! from your body language I feel you dive inside the wire a swift through these packet! I love it. quick question, minute 48:53 can you please show me the math behind how TTL 111 translate to 17 routers (n00be asking)
Thanks for the feedback! Yeah so most devices start with IP TTL's of 64, 128, or 255. So when I see 111, it likely started at 128 and traveled through 17 routing devices along its way to me.
@Chris i have one quick question what is idle or best time format setting you suggested or best to use in packet analysis. since beginning or capture or previous capture or displayed options. can you please give a detailed analysis on this
Hi Chris!! Excelent explanation!! I'm super noob in this sftuffs but i can learn many tips! I like your way to explain teacher 😆😆 very funny!! Pd: Sorry about mi poor english! Regards from Argentina 😉👏
Hi Chris, nowadays i am watching lot of videos on wireshark. but your approach of understanding is unique. I really appreciate if you could please assist me on below. I was reported issue, where application team was facing duplicate transaction issue. and i was contacted to see if network is causing any issue. 4 servers are involved in this and i have taken wireshark capture on all 4 servers. but it is using SSL protocol which is encrypted. so as per my thinking i think we cannot come to know if duplication is happening by looking to TCP\IP packet only. could you please suggest me if it is possible.
I entitle my delta column with a Δ . Like the greek delta Δ. Yay unicode! But if that's too uppercase for you then δ also will work. I just figured out in the midst of a 35 hour long packathon of looking at frames, with my vision going blurry and my mind actually starting to think Cisco is a real company I'll be able to make out Δ and what it stands for a little easier.
[placeholder for screenshot URL that is coming up] About half an hour later I came up with a much better approach it seems. Just take the nerd fonts I already use for powerline, airline, sofaline, toiletline, lineline and use some of its extra icons and then install it as a font in Wireshakr. The delta is just much crispier. Oh and while I was at it I pulled a clock and replace time title with that too. I am currently brainstorming with chatgpt as to how source and destination can be represented by the icons. Otherwise great conversation, dude! I'm a red teamer and the way you talk about TCP signifies that you have such extreme levels of expertise that you are like fluent in it. I'm probably gonna pull out my fountain pen anda take some notes tbh ans so far that's only been reserved for MIT OpenCourseWare stuff (like csail from original HP recording). I just learned more about TCP in three bours binge-watching your videos than in the last like 10 years I think.
what is the relation between window size and mss? i.e. if we have a window size of 65535 and a capacity of 1460mss, does it mean we can receive almost 45 tcp segments with 1460 bytes in payload each in a row?
@@ChrisGreer Thank you for the response. But I am wondering will router do a layer 4 lookup for a transit traffic and rewrite the TCP header fields as it is just supposed to do a destination IP lookup ?
@@453nabeel Yes sir! of course. I do have more training - remote, onsite, or on-demand. If you are interested in more please shoot me an email at packetpioneer@gmail.com or contact me through my website - www.packetpioneer.com. I'm happy to work with you to help you meet your Wireshark goals.
Hey Chris, great video. In your last case study a router diminished the MMS which caused latency on the network. To realize that you did a scan on the server side. Is there a way to spot this kind of problems when you only got a client scan?
Hello Xtra999. In this case, not really - I needed to see how the SYN was leaving the server and how it was arriving at the client. I suppose you could infer that it was an MSS problem by the TCP behavior, but that is something you probably would need experience in looking for. Thanks for the comment.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Chris, you are just awesome! Do you have whole your courses available somewhere? Like you mentioned you run a few days classes. I am very keen to watch those recorded - something like what INE (and others) does.
Hello Alexander - very happy to hear that the videos are helping you. I have an on-demand training available on Udemy. TCP/IP Deep Dive with Wireshark - bit.ly/udemywireshark Check it out! It's got a ton of hands-on labs, assignments, and ways to practice on your own. I hope you like it.
He repeats the questions! Good form sir, good form.
I keep coming back to this video from time to time and I always find something that I missed the last time. Thank you, Chris.
Thanks for the comment Yash! I'm glad to hear that the video is helping you. Stay tuned on my Intro to Wireshark course for more TCP stuff.
Whole world need trainers and teachers like you. You are awesome
I hope you know you're awesome !! The best thing is how you put 'air' into explanations and let the audience take notice of subtle things, ruminate, analyze and really understand. You have covered so many topics in this single session and made sure that everyone remembers/ retains 90% of those (I'm an app-guy and others would retain more than me). Amazing stuff !!
thanks for the comment Partha! I appreciate it. Make sure to check out my new Wireshark Masterclass too - ruclips.net/video/OU-A2EmVrKQ/видео.html
@@ChrisGreer Thanks for that link. I wouldn't miss it for anything.
such a fantastic teacher and such insights into the TCP packets. I watched a 5 hour course on Wireshark from another teacher and watching this video I realized I am finally learning what the 3 way handshake is. This teacher should educate all network administrators and cyber security personnel.
Thanks for the comment! Glad the video helped.
Stellar public speaking and instruction. Glad I found this channel.
Glad you found it!
Why is that only 1.5K likes for this video. It should be in Millions!! ...and he repeats the questions clearly to answer..
Thanks for the comment Arun!
Fantastic Chris!
Your wait for the packet from layer 7 (1:12:00) was hilarious!
You have actually inspired me to learn more on TCP.
Thanks for the video.
You are one hell of a expert Sir!
I learned what I could not understand even in my years of networking career and in college degree.
Thanks very much, appreciated!!!!!!
Superb explanation !
Thank You Chris.
As a TAC Escalation engineer I find this very useful. Will help a lot of folks who want to understand how TCP works.
This was SUCH a good video! I think your teaching style is excellent. Thank you for making this available.
Thank you for the comment Tristan!
I feel as if I hit the motherlode of TCP and Wireshark knowledge with this presentation. Thanks, Chris!
James Boelter thanks for the comment!
Stopped and liked the video because it has been one of the best and informative video of how TCP works in Wireshark.
Thanks for the comment and for watching Manuel! Glad it helped you. Hope you like the rest of the content on the channel too.
What awesome video, 10 years as network guy and now I'll make sure that I'll understand TCP, Thanks @ChrisGreer
Best to your TCP journey!
oh gosh this is wonderful. clear out many things. working in ISP receiving client complaints how their replication cant be done cause they cant see full throughput. i wish i can send them this video to learn how network work and before blaming their ISP they need to check wats going on with their application.
Great to hear you enjoyed the video! Yes please send it to whoever may benefit. Yeah I bet you get blamed for quite a bit that is not your fault!
Why is that only this much likes and comments for this video.
It should be in Millions/Billion.
Lots of Love from India....Ur awesome!😍
Im not a native english and im not even so good in english but all these hard stuff with your teaching style, is so understandable. Thanks and i wish best for you.
Thank you!
David Bombal just sent me here. I thought I knew TCP/IP, apparently nope. Good content Chris.
Awesome Andy! Great to have you on the channel. Thank you for stopping by.
I have learned so much from this video in just one hour. 'Explain me like I'm five' at its best. Thank you so much.
That is how I have to learn everything - like I am five! 😜
45:30 - 128 on a SYN means that it is in the client side...what made you reach that conclusion (newbie asking)?
great question! 128 means that the packet is unrouted. Once that SYN goes through the first router, the router would have decremented the TTL by 1. It would be 127, then 126, 125...
Since clients almost always are the ones initiating connections to servers, we can be pretty safe to conclude that if we see an unrouted packet on a SYN, that we are capturing client-side (unless we are in a data center, etc...).
Thank you for that explanation (and the quick response - I figured I'd give it a day, so this was a welcome surprise)!
What do you mean when you say "unless we are in a data center?"
@@PriestApostate No worries! It was a great question. In a data center, we would see servers communicating to other servers. So a web front-end, after receiving a request from a client, might turn around an initiate a connection to an app server or perhaps a database (unless that connection was already established). In that case the server would become the client to the other server and be the one initiating the SYN. We would only capture that however if we were sitting in the data center where the servers are communicating, or if we were capturing in the cloud environment.
Hope that helps!
Hats off Chris.. Thanks lot for this wonderful presentation.
Hi Chris, great intro into TCP, I'll recommend it to anyone who asks me about TCP beginner talks ;-)
But I think there's a small error at 1:01:17 - missing SACK options does not mean there are no fast retransmissions possible. The triple dup ack mechanism works without SACK, but it may lead to full retransmits from the gap. There are three flavors of retransmissions: time out based, fast retransmission triggered by triple duplicate ack, and SACK (which in turn doesn't even need a triple duplicate ack to signal loss)
Thanks for the comment Jasper - I hadn't seen a stack not have the option but still do fast retrans yet. But hey if it's out there I want to be correct about it!
Nice presentation,I like the way your are explaining things in a simple way & Very informative video.Thank you so much
Chris, I have learned a lot from you in this video that I have not learned in last 10 years. thanks
Great, Thanks for sharing Chris... Love your enthusiasm, and the your joy of teaching the subject. Good Job!
Thanks for the comment Michael!
this was a brilliant hands-on example Chris. In additional to clearly explain how TCP works and why handshakes are always so important, you have humoursly also explained why application guys and network guys keep bickering over latency issues. I am from application team and this video has enhanced my troubleshooting skills. Thank you so much for posting this!
Thanks for the comment! I really appreciate the feedback.
Excellently explained, I know nothing about this but after 1h17mins I can start to see a little of what it’s all about looking forward to the rest of the series
Chris Super explanation of TCP. More window Size to you..... I have seen lot of videos for tcp but this one contains all of it most the part i would recommend everyone to watch this video instead of shuffling through the youtube bits and bytes of other tcp video
I guess you don't know how Noble work you are doing .... I really appreciate the effort you put in to learn weeds of TCP and importantly sharing your knowledge..... God Bless .Keep going
Thank you so much for the comment. I appreciate it!
Typical great presentation from Chris. The guy is a consummate professional.
First I thought "Over an hour, that's long...". Now I think "Could have been longer!!!" :-) :-) :-) Awesome presentation. Motivates to dig in! Many thanks!!! :-)
Thanks for the comment Francisco! I appreciate it.
Your courses on plural sight are the best. I've done other tutors' courses on plural sight and linked in learning which left me a bit confused since they hit the surface without much explanation. I just finished your "foundational TCP analysis with wireshark" course which is clear and the orderly step by step layout makes it easy to understand. Great job👌👌
Thank you so much for taking the time to comment and give feedback. I really appreciate it.
Can't go to next video, without liking it; Good video Chris, thanks for this basic TCP stuff; lets jump to your next session. Thank you.
Hi Chris - Thank you for such an awesome video. Informative, Easy to understand and remember.
Thank you for the kind feedback Vishal!
This material should be required for every new engineer coming into the field
Very knowledgeable..Appreciate in sharing the knowledge
Glad you like it!
Bravo .. buddy you nailed it ... content to your style of explaining.. loved it all..... :)
Thanks for the comment Sandeep! Glad the video helps.
Excellent method of teaching
Thank you for the comment!
I love this video, I wish I had it during my Computer and Network Security course last semester. Thanks for sharing.
Thanks so much Chris for sharing your expertise.
Glad it was helpful!
Man Chris, you just nail it with expressions, easier to remember, thanks a lot!
Thanks for the comment!
Fantastic teacher awesome session. Thanks.
Thank you!
Terrific presentation! Very insightful
Thank you Chris for this video, you're a great teacher. Your explanation of waiting on Layer 7 traffic to fall down to Layer 4 on the server side was hilarious. 😂
Thank you! I'm really glad you liked it! Please feel free to share...
Super explanation. Thank you Chris!
Glad it was helpful! Thank you!
You inspired me to learn more in depth TCP/IP
How can someone not love this guy!
@1:10:54 you said after http get from client . server sent ACK only acknwldg previous sent data but not sending any other data, that is perfectly fine. But i have one doubt. you said if that ack is not received to client then it will re-transmit. i think client will not re-transmit. TCP-keep alive message should go in that case.
What a great speaker!
What a lecture! Simply Amazing
Thanks for the good vibes!
Very good video.
Thanx Mr Chris.
extremely helpful videos, love your passion for packets!
Glad you like them!
Chris, eres el mejor. Apenas empiezo y entendí !!! gracias
Im in the first few hours of learning to how to become a pen tester. If im honsest, this tcp thing looks relatively easy. I'm mostly worried about the command's i have to remember. A whole new language. Including phyton. But this is super interesting. Do you have tips and tricks, I've get what ipv4/ipv6, subnetting what a /20 a /24 network is. And how and why it's different, and what routing is, what a gre and ipsec tunnels is. What an handshake is, and what the window sizes and the multiplier is, The package size. I'm curious how to continue. Looking forward to learn way more about networking, testing kali, linux, understanding and writing code, discovering that I don't understand anything of this. And learning to understand. Love this journey so far... Thank you for this video and the collaborations you did with david bombal, and many others... Cheers!
Very good explanation Sir
Thanks Parvesh! I appreciate the comment.
Absolutely fantastic explanation. Thank you!
Thanks for such helpful videos. You are awesome!
Hi Chris, thanks foe the nice and informative video, watched it couple of times and using it as a reference.
I have a question which I couldn't find any answer for that.
What does "windows scaling factor -1 [unknown] means and is it a problem ?
Thanks in advance.
Chris, fantastic presentation . I really learned a lot .
Glad it was helpful!
This is one of the best talks on networking I've seen.
If you have part 2 available, it would be awesome to see it.
Thank you for sharing.
Thank you for the comment Pablo - I will post round two soon!
This presentation is awesome. I wished you could teach me that in my class lecture
Impressive style & content. Thanks so much for sharing this
thanks chris... well explained ....
Glad it was helpful!
Awesome Chris, can you do a modbus analysis? It would be great
Just bought your Udemy course Chris. Would you recommend for a network engineer to try work through that Stevens book TCP/IP Illustrated vol 1? Thanks
Great speech! Enjoyable even for a begineer like me
Chris. Thank You for this.
My pleasure!
Brilliant video. Please post the next part as well.
54:00
I dont get the difference between MTU size and Window Size.
Window size value is 64240 (bits? bytes? what?)
and MTU 1460 Bytes
I mean, if the MTU size is 1460 how the window size could be bigger? there is something that I'm not getting... thanks in advance
@Chris you are amazing man! from your body language I feel you dive inside the wire a swift through these packet! I love it. quick question, minute 48:53 can you please show me the math behind how TTL 111 translate to 17 routers (n00be asking)
ahhh 128 -111
Thanks for the feedback! Yeah so most devices start with IP TTL's of 64, 128, or 255. So when I see 111, it likely started at 128 and traveled through 17 routing devices along its way to me.
@Chris i have one quick question what is idle or best time format setting you suggested or best to use in packet analysis. since beginning or capture or previous capture or displayed options. can you please give a detailed analysis on this
This is a great question - I will shoot a video to cover it.
@@ChrisGreer 🙏 thank you my friend .you are amazing person..,
@@ChrisGreer please touch how to switch between local timezone to UTC or other in that video too
This is fantastic stuff. Very helpful. Thank you!
It was an incredible session Chris, thank you for the great explanations and good humour.
Glad you enjoyed it!
Hi Chris!! Excelent explanation!! I'm super noob in this sftuffs but i can learn many tips! I like your way to explain teacher 😆😆 very funny!!
Pd: Sorry about mi poor english!
Regards from Argentina 😉👏
I'm glad you liked it!
He is Very good instructor !!!
Thanks for the comment @imran! Glad it helped you.
@@ChrisGreer clarity in explaning concept was too good. Have a great day !!
Chris could you explain the difficulties of on-board airline WiFi? What is 802.11ac at 700mph?
Thanks for the help.
Hi Chris, Very informative video on TCP. Learned a lot. Thank you very much.
Great Samir, Thanks for watching and for the comment. I'll post round 2 soon.
Nice. Also, dropping a link to pcaps you're using so we can follow by step-to-step in a video description would've been super cool.
Chris you are awesome. Can you please upload the packet capture?
Superb video
_Are the packing peanuts for the structure and throughput?_
you nailed it. Is there any book that can team me more about the TCP ? ( I am going to have a look at the RFC) Thank you again.
I really like TCP/IP Illustrated by Fall/Stevens.
I found the it and I am going through it. Thank you Chris.
Thanks a lot for informative & detailed session.
really nice conference! very helpful
Glad it was helpful!
Hi Chris,
nowadays i am watching lot of videos on wireshark. but your approach of understanding is unique. I really appreciate if you could please assist me on below.
I was reported issue, where application team was facing duplicate transaction issue. and i was contacted to see if network is causing any issue. 4 servers are involved in this and i have taken wireshark capture on all 4 servers. but it is using SSL protocol which is encrypted. so as per my thinking i think we cannot come to know if duplication is happening by looking to TCP\IP packet only. could you please suggest me if it is possible.
That's some real good stuff. Thanks for sharing!
I entitle my delta column with a Δ . Like the greek delta Δ. Yay unicode!
But if that's too uppercase for you then δ also will work. I just figured out in the midst of a 35 hour long packathon of looking at frames, with my vision going blurry and my mind actually starting to think Cisco is a real company I'll be able to make out Δ and what it stands for a little easier.
[placeholder for screenshot URL that is coming up]
About half an hour later I came up with a much better approach it seems. Just take the nerd fonts I already use for powerline, airline, sofaline, toiletline, lineline and use some of its extra icons and then install it as a font in Wireshakr. The delta is just much crispier. Oh and while I was at it I pulled a clock and replace time title with that too. I am currently brainstorming with chatgpt as to how source and destination can be represented by the icons.
Otherwise great conversation, dude! I'm a red teamer and the way you talk about TCP signifies that you have such extreme levels of expertise that you are like fluent in it. I'm probably gonna pull out my fountain pen anda take some notes tbh ans so far that's only been reserved for MIT OpenCourseWare stuff (like csail from original HP recording).
I just learned more about TCP in three bours binge-watching your videos than in the last like 10 years I think.
what is the relation between window size and mss? i.e. if we have a window size of 65535 and a capacity of 1460mss, does it mean we can receive almost 45 tcp segments with 1460 bytes in payload each in a row?
It starts at 3:58 if you don't want to listen to the introduction
THANK YOU
Also nice merch, had to get me a shirt.
Is TCP good for people looking to get into security jobs?
YES!! I actually want to put out a TCP Analysis for Cyber Security Professionals. Would that help you?
@@ChrisGreer please have you put out the analysis for cyber security professionals, if you have kindly drop the link here
Hi @chris, Can router change the MSS in between ?
Yes! Look into MSS clamping.
@@ChrisGreer Thank you for the response. But I am wondering will router do a layer 4 lookup for a transit traffic and rewrite the TCP header fields as it is just supposed to do a destination IP lookup ?
Amazing Chris. This is brilliant. Really Geek stuff
Thanks Nabeel - I try by best to geek-out but still not be boring!
@@ChrisGreer Sir is it possible we could have more from you about traces , case studies etc. Do u have any training course ?
@@453nabeel Yes sir! of course. I do have more training - remote, onsite, or on-demand. If you are interested in more please shoot me an email at packetpioneer@gmail.com or contact me through my website - www.packetpioneer.com. I'm happy to work with you to help you meet your Wireshark goals.
Good stuff. Thanks
Glad you enjoyed it!
excellent presentation!
06:53 | 17:55 TCP Handshake
Hey Chris, great video. In your last case study a router diminished the MMS which caused latency on the network. To realize that you did a scan on the server side. Is there a way to spot this kind of problems when you only got a client scan?
Hello Xtra999. In this case, not really - I needed to see how the SYN was leaving the server and how it was arriving at the client. I suppose you could infer that it was an MSS problem by the TCP behavior, but that is something you probably would need experience in looking for. Thanks for the comment.
I cannot thank you more!