tcpdump won't capture entire packet

27,795

The guidance on the Wireshark documentation suggests capturing the entire contents of the packet using this command:

$ tcpdump -i <interface> -s 65535 -w <some-file>

Looking at the man page for tcpdump the guidance there suggests that -s0 should be equivalent:

-s

Snarf snaplen bytes of data from each packet rather than the default of 65535 bytes. Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in. Setting snaplen to 0 sets it to the default of 65535, for backwards compatibility with recent older versions of tcpdump.

I suspect that you might be losing some of the data due to the sentence in the middle of that guidance, mainly:

Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in.

Searching on how to do this I noticed that others were suggesting a command line similar to this:

$ tcpdump -nnXSs 0 'port 80'
  • "-nn" makes it not lookup hostnames in DNS and service names (in /etc/services) for respectively faster and cleaner output.
  • "-X" makes it print each packet in hex and ascii; that's really the useful bit for tracking headers and such
  • "-S" print absolute rather than relative TCP sequence numbers - If I remember right this is so you can compare tcpdump outputs from multiple users doing this at once
  • "-s 0" by default tcpdump will only capture the beginning of each packet, using 0 here will make it capture the full packets.

I would suggest adding the -nn to see if that improves your performance, thus causing less data to be buffered, and hopefully protecting more of the data from being potentially dropped. The other switches might help, but it is not clear to me how they would help, if at all, in your situation.

References

Share:
27,795

Related videos on Youtube

DisplayName
Author by

DisplayName

Updated on September 18, 2022

Comments

  • DisplayName
    DisplayName almost 2 years

    I'm using

    sudo tcpdump -A -s0 -ien0 port 80 | grep schemas-microsoft >> ~/Downloads/convert.txt
    

    to capture microsoft-schema xmls being sent throught the internet, when tcpdump is supposed to capture: (for example)

    <xml>
     <sample>h</sample>
     <samp2>j</sample>
    </xml>
    

    it only captures:

    <xml>
    <sample>h</sample
    <sam
    

    And stops randomly somewhere in the file. What could this be due to?

  • DisplayName
    DisplayName over 9 years
    sudo tcpdump -nnXSs 0 'port 80' | grep schemas-microsoft doesn't show anything at all?
  • slm
    slm over 9 years
    Without the grep do you get output?
  • DisplayName
    DisplayName over 9 years
    Yeah, but the meaning of this was grepping the output like that, any idea?
  • slm
    slm over 9 years
    @DisplayName - as I said in the A, the rest of the switches are questionable to me, but are often shown for similar examples. I'd omit the -X switch and go with -A for starters. Does that show the schema-microsoft?