Introduction to Wireshark

[Music] so [Music] good morning afternoon wherever you happen to me i happen to be my name is mike panocki owner of network protocol specialist llc here in seattle washington and today we are going to be talking about wireshark i've been doing these sessions i want to talk about a variety of different technologies i work with everything from the physical layer all the way up to the application layer troubleshooting problems and i want to introduce you to some technologies clear up some myths things like that so whether you're joining me on facebook linkedin or youtube uh i've got the comments section up here so if you have any questions as we're going along please feel free to throw them in the comment section and i will do my best to get an answer to all of those or as many as i can so what we're going to do is we are going to go through some of the tips and tricks in capturing with wireshark maybe you've been using it for a while maybe you just started or you are curious about it so i'd like to go through a few things that i've learned over the decades that i've been capturing packets just to date myself i started capturing packets back in probably about 1993 on a banyan vines network using a network general sniffer so things have changed a lot since then and fortunately there's free programs out there like wireshark that allow us to get in there and see what's going on now is packet analysis the solution for everything no there's a time where i probably felt like it was but honestly there are times where there's other tools out there snmp ping trace route that are going to help get us close to what's going on but what i found is on those really difficult problems especially those problems that deal with application performance problem issues doing packet capture and analysis is a great way to go so what we're going to do is we've got a few different topics we're going to talk about and the first topic that we are going to talk about in here is getting in the path of the packets because honestly until we get in the path of the packets and we can capture the correct packets it doesn't mean anything as far as the trace that we're looking at i have gotten sent traces over the years where people have done a capture about the time the problem happened and it turned out that they just didn't have the right packets so we're going to talk about a few different ways that we can get in the path of the packets now one of the easiest ways is just to install wireshark on the machine that's having the problem and do the capture there we're going to get to that in just a little bit but sometimes we need to capture the packets as they're going across the network now what do we know about an ethernet switch well an ethernet switch has a bridge forwarding table in it that directs packets to the proper destination so that means that if i plug my laptop into a switch port and there's a conversation going on between two other switchboards i'm not going to see it i need to inject myself into the path of those packets so we're going to come over here we're going to take a look at a few different ways that we can get in the path of those packets so we're going to start out by switching over here let me clear a couple things off here before i switch over there so let's switch over here and here is about the simplest setup that i've got and that is that right here we have our network our netgear gs105e switch now i've got a nice little video out on youtube that talks about this switch and how to turn on port mirroring on it so what i've done with these is i wanted to find out the cheapest switch that would support port mirroring and set that up so i could use this to get in the path of the packets so in this case what i've done is i've taken this netgear gs105e and if you search youtube for netgear gs105e you're going to find that video it's going to show up as one of the top ones and i'll even put in the comment here tell you what i'm going to put in the comment right there there is we'll send that out um that is the link to the youtube video on how to turn this into a tap into a a device we can use to help us capture packets so what i've done is i've set this up so it's mirroring the traffic from port one over here to port four so i've got my laptop the laptop that i'm using to do this broadcast plugged into port 1. i've got my analyzer plugged into port 4. port 5 is connected to the rest of my network so now i've put myself in the path of those packets so this allows me to come in here and start capturing all the packets that are going between these two ports right there so for about 35 dollars i can go in and i can set up a little device like that to get the path of the packets now what's the downside of a device like this if i came in here and i pulled this power cord right there we would lose this stream why because this will not forward packets if we kill the power to it so that's where we need to ask ourselves when we're going in and doing packet capture am i willing to put something like this in the middle of my network and if i lose power i'm going to take down that network so this is where we start getting into some other devices for capturing packets now if you have a managed switch you can certainly go in and set up a mirror port on that managed switch you can tell the switch to take the traffic going in and out of one port and copy it over to another port that's a really easy way to go do that there's some downsides to that you can lose packets especially if you try and span too much traffic uh your timing can get thrown off so let me just show you a few other devices that we have back here and the first one is an inline fault tolerant tap so in this case with this inline we'll push that out of the way right now with our inline fault tolerant tap what this does is we can put this in line with the network and we can connect it to our analyzer this allows us to go in capture the packet or get the packets and forward them over and if we kill the power to this this will recover in about 26 nanoseconds so this provides a means first to get in the path of the packets without damaging or causing problems on the network now another option is something like this this is a fiber tap so this does an optical split on the light so we pass the network through these two ports and the traffic going in and out of ports a and b are sent out these two fiber ports right there so this is another way that we can go in and monitor traffic out there using a tap so getting in the path of the packets becomes critical now i'm going to flip over here and here is where we really step things up so this is a product called the booster from profittap and what this does is i have this tapped into four one gig connections including my internet connection it aggregates all that traffic into a single 10 gig connection and sends it up over here to this iota now the iota is the device i'm using to do the captures so what we can do is we can go in and use that to tap into a number of connections and capture that as well now somebody brought up a question uh can we capture wi-fi traffic wi-fi is tricky because with wi-fi we have to be able to get down into the drivers and be able to capture the packets so i have found the greatest success in doing wi-fi traffic capture is by using a device that's specifically designed for that we can also use wireless access points in many cases so probably the cheapest and easiest way to do a wireless packet capture is to look to see if the access point you're using supports wireless capture so i was doing some troubleshooting on a meraki network we were able to use the merakis to do the capture uh we can [Music] use i you know i've i use a lot of micro tick routers i can use those for doing capture over my shoulders we've got some equipment from net ally and one of those is the aircheck g2 now the aircheck g2 is designed to do 802.11 ac and below wireless backup capture now somebody else brought up monitor the port of the ap great response and why i like that response is because when we get into capturing wireless traffic we have to decode that traffic so there's times where we want to be able to see the contents of the packets and if you're using something like wpa2 personal we can put in the pre-shared key and we can decode that traffic if we capture the beginning of the conversation we have to capture that four-way handshake between the client and the ap if you're using something like wpa2 enterprise we're not going to be able to decrypt that traffic so if we just want to look at the wi-fi communications we can capture on the wired side but i'll tell you honestly it's easiest to capture on the access point the wired side of the access point and see the traffic there all right so we're going to be talking about wireshark so let's dig into wireshark and let's take a look at a few things on there so what we're going to do next is we're going to take a look at a wireshark overview so you can go out to wireshark and download it now what i'm going to do is i'm going to come in here and share my screen now i'm running wireshark on a macbook now when we're running it on a mac we have to run wireshark as root so that we can see the interfaces on it if you're running it on windows you're not going to have the same problem so in this case what i'm going to do is i will come in here and we'll just grab this window right here and i'm going to go ahead and i'm going to start wireshark as root i'll type in my password and that's going to fire up wireshark so here we go so let's go ahead you don't necessarily need to see me for this part so let's go ahead and have that take up the whole screen right there so when we first log into wireshark here's what we see right here we see our various interfaces that we have available to us so in this case i've got my usb 10100 1000 interface that is the one i'm most interested in now if i don't capture using root i won't see that interface so let's just go ahead and start capturing some packets so i'm going to double click on that interface and here we go we see that we've got packets going across so i'm going to stop this now one of the things that oftentimes happens when we first start with wireshark is we get a lot of information and we may or may not know what we're looking at so let's talk about a couple of things that we can do to make wireshark easier to use the first one is not trying to remember every single ip address there is out there so if i'm out here and i'm trying to remember you know this device goes with this ip address and this device goes with that ip address that can be troublesome so let's do this we're going to come over here and i'm going to go up to view and i'm going to go into name resolution now by default wireshark turns off network layer name resolution why does it do that because to do this it's got to send dns pointer record queries and if we're capturing a lot of packets with a lot of ip addresses this can create a lot of traffic at the time we're doing our packet capture so by default this is turned off so one of the first things i like to do is i like to come in and turn that on so i'm going to turn on resolve network addresses now what's going to happen and we can say we're going to see that it is going to start putting in some names to go with those ip addresses so in this case i can start seeing some dns names that go in here now there has to be a pointer record out there for that device for it to be able to resolve that name the next thing i can do is over here where i see 10.0.0.11.122 that's my pc so do i always want to remember that's my pc no so what i can do is i can right click and i can say edit resolve name now up here at the top of the screen and my logo let's get rid of that for right now we'll turn off that logo for a moment so it doesn't hide anything over there but what i can do is right up here at the top it says address 10.0.11.122 i can give it a name mike macbook i'll hit ok so now it puts mike macbook in there so anytime i'm looking at my trace now it's going to show that 10.0.11 is my macbook that makes it easier to follow along and see what's happening in the trace now the other one that i change right off the bat and in fact let's do this let's see if we can i don't want to do it on that screen i want this screen i'm going to make the font a little bit bigger here so that you can see it i want to make sure you can see everything okay let's change our column widths but over here what we've got is in our time column by default with my time column it is showing the time since the beginning of the trace so honestly i could care less about the time from the beginning of the trace anytime i'm in there troubleshooting problems i care about the time between packets because nobody has ever called and said that an application is running too fast they always call and say the application is running too slow so what do we do well we come in and we change our time so i'm going to come up here and go to view and i'm going to go to time display format and i'm going to go to seconds since previous displayed packet so now it's showing me the gap between each of the packets so i can use this gap to start getting an idea of what's going on on the network so now we've come in and we've started setting up the display we're getting the display so that it is working for us so we can see exactly what it is that we're looking for now the next piece in here is i want to come in and start setting up some capture filters now i know you want to capture everything you want to capture it all and it's really not a bad idea because if you don't capture everything then there may be some things you miss but sometimes maybe there's a bunch of traffic going on in the background and we don't care about that traffic or worse we're concerned about a particular port so in that case we can set up a capture filter so if i come up here and i go to capture and i go to options i can come down to my capture filter for selected interfaces so i've selected my usb interface i'm going to use for doing my capture and i could go in and type in host and notice how it gives me some suggestions it tells me if you're going to type in host here's some things you could type in for that so or i could type in port but let's say i'm interested in port 53 i'm interested in my dns traffic so now if i hit start it's going to say whoa you haven't saved that trace you had before are you sure you want to throw that away yeah so now it's going to go in and start looking at my dns traffic so what i'm going to do is i'm going to come back here we'll go out to amazon let's go out to a few websites here let's see a lot of these are probably cached on my machine let's try youtube so what this will do is this is going to go out and start capturing that traffic to and from my machine and these various hosts out here so i can start getting an idea of um what my dns queries look like so dns one of those protocols that's key to being able to go in and communicate out there on the internet well i need to i can come in and i can see right here i send this query out for dns or for google right there and i get a response back right here in frame number two now remember we set that time field to look at the time between the frames so i sent my query out here i got a reply back in 65 milliseconds ah that's pretty good now we see this 911 milliseconds should i worry about that not really because that is the time between this response and when i set my next dns query now that dns query we got a response back in 1714 microseconds so we can start getting an idea of how long it takes to send packets back and forth now what i'm going to do is i'm going to come up here and i'm going to open a trace file first we're going to stop capturing and we're going to open up the old dot cam trace file now this trace file i captured 18 years ago 18 no let's take a look if we come into this frame right here uh and we look at yes it was captured in 2003. so even a trace that is old enough to vote is still good for demonstrating things now in this case we see a variety of things we see some tcp syn packets we see some acts so this is where we captured traffic going between my machine and the washington state department of transportation and some some of the communication was slow the website was slow to load up so let me show you a few handy things here when it comes to filters i can come in i'm going to grab frame number 24 right here one of the handiest filters in wireshark is to come in and right click and go to follow tcp stream so what this does is this sets up a filter for just the communication between these ip addresses and using these ports so now i'm looking at this specific stream so i can see right here i do my tcp three-way handshake now remember when we're going in and doing troubleshooting we are doing protocol analysis so with protocol analysis we are looking at are these devices acting like they should so here i send my tcp sin i get a sin acknowledgement back in 39.8 milliseconds that is the round trip time between my device and the server so i don't have to try and do a ping and really that was the round trip time 18 years ago when i did this capture so that gives me an idea of what does that round trip time look like now when i come in here i can see that i then send a knack that's the third part of my three-way handshake so i've completed my three-way handshake that is great okay now i can come in and i can uh see that i sent a http get now these were this was back in the good old days be before uh https and we could actually see what was going on in our packets but here we send our http get now our http get it takes us a hundred and thirty milliseconds to get a response from the server now this starts giving us an idea of is it a problem with the server or is it a problem with the network because if i know it takes 39 milliseconds to get a reply back from that server when i sent my sin it takes 100 takes 39 there it takes 130 there that is probably 39 plus the delay on the server to create that interface right there okay now in this case it said use local copy so it told me you have that cached on your machine you don't need anything from me so now we close up our connection and we're done so that is what we see with a pretty typical connection now up here we see tcp stream equal so that is our stream index so for every tcp conversation within wireshark we have an index i could change that to 11 and apply that filter boom there's the next conversation right i could do 12. there's the next conversation but what we're doing is we're filtering down on that tcp stream now nick brought up is that the same as the index column sure i could come in and we're going to see that there's our stream index right there and when we start looking at that i could right click on that field and i could say apply as filter selected and it's going to do the same thing so i could grab any packet within a tcp stream and take a look at it but now let's go ahead and let's jump in and what we want is we want to find the bad packets right we don't care about the good packets we want to find the bad packets so here's what i'm going to show you and this is how we can start modifying wireshark to meet our needs so we're going to apply a display filter here so let's go in and we're going to apply that display filter and in this case we want every bad tcp frame so there's a nifty filter for that and that is tcp dot analysis dot flags so you notice and i know that the screen's a little bit small up there but you notice that down here up here in the corner when i typed that in it started showing me suggestions and if i get the filter right the display bar turns green so now i'm going to go ahead and apply that so now look at all these re-transmissions so now we start seeing tcp re-transmissions so what's a re-transmission well a re-transmission is any case where i send a tcp frame and i don't get an acknowledgement for it and i need to resend that tcp frames every time i send a tcp frame i start a re-transmission timer when that timer expires if i haven't gotten an acknowledgement yet i resend the frame so let's go in and let's take a look at one of these so i'm going to grab one in here how about a sin i'm going to grab a sin frame and i want to grab one right there let's grab this one right here so i'm going to right click and i'm going to follow the tcp stream let's see what happened with this tcp stream so in this case what happened was i sent my tcp sin right there and i waited 2.9999 seconds i haven't gotten my sin acknowledgement back so i resent the sin now if we were to go in and especially with windows at the time this capture was taken the re initial re-transmission timer for tcp was three seconds so our machine patiently waited three seconds and retransmitted the frame then we see that within 41 milliseconds we get a reply back and that is in line with what we saw before it's about 39 milliseconds before so that's in line with it but this tcp syn packet was lost somewhere along the path so we waited three seconds and this is just adds ins or insult to injury right here we say get this header image it says use local copy you already have it so here's an example of where i already had it cached on my machine and i said hey i want to i want that and we waited and waited and waited and waited a long time when it comes to networking three seconds very long time only to find out we had the correct image cached already on our machine so what i'm going to show you next is i think one of the coolest things in wireshark and that is we can now start creating profiles so profiles or ways is a way that we can customize wireshark for a specific protocol so i'm going to come up i go to edit and i'm going to go to configuration profiles and we're going to drag that window back over here so it shows these different profiles that i've already created so we're going to create a new profile we're going to call this webcast i'll hit ok so now what it's done is it's taken my default profile and copied all the settings over to webcast and we're going to make our font bigger again so that you can see what's going on now what i'm going to do i got to be careful sorting on different columns sometimes there's some reasons that we want to do that for here not today so in this case we're going to go back and the last 10 filters that i use are saved in this drop down so we're going to reapply our tcp analysis flags and i'm going to come over here to the far right hand side and there's a little plus right there i'm going to click on that this is where i can save display filters i use on a regular basis so now i could say bad pcp display uh tcp frames that are errored we'll say that and here we see our filters tcp analysis flags and i'll hit ok so now we've got a brand new button up there called bad tcp so i'm going to close that so when i come in and take a look at a trace file i can come up here and i can say hey show me all the bad tcp frames and i see all these re-transmissions okay so now i can start seeing all of these packets that are being re-transmitted well that's not good now if i suspected that my network was a problem i'm going to see retransmissions i'm going to see packet loss and that packet loss is going to cause slowdowns but if i go in and i take a look at a trace and i don't see any slowdowns if i don't see any bad packets any packet loss that can be an indicator that my network and packet loss on that network isn't what's causing the problem so i use the bad tcp filter the tcp.analysis.flags as a way to quickly go in and take a look how does this trace look are we seeing packet loss in there if i am then i'm going to move down the protocol stack and start taking a look at what's happening along my network if i see if i don't see packet loss occurring i'm going to start moving up i want to take a look at how long it takes to get a response from a device now let me we're going to open a trace file here let's see if it's in recents this is another one of my favorites right here now with this one probably too short let's open up a larger version of that there we go all right so we're going to start out we're going to apply bad tcp now we see a duplicate act and we see a re-transmission but we really don't see a lot of problems as far as tcp goes in here so i'm going to go ahead and clear that filter and you're not seeing my screen that's all right now now you do so in this case what i'm going to do is i'm going to come in here i'm going to hit bad tcp we see this spurious retransmission this can be caused at the beginning of the trace by seeing you know packets that we really didn't see the initial packet etc uh here we see a duplicate ack and we can get into that later if we have time but for the most part i'm not seeing a lot of re-transmissions so what i'm going to do is unload that filter so this is another trace captured quite some time ago i was going out to the hilton website so what i'm interested in is where do i see the server taking a long time to reply so what i can do is i can come into tcp and right click and i can go into protocol preferences and what i want to make sure that i'm looking at is that i am calculating conversation timestamps now when i calculate conversation timestamps what that's doing is it's looking at the time between each packet within a tcp stream so now if we come in and we start taking a look at our tcp information we see that right here it says time since previous frame in this tcp stream and if i click on that down here at the bottom and i know it's really hard to see on this screen but it says tcp.time delta this is the time between tcp frames so if i come up here and i say tcp dot time delta and let's say greater than one second okay so now in this case we can start seeing where we have tcp frames that took more than one second to get a reply so we can i'll look at this one right here frame number 11. i'm going to follow tcp stream and let's see what we have going on in here so in this case let's make sure our time is set to second since previously displayed frame so let's look at what's going on in here so what's happened is we've done our three-way handshake since synack this tells me my round trip delay for this connection is about 134 milliseconds then i send my ack then i send my http get now 125 milliseconds later which is in line with what our round-trip delay to the server is we get this acknowledgement coming back right here how do i know it's an acknowledgement well one it says ack and two the length is set to zero now that length is going to be the length of the data that's getting sent back so think of if you sent a certified letter you send that certified letter out when the person receives the certified letter at the other end they sign a receipt and that receipt gets sent back to you so you get a receipt saying they receive the letter now it could take them two weeks to reply to that letter and that is what we're seeing here is that this acknowledgement that we get right here in frame number 10 tells us that our request our http get was successfully received by the server now how do we know that it's that packet well if we come in and look at frame number nine right here if we look at our tcp sequence numbers we can see that our sequence number right here is number one for frame number nine we see that our next sequence number is 349 that's because we sent 348 bytes of data so our next sequence number equals our current sequence number plus the number of bytes of data we're sending which also equals the acknowledgement number so if we see an acknowledgment number of 349 that tells us it got sequence number one and all 348 bytes of data so what do we see right here acknowledgement number 349. this acknowledgement right here goes with that frame right there now how can i make that easier to see one thing i'll do is i'll right click on next sequence number and say apply as column so right here tells me what my next sequence number is and i know that my next sequence number is also the acknowledgement number for that frame so i can see right there 349 act 349 this is acting that so what that does is that tells me the server received the packet but now it waits how long does it wait the server waits 4.85 seconds to send me a reply so is this a problem with the network or is this a problem with the server in this case this is absolutely a problem with the server this is a slow server the network got it there and sent me the receipt back in the amount of time i would expect but the server is taking a long time to reply so when it comes to going through these traces these are the types of things that we're looking for we're looking for packets that are lost we're looking for tcp errors we're looking for cases like this where we see a delay out there where we see that the packets are slow slow coming back and how do we do that we can use things like tcp time delta so now i could add a filter for that i could come back here i could drop my filters down i could see tcp time delta greater than one and let's apply that now we see some resets we see some fins so maybe i'm not concerned about fins i'm not concerned about it taking a long time for it to close the tcp connection or for it to reset the tcp connection so i could say and dot we could say tcp dot flags dot reset equal one or tcp dot flags there we go now that narrowed it down that now i'm looking at data frames that are taking longer than one second now i could even adjust this i could say half a second that's so we could say what if it takes the server longer than half a second to reply now let me make my screen bigger again sorry about that i will keep forgetting to do that but now in this case we've got this filter tcp tcp.time delta greater than half a second and not tcp flags dot reset equal one or tcp dot fin equal equal one so exclude the fins and the resets show me where my tcp response time was more than half a second and i could come in here and say add that as a filter we could call this slow tcp i'll hit ok so now i've created another can filter up there this allows me to more quickly go through my trace files and start finding out where there's problems okay so as we go through here you notice that i added columns so we can add anything that's shown in our decode window here we can add that as a column so we can start bringing some of that stuff up to the surface let's take a look at a fun little trace here so i'm going to open recent we're going to open our dns problem trace we'll close that so here i was teaching a class in orlando florida and i was out by the airport and we were having a heck of a time connecting up to the internet so we decided hey this is a network analysis class let's go ahead and troubleshoot this and see what's going on in here so in this case we did a capture of our dns traffic so we see that our machine right here sends this dns query for google to 4.2.2.2 okay we get a reply back in 141 milliseconds from 4.2.2.2 and it tells us that google is at 0.0.0.1 now that is the ip address to have that is a cool ip address one now does it make sense to google's at one not really so let's take a look at the next one so 1.6 seconds later we send another query for google this time we get a reply and if we look at our answers here 64.233.187.104. well that sounds that sounds plausible that sounds like a good ip address so here we start going in and we take a look and we get a good reply there but now we get one again so one of the things that i always look at when i start seeing things like this i am curious who's responding i want to know where that server is so there's a fun little field inside our ip header that lets us know where the response is coming from so if i take a look at my ip header in here i go into the internet protocol what we find in this case let's click on this is we have our time to live now anytime we send an ip frame we put in a time to live value and every time it goes through a router hop it decrements this value so i can use this as a way to get an idea of how many routers i've gone through so in this case this machine was starting out at 128. so if i come in here and i look at the response i see that my time to live is 62. now this could be as high as 255 to start with that mean i went through about 193 router hops that's a lot or it could be 128. that's still 62 router hops or it could be 64. 64. that seems short if it's 64 that means that one of the root dns servers is residing at the orlando in and suites at the airport and that seems very unlikely but we notice that our time to live is 62 right there now let's look at one of our good responses that has a time to live of 2 45. let's say that seems plausible that would be about 10 router hops if it started at 255. let's look at another good response 248 7 router hops that's plausible here's a bad one 62. so let's raise this up let's make this a column so now and we can take next sequence number and let's get rid of that column we don't need that for this so now we see that every time we get a bad response it has a time to live of 62. so what was happening here well in this case what we were running into is at the hotel they had a box that made us sign in to get onto the internet this box was broken and the way that they forced us to sign in was by intercepting our dns traffic so it was broken and it was responding to any dns query with 0.0.0.1 part of the time so we were able to narrow this down based on the number of routers that we knew we had in the classroom and go back and say you know in this case we strongly believe that there's something wrong with your system here they said yeah you know we've been getting complaints by other people so they got permission from corporate to reboot this box and the problem went away so oftentimes we run into firewalls we run into load balancers we run into other devices that could be in the middle of the network that could be responding as if they were the device at the far end so by going in and looking at things like the t the ip time to live we can get an idea are we actually getting a response from the same device that's kind of one of those little tricks in there i've learned over the years for being able to go in and take a look at that so you know this is one of the things with packet analysis i could uh absolutely go on for days on some of the things that we can go in and take a look at in here let's take a look at another little trace this one outlets so here i did a packet capture and i'll be honest with you one thing i usually like to do is i turn off colorization um there are times where i care about that and there's times where i don't uh sometimes if traffic is not encrypted we can see some interesting things in here if i say tcp contains i can type in a field or i can type in text and it will search all the frames for that text so right here i see break what this is is in this case these are some wi-fi attached outlets i have here in the office and i captured the traffic to and from those devices and the rest of the internet just to find out what were they doing so this break is when we turn the outlet off so we're i was able to capture this and see what ports are being used uh what the ip addresses my outlets are and who they're communicating with in this case and i could come in and i could use something like goip lookup to find out where that device is in fact if we go in let's see if i've added it in here i may have not redone it and that's a that's one for another class is uh we can go in and we can add in the geoip database within wireshark and it will tell us where that ip address is but now i can use filters such as tcp contains to search for specific text or udp contains to search for specific text within my traffic so um i'm going to keep an eye out here for questions if you have any questions i want to make sure that i get those answered but one of the things with doing packet capture analysis and this is a very very brief introduction into using wireshark but is you got to be curious if you're not a curious person yeah you're going to have trouble with this the other one is practice using this before there's a problem don't wait until there's a problem somewhere around here i've got my fire extinguisher it always makes my wife nervous when she comes out here and i've got the fire extinguisher sitting on the bench but i use the fire extinguishers as an example that most fire extinguishers say pass on them pull the pin aim the fire extinguisher squeeze the handle and sweep side to side a protocol analyzer is not a fire extinguisher it's not that easy so first off we want to get in the path of the packets we want to make sure that we are capturing the packets that are having the problem then we want to move in and start capturing or start analyzing those packets there is one more thing i want to show you so let's go in i'm going to share my screen we're going to make wireshark a little bit smaller so back here i've got let me close a couple things up here let's see well here and close wireshark for a sec because it's got one of my screens jammed up all right so earlier i showed you let's go back that switch so if we zoom out a little bit what i have connected to that switch is a raspberry pi so sometimes we need to be able to go in and capture over a long period of time so what i've done is i've taken this raspberry pi and i've configured it so that the wi-fi card in the pi connects to the network i've configured the wired port right there so it does not attempt to get an ip address all it's doing is listening and i've connected that via very short ethernet cable over here to my gs105e so this is my sub 100 packet capture setup so if we come in and we take a look at that pie what we're going to do is we're going to stop capturing for a second and let's see if we can make that font bigger so you can see it we're going to type in what i believe is one of the most useful commands when it comes to doing packet capture so let me switch back over to our screen we've got our screen up there okay so i'm going to come in and i loaded t-shark up on this raspberry pi so i did a sudo apt-install t-shirt t shark is the command line version of wireshark so now i can come in and say sudo t shark minus i eth0 so i'm going to capture an interface ethernet 0. then i'm going to say minus b now there is a pile of command line variables that are available for wireshark but this one allows me to specify how many files are going to be in my ring buffer i'm going to say a hundred then i can say minus b file size i'm going to say 50 000. now this is measured in kilobytes so this is a 50 meg file so i use the combination of files and file size and i base that on how big a drive i have in that device so this has a 128 gig micro sd card in it so i could go with a lot more files if i wanted to then i say minus w and we'll say webcast a pcap so here's what this is going to do it's going to capture on ethernet 0 which is the port that's connected to our little inline tab it's going to keep the last 100 files and it's going to set that file size to 50 meg for each file and each one is going to start with webcast so i'm going to hit enter so now it is capturing all the traffic going to and from my computer now if we come over here to this window and we look at the directory where i started that what i see is here i've got these files right here now we see we've got a new file called webcast so what's going to happen is every time webcast hits 50 meg it's going to start a new file now if we look at the timestamp on this file we have 2021 we have 11 04 we have the time and the date now the time is off on this machine apparently it thinks it's closer to 5 56 p.m but in this case it shows me when each file started and then i can see when the next started so this is a great way to go in and capture over a long period of time i could take this setup i could put it under somebody's desk i could let it capture and then when they have the problem the intermittent problem what i can do is go back and say what time did that problem occur and i can go grab the trace files that i captured during that time because this is the other big one when it comes to capturing packets you need to be there you need to have something capturing when the problem occurred so here we went in we created a little setup using a raspberry pi and a 35 dollar switch to get us in line capture the packets and write it to disk now if you really want to get fancy you could load things like zero tier up on here so that you could access this from outside your network so once i do that capture i can stop it i could transfer it over to my machine now this i mean this takes a little bit of work right because you've got to get these files off of that raspberry pi we could do a scp command in the mac we could copy it over we could use a little applications of windows like winscp that makes it easy for capturing these i've gone in and created just a little web page so that i could get to them but the thing that we can't see is we can't see the live packets going across right because now we're doubling our network traffic so when we're using something like this we're setting this up to capture for a very long period of time now one little trick that i'll do is i will put an icon on the person's desktop and that icon will send a ping to an ip address doesn't matter what i p address but by doing this it puts a marker in the trace file that i can go back and find again in the future so if i came back here let's do that again yeah we're almost at 50 meg right there there we go so we hit 50 meg we started the next trace file now we could go in and use a t-shark to display this but it's just going to run through all the packets i would need to transfer this file now the beautiful thing with this command over here is i can run this command on my machine so on my mac i can come back and run it on my mac in windows you can run it on your machine so if we want to capture this we can take an old machine we run this command right here t shark minus i is the interface minus b files tells us how many files we're going to save minus b file size shows us that all right well we've been going for about an hour so i'm going to conclude this webcast oh thank you for joining me we're going to do these every week it's going to be on some topic we'll come back to some more advanced topics on wireshark if you have any questions anything you'd like to see me cover uh comment in youtube send me a message in linkedin put something on our facebook page but i hope that you found something out of today to be useful i you know i always sit in and listen to other people talk about things like wireshark because there's always a different approach that they may take all right well thanks for joining me and i hope to see in a future webcast we'll keep sending these things out and doing them so thank you very much and have a great day

Channel: Mike Pennacchi

Views: 2,104

Keywords:

Id: M-k3U5Uxbcc

Length: 61min 15sec (3675 seconds)

Published: Fri Nov 05 2021