packet analysis with wireshark can be really hard i'm sure you've felt that way after all
the things that we're looking for at the packet level are pretty detailed we're going down to
the microscopic detailed binary view to answer some of the questions for the traffic we have on
our networks but there's also things that we do as analysts that can make this even harder and
in this video i'm going to go over the top five mistakes that we make as analysts that complicate
our analysis with wireshark let's go to the first one our p caps are just too big now i've worked
with some people that they install wireshark in a certain area they hit capture they walk away and
then they just let that capture build and build and build they come back later and then they got
a whole terabyte of traffic to try to sift through well you don't have to be a wireshark expert to
know that it doesn't do very well past about a gigabyte of data so what can we do well from
the get go if we make our pcap smaller it can be a lot simpler when we go back through and we do our
analysis what i do is i often set up what's called a ring buffer when i'm doing longer term captures
this means that i give wireshark some parameters i say okay i'm going to capture 500 megabyte files
and i'm going to capture 100 of them and then i'm going to hit start what that will
do is it'll store that traffic into those files and it will write a new one every 500 megabytes
when the problem happens now i can go back to the one that was running at the time of the event
and i have a much smaller data set to work with the second mistake we can make as analysts
is having a very noisy machine under test you ever go to do a pcap of someone's machine and you see
that they have a browser open it's got 100 tabs open they're listening to music they're watching
youtube they're doing email and then now you're trying to get a capture of a problem that they're
experiencing what do we do let's shut down all that noise close everything down close down email
close down spotify close down youtube make it to where that machine is transmitting as little as
possible and then that will make sure you have less traffic to have to dig through in the pcap
the third thing is chasing false alarms in the packet capture and here's what i mean by that
sometimes we run across things in our p-caps and we go down these rabbit holes spending a whole
lot of time with things that are not related to the true issue that we're troubleshooting
i'm going to show you three of those the first false alarm is duplicate packets now here we can
see every single packet has a black line after it i see one packet then i see a re-transmission see
another packet then a dupac then a re-transmission i've had people call me and say chris my network
is falling apart it's being ripped apart at the seams what do i do well here let's just back up
for a moment if i take a look at the first packet and i take a look at the ip identification number
here i can see that this is 5722 if i go to the very next packet which happened almost immediately
i can see exactly the same ip identification number that means that i caught the same packet
twice this is really easy to do when i'm capturing on a span port especially when i feed multiple
interfaces over to my monitor port it's easy to catch a packet when it's coming into the switch
copy it and then when it's leaving the switch get another copy so duplicate packets are a false
alarm that we want to make sure that we watch out for the next false alarm would be so called
oversized packets now i fell prey to this one too so don't worry if it's gotten you let's take
a look at it from a packet capture perspective if i come in here check out our segment size
now notice this is just a conversation it's a tcp conversation but notice one station is
sending these packets that are 14 000 bytes long now how is it possible i can have a segment that's
longer than the network mtu well that could really catch my attention and i could spend a lot of time
coming in and trying to troubleshoot these so-called jumbo frames in reality all this
is is that the packet capture driver captured this before the data was segmented all it means is the
station is doing segmentation offloading so instead of tcp doing the segmentation
breaking up the data into smaller pieces that just means that after the point of
capture the nick itself is actually doing the segmentation so had we captured on the network
off of either a tap or a span we wouldn't see these really large frames instead we would see
that mtu being respected by the packets and another false alarm this is one that i commonly
hear as well are really small tcp windows let me show you what i mean if i take a look here
i have a tcp conversation happening between endpoints and if i just take a look at this
first packet and i come down now this is a device that looks like it's acknowledging data or better
yet why don't i jump down a little further here if i take a look at this packet and i come down to my
tcp window i can see that i only have a window size of 244 bytes that means that this station
cannot receive any more than 244 bytes at once that's tremendously small so we might be thinking
oh i have no window let's look into tcp let's see what's going on here when in fact all this means
is that we missed the tcp handshake now up in the tcp handshake very likely there was a window scale
that was exchanged between the two endpoints that would greatly multiply this number in fact this
number is probably well over 100k but because we missed the handshake wireshark doesn't know how
to multiply this number that's why it's telling us the window size scaling factor is unknown so this
is not the true window in this conversation now there's other false alarms that we can run into
in wireshark but those are definitely some of the big ones all right the fourth mistake we can make
is capturing traffic in the wrong place see we can assume that we know where traffic goes
maybe we plug into a switch and we think that we have a proper span setup or we think we
know which server a client is communicating with when in fact it's talking to a different
one so particularly in a switched environment we want to make sure that we get our packet capture
device in the right place and we do that largely by either using a tap to actually break the
connection somewhere along the network path or we can use a span and make sure that we pass the
appropriate traffic over to our monitor port and the fifth mistake it's easy to make as analysts
is not being able to duplicate the problem can't tell you how many times i've gone out to a client
and we just cannot get the problem to happen again it's intermittent so in those cases what we have
to do is set up packet capture that's ongoing just like we talked about with problem number one
we want to get those ring buffers going to be able to capture traffic all the time and when
the event does happen we were in the right place at the right time to properly capture it now one
other thing that can make it harder for us to do our analysis is not setting filters properly so
go ahead and click this video over here and learn more about how to properly filter with wireshark