Decoding Packets with Wireshark

hey Mike Funaki here with Network protocol specialists and today we are going to be decoding some packets so I'd like to welcome everyone that's on as always let me just scroll down here a little bit comments are highly welcomed questions always interested to hear what you have to say so Mike on Twitter at M pinnock is my twitter ID there and so let me just get rid of that and so that you know as I'm going through here I not only analyze packets but I produce these things myself so if you see me looking down and clicking on things it's because I'm moving the video around all right before we get going into taking a look at packets there are a couple things that I would like to talk about and one of those is that I am going to be speaking at interrupts this year so this will be I think my 22nd year of teaching it Interop and so I'd like to welcome you I'm going to be doing a class on Tuesday May 1st on Wireshark and digging into packets so this will be a day-long class so if you can make it to interrupt that would be great love to see you there even if you don't come to my class still love to see you and if you are going to be coming to Interop there's a discount if you use my last name so if you go in and sign up for Interop you can put in the discount code pinaki and that will save you $300 on your pass there so not a bad deal for being able to go in and save a few bucks on that so feel free to use that pass if you'd like and that will get you in a little bit cheaper all right so with that said I think it's time that we go in and start taking a look at some packets here let me clear some things out there and make sure I got everything all set back up the way I want it here all right so let's get rolling with taking a look at packets so when it comes to capturing and analyzing packets oftentimes we see people start using a tool like Wireshark and they get hung up on capturing the right packets on how to start decoding those etc so what I like to do is periodically do a webcast a YouTube live event like this so that we can go in and we can talk about some of the things that we can do when it comes to doing packet capture and one of the most important things about doing packet captures is getting the right packets so one of the things that I'd like to take a look at before we get started with digging into the packets is taking a look at a way to get in line so one of those ways of doing that is using a tap or a span port so in this case what I've done is I've taken some little Netgear switches and converted those over and let's see if we can switch this over okay I don't all right so right here I have this Netgear GS 105 II switch now this is just a simple little barely manageable switch out there and but one of the things that this switch does pretty well is it allows us to go in and do port mirroring so what I've done is I've set this thing up so that we've got our source port right here and that source port is being mirrored over here to our analyse report and what that allows us to do is to go in and start taking a look at what packets are going in and out of this port because getting in the path of the packets is always one of the most challenging things so typically what I'll do is I'll take and plug my network in the port number five right here I'll plug the device I want to monitor into port number one then I'll come in here and in port number four which is my analyze report I'll plug my PC now these things go for about third two bucks on Amazon I've got a whole pile of them that I've bought over the years you see this one has a few scratches on it there and I keep these in all of my bags because if I want to go out and get in line now we could spend a significant amount of time talking about Spain versus tap reliability etc so some of the challenges that we run into is with this little gizmo right here this little Netgear gs1 o5e switch one of the challenges is if we lose power on that power supply right there the connection drops so when we start talking about capturing and looking at packets where I've got a tap set up on my internet connection now what we find with that internet connection is that I've got a fault-tolerant app in there and the reason I have a fault-tolerant tap and let's see if we can get all of this switched back over here without it being a huge mess and we'll flip over there so one of the reasons that I use a fault-tolerant tap is I want to make sure that if I lose power or if the power supply fails on that tap that it doesn't knock down my interconnect connection because it would be a real bummer if I was doing a presentation like this and all of a sudden we lost connectivity because that power supply went out so depending on the environment you're in using something like a Netgear switch may not do the trick now when it comes to configuring that Netgear switch if you go out here to my youtube channel I do have a video out there on how to go in and configure that switch to Mir ports now one of the things that was really interesting that we found when we were going in and taking a look at that was that this switch reduced the throughput down to 500 megabits per second in each direction when we're running full duplex traffic so on the good side of things that limits the total amount of traffic to one gigabit per second so I can't overrun my Mir port on the downside it does reduce that throughput down to five megabits per second so good and bad but certainly having a little something like this to throw in your bag when you're going out and doing troubleshooting is a great way to get your PC in the path of the packets because just plugging into a switch port isn't gonna cut that for us okay so let's come over here and let's start taking a look at some packets so we will switch over there and here we have Wireshark so this is where I've got Wireshark loaded on my machine one of the things I did was I went out and I made sure that I had the latest and greatest version before we got started so some of the things I'd like to do in our session is just take a look at some basic filters basic things that we're gonna take a look at when we're using the Wireshark analyzer so I'm gonna start out by coming in and opening a file here and the file and then I open is my old dot cam file now the dot cam file is a very old file I captured this file way back in I think 2013 we can look at the top of the the information here and thousand three so this this trace file is what 50 almost 15 years old but here's a funny thing about trace files even though they're old and they contain old packets out there they still have a lot of good information about what's going on so we're going to dig down through this tray so we're going to take a look at a few cute key things and I'm going to window that again because I want to be able to get in here now I want to show you an important feature of Wireshark and I'm gonna use this quite a bit we're really gonna focus in on that if we come down here into the bottom corner I draw a little circle right around there I don't want to make sure that that's not on top of me there but you see it says profile TCP I'll just move over there a little bit so you can get a better look that and that profile TCP tells us what profile that we're using within Wireshark and profiles are a real important one because profiles allow us to save our filters our columns our color rules things like that to a profile and then I can go back and I can use that profile over and over again so one of the keys to using wireshark successfully is configuring it for your environment configuring it for the way that you want to go in and analyze packets so we're gonna escape out of there so if I came up and I went to edit and I went in here to configuration profiles this is going to show some of the profiles I have so I'm gonna add a new profile and we're gonna call this a live stream okay I'm gonna click OK now when I create that live stream profile what we notice is again down there in that lower corner we see that it says live stream so there's our new profile that we just created and these profiles are saved out on the disk so we can go out and we can dig these up pretty easily if someone said my volume seems a little bit low so we're gonna crank the volume up there just a little bit and make sure that everybody can hear me okay in fact I'll just bump that up a little now I don't want it clipping off too much but well I will give that a shot right there and see if that helps okay so in this case we're gonna come in we're gonna hit escape on let me hit escape on here okay and hopefully the volumes a little bit better now I turned up the microphone a bit but in this case what we're gonna do is I'm gonna come in here and we've created this new stream now when I create that new stream it I've got my packets in there I've got my colorization rules now these colorization rules are going to colorize the packets based on what's going on in there now you know it's one of those things where I it's up to you you know do you like the colorization do you not like the colorization for today we are going to go in and I am going to turn off the packet colorization so what this does this takes off those colorization rules in there and we see that you know we're getting the packets so now I want to create the filter that I use the most and this filter is going to help me identify when I have bad TCP frames because oftentimes people complain I can't connect to something I can't the networks running slow I've got a problem so what I'm gonna do is I'm going to come up here and I'm going to type in TCP dot analysis and this is important to note as well and I lost it when I hit that key is that as we're typing it in it's showing us the available filters that we can put in here so I'm going to go into TCP analysis dot flags now this will be set any time that Wireshark detects that there's a problem with TCP so in this case by setting TCP analysis dot flags I'm gonna look for any bad TCP frames now I can click this little blue arrow right here and that's going to apply that filter okay so now this is showing me any case where I've seen my TCP analysis flags and if we drill in we see what have we seen in here well I've seen some TCP retransmissions so these retransmissions could be an indicator that I'm having trouble connecting out there to a website or to a server that I'm trying to get to so if I scroll down one of the ones I'm really interested in is these TCP syn frames right here now some of these may be you know not really an issue because if I'm trying to connect to a resource that doesn't exist maybe that's not a big problem but right here I see a TCP sit retransmission where I'm trying to connect to port 80 on a website out here that is an issue so this brings us to the next piece that's really important when we're going in and setting up our profiles and starting to get in and decode packets and that is saving these filters so what I'm going to do is I'm going to come in here and I'm going to click on this little plus symbol right up here at the top of the screen and we'll just drill in a little bit I'm going to draw a circle around it so I really want you to pay attention to that and that little plus right there is an indicator where we can add our display filter so I'm going to click on that plus and it says right here label apply this filter filter TCP analysis flags so I'll come in and I'm gonna say bad TCP and I'm gonna click OK now when I do that it adds this filter right up here at the top so if I go up and I clear out that filter we're seeing all of our frames if I want to go back in and I want to see just the bad TCP frames I can now come in here and click on bad TCP and that will show me those frames and I've now created that filter so what I find is that I end up going in and creating these types of filters over and over again and those filters are unique to that profile to that type of traffic that I want to go in and monitor so by doing that it allows me to quickly filter in on those packets that I really care about okay so now let's go back down here and we see that I've got some TCP syn packets right here where I'm seeing retransmissions so what I'm gonna do is I can click on that frame now the next thing that I'm gonna do is we're gonna go in and I want to drill in on just that one TCP conversation because what's one of the problems that we run into when we're going out and we're analyzing traffic using wireshark we're looking at too much traffic at one time we're trying to take a look at too big a picture so what we want to do is we want to go in and we want to drill in on just those packets that are having problems so what I'm gonna do is I'm gonna come into this frame right here and going to right click and I am going to go to follow TCP stream now when I do that it creates a filter on just that TCP conversation it then comes in and it tells us okay you know we're gonna go out we're gonna get this I Jif image right here we're going to say you know use local copy that's fine there's sometimes when I'm interested in the text that's in there but in this case I'm gonna hit close and I'm more interested in what's going on with my packets right here so the next piece that I'm gonna take a look at is my timing and right now this is showing me typically the time since the beginning of the trace file so I'm going to come up to view and I'm gonna go into time display format and I'm gonna change that since seconds since previous displayed packet they click okay now what this does what this does is this shows me the traffic for this one TCP conversation from beginning to end and it shows me the time between each one of those packets I can tell you in my career of going out and doing network analysis not once has anybody ever contacted me and said Mike my network is running too fast in every case somebody has contacted me and said Mike my network is running too slow so if we have a network that is running slow then what we want to look at is we want to look at the Delta time this time between each one of these packets and in this case we send that first TCP frame right here frame 132 we then are waiting for a TCP syn acknowledgment this lets us know that that frame made it to the device at the other end here we see we didn't get that syn acknowledgement so what do we do well TCP is going to retransmit that sim frame so in this example we see that that sin is retransmitted 2.9 2 seconds later that is a three second delay that we see out there between the time that we sent that first syn packet and when we got the response back so that 3 seconds is a ridiculous amount of time when it comes to going across the internet now I send that and let's escape out and we'll zoom back in again and what I resend that syn here we get our sin acknowledgment back and we get that syn acknowledgment back 31 milliseconds later that's a round-trip time between us and that server so what should have taken 31 milliseconds ended up taking us over 3 seconds ok so in that case I'd you know that that turns into an issue because we're waiting and if we went back and we took a look at what was happening out there as far as our let me just adjust that a little bit if we take a look at what was happening out there as far as that traffic going across what we found was in this particular example and we're going to let me do this again I'm gonna right-click on your do follow TCP stream again and I want you to take a look at this text because what's happening here well in this case I'm going out and I'm going out to get this image and the server that I'm communicating with came back and said use local copy so the copy I had cached on my machine was hardly the right copy I didn't even need to get anything off of the network but I ended up going all the way out there to have to find out that it was that copy was still good and it took me three seconds to find that out this is an indication of packet loss across our network I sent that packet out I didn't get a response back so from a troubleshooting standpoint we then have to start digging into where is that packet loss occurred so this is where we need to capture in multiple locations throughout our network and by doing that we can take and compare those captures and find out where along the path are we losing those packets so let's come in and we're gonna close this particular trace file so honestly this trace file was one that I I didn't even really put a whole lot of effort into going out and capturing I was working late one night I decided to capture this trace of going out to the Department of Transportation website and this is what I got so let's go ahead and I'm going to open up a trace and I'm going to open up slow HTTP GET now slow HTTP GET let's clear that filter right there this is an example of where we're gonna go out and we're going to get an image and we're gonna find out how long does it take to get a response back so in this case here I've got this HTTP GET right here and I'm going to do my follow TCP stream on that now what I want to show you is you know kind of the nuances of looking at this trace file this is what it is really all about is going in and taking a look at all of those little details in there about the trace and what tells us you know what's an issue what's not an issue etc so in this particular trace what we're seeing is that we send this TCP syn frame right here in frame number four so I send out that syn and I just cannot overemphasize how important it is that we go in and do things like follow TCP stream why because that helps us zoom in to just those packets that were interested in for this particular stream I then find that I get my TCP syn acknowledgment back in a hundred and thirty four milliseconds so anytime I'm analyzing a trace file one of the first things that I'll do is I'll go in and I'll start trying to get a mental image of what is my round-trip time how far away is this server from me so once I do that and I know about how far away that server is then I can take a look at the rest of the trace and get an idea does this look like something I expect okay so in this case I send my TCP are my HTTP GET right there give me your web page I want to see the front page of this website now I get an acknowledgment back right here at 125 milliseconds okay so I get this ACK back now we could start digging through these frames I can show you that if I send this HTTP GET right here let's dig it start digging into the detail section of our packet I'm going to go into my transmission control protocol header and what we find is this is TCP sequence number one right there TCP sequence number one that's at HTTP GET and I sent 348 bytes of data in that frame now how do I let you know that I got a TCP data segment I send you back an acknowledgment that is equal to the sequence number plus the number of bytes I received so if we send you if I send you sequence number one and I go in and I send back I and I send that many bytes of data 348 bytes of data I would expect an acknowledgement of 349 so let's see if we see that well right there ACK 349 and in fact in our frame right here it tells us that our next sequence number is 349 that's what we expect the next sequence number to be so how about that right up here 125 milliseconds later I get an acknowledgment back if I know that my round-trip time between myself and the device out there at the far end is about a hundred and thirty-four milliseconds and I get an act back an eighth of a second right 125 that's consistent that's about what I would expect for an acknowledgment to come back so if that's the case and I get that acknowledgement coming back in there in that period of time then that tells me the packet got all the way to the other end and I got it acknowledgement back that server got the packet let's look at the next frame the next frame shows us four point eight five seconds that is how long it took us I'm just gonna zoom in again so it's easier to see right down here and our bytes we see that that is where we got our HTTP okay that is where we got our response back from the server with the web page but that response took us four point eight five seconds so in this case if we said is this a problem with the network or is this a problem with the server well the server got the packet in the court in a eighth of a second 125 milliseconds we got the ACK back it told us I got the package but it took four point eight seconds to get a response back so in that case it's not a problem with the network it's a problem with the server this is like getting a return receipt when we send certified mail so by being able to go in and start taking a look at these trace files and seeing what's going on in there with the packets it is a way that we can start getting a feel of what's going on with our network okay so I could come into this trace I could say are there any problems well I could click on bad TCP and we see that we've got to do back in here we've got a spurious retransmission which can sometimes be caused by a retransmission well let's see let's filter in on that we're gonna follow that TCP stream and what I like about Wireshark it holds position for me here so we see that you know we saw a retransmission right there so we can take a look at our sequence number we see that that sequence number one four four one nine and we see that there's sequence number one four four one nine up there now what can happen sometimes is we can run into a situation where the device our device right here thought that the packet was lost it waited 148 milliseconds right there before it got an acknowledgment and it had sent this retransmission out so in this case this could be an example of where we retransmit or the other end retransmitted that because it thought that we hadn't gotten it and it took it so long to get an acknowledgment back it retransmitted that packet okay we could run into places right here where we have a duplicate acknowledgment that is a result of that spurious retransmission so in that case probably not really a problem but this gives us a way that we could go in by taking a look at when do we receive that acknowledgement so I always always look when I'm analyzing packets did I get an ACK if I got an AK that I know the device at the other end has it I didn't get an acknowledgement to the packet then the packet never made it there and I need to start taking a look and where that packet potentially could have gotten lost so there's an example of taking a look at a trace where yeah overall traffic was good no packet loss but we had a case where we had a slow server on the other end hey so I'm gonna clear that filter out we're gonna open another trace I just in this particular session I want to go through a few different traces and take a look at you know some things that we might see out there and this is a real good one this is bad DNS so let's go ahead and take a look at bad DNS now bad DNS was a case where we were at a hotel and down in Florida we were trying to do a class and it just wasn't working every time we tried to go out to the internet we'd have trouble getting to the Internet so let's go in and take a look and see what we have going on with our packets so right up here I start out and I send a DNS query right there for google.com and I get a response back and if we drill into that response right there it shows us on this line the IP address that's being returned for Google Doc that's 0.0 0.1 now the probability of Google having the IP address of one is very very unlikely so what that tells me is something's wrong this could explain why I'm having any trouble trouble getting out to the Internet I'm getting a bad a dress now if I look at what server's sending my response I see it's 4.2.2 - now I can come up here and I could save you and I could say I'd name resolution now normally we turn off Network name resolution because if you're doing a big capture this can result in a lot of DNS queries going out so what I'm gonna do is I'm going to come in and I'm gonna hit resolve the addresses I'm gonna reload my trace right here okay so we can see if it's going to resolve that network address right there okay so 4.2.2 - that is a pretty major DNS server to be returning 0 not 0 not 0 not 1 so here's the first thing I look at when I see a case where I'm getting information coming back that just doesn't look right I'm gonna come in to my IP header and I'm gonna look at my time to live where did this come from so in this case we see that our time to live is 62 now our time to live normally starts at 255 128 64 sometimes 60 32 now people can adjust this to whatever they want but this is an example of where we would expect that it would start out at 255 128 64 now if it started out at 255 that means that I would have gone through hundred and ninety-three hops to get to this device that doesn't sound reasonable it started out at 128 that means that I would have gone through approximately 66 hops that still doesn't sound right so the other alternative is two hops now that means that the DNS server was probably in the same hotel I was which is very improbable so this is an example of where that number tells us that something could be intercepting our packets and responding to us with improper information okay now let's come down here and I see that in frame number four I get what appears to be a more reasonable answer in fact if we expand out our DNS section and we come in and we take a look at our records in here we get a list of IP addresses that seem to make sense this is where we have to go and we have to put a little thought into it we have to say does this make sense what we're seeing and in this case what we're seeing is addresses that seem to make sense so let's go back up and take a look at what our time-to-live look like for that particular frame was it 60 - no it was not 62 it was 254 254 makes sense 254 says I came through about 10 hops that tells me that I'm probably talking to the real 4.2.2 - so let me show you this and this is something that when it comes to going in and using wireshark makes it much more usable and that is that time-to-live field I can go into each packet and I can take a look and see what that time-to-live look like or I can go in and take that time to live and make it a column so I'm gonna right click on time to live and I'm going to say apply as column so now what we see is that we now have our time to live here is a column and will we find that you know the ones that are originating from our machines have a time to live of 128 we see that right here this one that worked okay where we got reasonable addresses back has a time to live of 245 we see that this one right here has a time to live of 248 those are reasonable numbers those are numbers that we would expect out of there but we find right here there were we get a response of 0.09 0.1 that has a time to live of 62 now what we ended up finding out in this particular situation was that the network that we were connected to had a system in there like a lot of hotels do for intercepting our packets and making us pay to connect to the internet this system was broken so periodically instead of putting in the IP address of the Gateway at the hotel it would put in 0 dot 0 dot 0 dot 1 now if we had somebody that had put a device in line that was trying to redirect us to a site that and collect our credentials trying to collect our login information we would see that the time to live would come back rarely do we see that these systems will go in and go so far as to adjust the time to live to make it to look like that servers further away so this is where we can use a tool like Wireshark to make sure that the packets are coming from the source we expect them to at that time the live all the sudden becomes much shorter than what we would expect that would be a clear indication that that packet is originating from somewhere other than where we would expect it to originate okay so you know just some little things out there I you know we've taken a look at I can use my profile and what we find is that now that column that time-to-live column is saved in that profile so if I go back and open the live stream profile again that columns gonna be there the columns are gonna be there in that order that bad TCP filter is gonna be in there so this helps me drill in to those things just a little bit faster now let's go ahead and let's we're gonna take a look at another one in here and that is I'm gonna come in and I'm gonna say file open and what I've got I used a way an emulator to allow me to impair some network connections and what does when emulator I said you know what what if we run traffic at a variety of different TCP window sizes and a variety of different loss rates so in this case we're gonna grab this is a real nice one in here we're gonna grab this conversation this is a 100 megabit per second wide area network connection with 40 millisecond road trip time and no packet loss in a 64 K window and we're gonna click on sender side so in this case what I did was I did an eye perf test and I ran traffic through the network and I captured it so we're gonna scroll down and for this particular demonstration what I want to do is I want to grab a packet that has bytes right so we have 60 bytes this is an ACK I want to get data where I'm actually sending the data across so I'm gonna grab one that says 1514 right there and I'm gonna come up to statistics and I'm gonna go to TCP stream graphs and I'm gonna go to my Stephens graph now what Wireshark is going to do is it's going to go through this trace and it is going to graph out TCP sequence number over time so this is a beautiful graph because what we're seeing in this graph is we are seen where we are graphing out that TCP sequence number over time and right down here at the bottom this is a beautiful picture of tcp slow-start this is where TCP is sending frames out and it's slowly sending more and more frames out onto the wire to to see how many can we have out there at a time and the fact that this line I'm just using the roller on my mouse to zoom in and out but as we zoom out we can see this is a beautifully straight line this is exactly what we want to see for a file transfer this tells us that we're moving data through there and that is going great so now I'm going to hit close and I'm going to come up here and I'm going to go to my statistics and I'm gonna say I let's see do I want to see capture file properties now what i look at capture file properties this shows me for my captured and my displayed what my average bits per second were so i was getting about 11 megabits per second out of this connection now in a future session we can talk about things like bandwidth delay product and why is it I'm not getting a hundred Meg when it's 100 Meg circuit that's for a different date but by using my package or my capture file properties I can come in and start getting an idea of what type of bandwidth am I getting now let's go in and we're going to close that and we're going to open a different trace file in this case let's come up here we're gonna open this 45 megabits per second with two percent packet loss we're gonna open that from the sender side I'm gonna come down now you grab one of those 15 14 byte packets I didn't go to statistics and I'm gonna look at my Stephens graph that's horrible look at this thing that doesn't look anything like that other graph and why doesn't it look anything like that other graph because we have packet loss going on and that packet loss is impacting our ability to move those bytes across a wire now let's drill in and this is one of the things that is an indicator of packet loss right here and each one of these dots represents a data segment that we sent and in this case we see dots that are southeast of our line so here we've gone in we sent data boom boom boom boom boom boom then we waited for an acknowledgment we sent some more data but if we get up to here we see that we've got these dots that are southeast of our data line right there those lines that are southeast right there are an indicator that we are retransmitting segments and when we look at what happens after weari transmit those segments we go back into slow start and then we see some retransmission and then we go back into slow start again and so if we came up here let's hit close we look at our capture file properties our average bits per second 742 kilobits per second that is horrible so this is an indication that we're seeing packet loss out there we would want to go in find out the cause of that packet loss and eliminate that that is having a significant impact on our ability to move those packets across the wire so this is an example of how we can use tools like the TCP stream analysis to illustrate what's going on with our tcp frames it's very easy to show somebody those two graphs and say this is when things are working good and this is when things are working poorly so by doing that we can sit you know we can start showing this is what the impact of packet loss looks like on the traffic that we're sending across there hey let's see let's open another one we're just gonna go through a few more little traces here one oh I know let's see go back up there oh let's see let's go back into dot cam and I actually let's just do this we've got we're gonna I'm gonna close this and open up my web browser right here so what I've done and this is also you know we're not gonna have time to get into this today but what I've done is I've gone in and I have set up a PC and this PC is running Linux and it is doing captured a disk so it's been set up so that every time it starts up it just starts capturing packets to disk and if I came in and I looked at my capture files what we would find is I've got this ring buffer out here so we'll do another session on how we can go in and set up a ring buffer but what we find with this ring buffer is that this is taking and writing 50 Meg files out there to disk and every time that file fills up it writes another one or writes another one it writes another one so I am capturing all the time of my wine leak so if I came out here and I said you know what let's take a look at 10:16 on now let's see I will do we see some traffic we're going to take a look at this trace from Wednesday so the great thing with this is this allows me to go back in time and by capturing to a ring buffer we are capturing all the time so when someone calls up and they said you know yesterday things seemed kind of slow at this time we have a way we could go back and take a look at that so now what I'm gonna do is I'm going to come in and I'm going to open that trace file so I just created a little web page so I could pull those trees files down off my machine so now we're going to open this 50 Meg trace file and we're going to take a quick look at DNS and I'm going to show you you know a couple things that we can do in here when it comes to DNS okay so we open the trace file and first thing I'm going to do is I'm going to come up to the top I'm going to type in DNS and I'm going to apply that filter right there so this is going to go through my trace file and it is going to filter that trace out looking just for DNS frames now that takes a while because this is 50 Meg worth of trace and I got my machine doing lots of other things like producing this video so we will let that come back and there's all of our DNS traffic so what we see is if we look down at the bottom that DNS traffic was 20 or 2025 frames and it made up 2.6 percent of our overall packets so what I want to do is instead of having to go back and dig through all of those packets again every time to take a look at the DNS traffic what I'm gonna do is I'm gonna come in here and I'm going to say file and I'm gonna say export specified packets we cannot do a save as if you do a save as it will save everything what we need to do is we need to come in and say export specified packets so right down here we see it says displayed and so what we'll do is let's see we're gonna come in and I'll go ahead and say bring all this DNS Oh and I'm going to hit save so now it's going to save just those packets so we're gonna close this trace file that big trace file I'm gonna say file open I'm going to open DNS only so now in this case what I've done is I've opened just those DNS frames and see how much faster that opened there's no sense fighting with that trace file going through hundreds of thousands of frames when we're only concerned with these two thousand I'm going to get rid of this column because I'm going to show you how to add that here so what I'm gonna do is I'm gonna say there's my time to live right there and we're going to go in and I'm going to say edit configuration profiles and we're gonna create a new one we're gonna add one we're gonna call it DNS I say ok so now we've got our DNS for this one I'm gonna go in and turn off my colors packet colorization and I'm going to come in here and I want to see how long did it take to get replies to my DNS queries so if I were to come in and click on a DNS response and I expand a deep domain name system so if I came into my details section right here and I expand the DNS portion of that what I find is right here I've got time that time shows that if the request was in frame twelve and the response was in frame fourteen it took twenty five milliseconds get to get a response to that DNS query so I can right click on time and I can say apply as column so now what we see is we have a column right here that is showing us all of our DNS response times so if we have add it slow DNS server this can cause everything to be slow so if I want to quickly find my slowest DNS queries there's a few things I could do one is I could come up here to my filter but I can say DNS dot type how did I know that there was a time well because here are all of the different things I can filter on for DNS and right there is DNS time also let's clear that out if I click on this frame right here we go down to the bottom of the screen it shows us the name of that field right there DNS time so what I can do is I could come up and say DNS time greater than 1 this would show me any case where my DNS response time was greater than a second ok that's good we didn't see any of those how about DNS time greater than point 1 this is every case where it took me more than 100 milliseconds to get a response to my DNS response rate request so we find that yeah we've got some approaching 190 F there so part of it is what's our expectation if we're expecting that we're gonna get a response faster than that then yes we would want to get in and find out why that's slow we could also come in here and find out which servers tend to be the slowest so if we came over here we see that 184 tends to be pretty slow 95 tends to be slow here's one of the things I found with a lot of organizations they're given a list of DNS servers from their ISP and they typically use those DNS servers in the order in which they were given those IP addresses from their ISP do you think everybody does that yes they do so that means that everybody is using that DNS server that's at the top of the list first then they're using the second one so oftentimes what I'll do is I'll flip them over I'll use the last DNS server first why because that's the one that both people are at least likely to use theirs tools like DNS Bench and DNS bench is a free little tool that will go out and measure the response time to DNS servers so because we send so many DNS queries in this very relatively short trace on our way and like we sent at least a thousand DNS queries we want to make sure that those DNS queries are getting responded to in a timely manner so it's by going in and taking a look at that we can also see are there particular DNS names that are taking longer to get a response so in this case I have now created this filter so I can say let's say that I define that anything over 150 milliseconds is excessive so here are my excessive DNS queries as far as I'm concerned so if we go back and we use that plus symbol again I could say label this I'll call this slow DNS okay so now if we clear out all of our filters and I were to come in and say hey do I have any what I consider to be slow DNS queries here I click on slow DNS do you see how fast that is when we want to go in and we want to be able to grab a quick picture of what's going on in our trace we're not I'm not having to type these filter this and over and over again in fact if you share these profiles with others so if I go to help and I go to about Wireshark and I go to folders right here it tells me where do I store things like my configure you know my configurations right so I can go in and we could look in these directories and it's going to show me where I'm storing these different files okay you can share those profiles with others and you can say here's this profile so the first thing I want you to do when you're looking at DNS is I want you to click on slow DNS I want we could say let's just go in we could say right here are flags and we could look at opcode so we could say there's a query say so there's a response we could say error code so if I came up here and I cleared out that filter and I grabbed a response and I right-click on error code and I say this is another powerful one apply as filter or even better yet preparers filter I'll say selected so now if I say DNS flags are code that's our return code and I put a exclamation mark in front of that right here it says show me any case where my DNS flags dot return code is not equal to zero okay whew well pretty much every one of my queries comes back with that okay so that isn't very good so now what I would do is I would clear that filter out and this is where you know our trial and error in a lot of cases comes in and building these filters but now what I'd want to do is right here where it says message is a response well that return code only means anything if the message is a response so I'm going to come in I'm going to right click on that I'm going to say prepare as filter selected and then I'm going to say add and then we'll say return code we're gonna right click on that we're gonna say prepares filter but this time we're gonna say and not selected show me any case where it is a response code and it is not that now we've done I've done something haywire I put my hand in there when I wasn't supposed to so let's fix that how did I know it was bad because it was red now it's green I'm gonna apply that and this shows me any any case where I got a return code that was an error now in this case no such name so here's these are cases where I went out and I did a lookup and I got a response back that said it that name doesn't exist what if I don't care I don't care if no such name is really even an issue well we could go in and we could keep adding things I could say I'd take this prepare his filter and say and select it well we would say n-not so show me any case where it's a response the return codes not equal to zero but it's not named not found or no such name okay so what we find is that in this case we don't have any DNS errors that end up with in a situation where it is not it's an error and it's not a no such name so I could add hit my plus over there and I could say bat or DNS failed we could put something like that in there okay so what this does is this allows us to go in and start creating these filters and saving those that gets saved with that profile and I can always come down and it's back behind me let me move that out of the way there if I ever click on that profile right there it'll bring it up and show me all those different profiles I have available so going through and taking a look at packets is one of those things that we get better with time you got to capture it you got to look at it you have to start setting up filters and zooming in to just those packets you're interested in so some of the things I wanted to cover today how can we use things like our little our little Netgear switch right here to tap in and monitor those packets okay so I'm gonna come over here I'm gonna put in that is the GS or Netgear GS 105 e that's the switch I use that thing runs about 32 bucks on Amazon right now great little tool for being able to go in and get in the path of the packets you want to see how to set that up as a span device go out check that out on my channel there's a video on there okay we've got the pro at linkedin protocol analysis okay I've got the LinkedIn protocol analysis and troubleshooting group feel free to go out and check that out we've got great information out there from a number of contributors on network troubleshooting things like that so I am going to continue to do these all right it's a great way doing them live like this is a great way to get me to record them and do that what we'll do is we'll the next one that we do we will start where we're at here we'll keep moving along and digging further in but what I encourage you to do is go out start capturing packets start taking a look at what's going on one of the keys they make this may make myself a little bit bigger here just to emphasize this one of the keys to successfully analyzing and troubleshooting packets is going out and doing it if you don't go out and capture them if you only wait until there's a time when there's a problem and you decide to start capturing them then you're gonna have trouble because you're not going to know how to use the tools you're not gonna have your filters built and you're not going to be familiar with how those protocols go back and forth so I'd like to thank everyone for joining on for the session today we will do more of these we'll keep going through and taking a look at how to decode packets with Wireshark how to go in and do troubleshooting so I'd like to thank everyone for joining hi this is recorded and it's gonna be out there so that if you want to go back and take a look at it later on it'll be available for you so thanks for joining me and I hope to see you in a future session you

Channel: Mike Pennacchi

Views: 166,916

Keywords: wireshark, tcp/ip, tcp, ethernet, packets, packet capture

Id: U9i7rWV-Gxo

Length: 62min 23sec (3743 seconds)

Published: Fri Feb 16 2018