Jump to content

TCPDump half / more packets dropped by Kernel

Recommended Posts


I'm new to PS. when testing the TCPdump function, i see that not all packets are captured by PS.

I ran the TCPDump in armed mode and after a minute i stopped the process, i see a lot of packets are dropped by the kernel.
I did the same in bridged mode with the same result.

anybody an idea how i can collect all the packets?
Maybe a better method? or is PS to lightweight to capture all packets?

thanks in advanced,



Link to post
Share on other sites

Can you give me a few examples and I can try to repeat the process with mine?  I've only done a packet capture a few times and it seemed like it was all there...but that was several years ago.  Thanks.

Link to post
Share on other sites

Hello Bob123,

Thank you for your reply. 

I will try to explain it. if you would like i could make a video screen next time. 

i did the following. 

I have connected my computer to the Ethernet IN of the PS and  Ethernet OUT to my router. 

I putted the PS in army mode. 
I opened SSH and typed tcpdump -i eth0 -s 65535 -w /mnt/loot/tcpdump/traces.pcap in the terminal window. 

I started downloaded a file that is 700mb big. Offcourse i didn't actually downloaded the whole file. i interrupted it at approximately 50MB. 
When i look at my loot folder, i see that my traces.pcap is only 7MB. 

When you stop the tcpdump command in the terminal window, i see the following message. 

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
8077 packets captured
66286 packets received by filter
58208 packets dropped by kernel

I have downloaded the payload from github and adapt it a bit so tcpdump would make x files of y mb and loop. 
but the result stays the same. i have the idea that not all packets are captured, but dropped by the kernel. 



# Title:        TCPDump
# Description:    Dumps networking-data to USB storage. Completes on button-press or storage full.
# Author:         Hak5
# Version:        1.0
# Category:        sniffing
# Target:         Any
# Net Mode:        TRANSPARENT

# LEDs
# SUCCESS:        Dump complete
# FAIL:            No USB storage found

function monitor_space() {
    while true
        [[ $(df | grep /mnt | awk '{print $4}') -lt 10000 ]] && {
            kill $1
            LED G SUCCESS
        sleep 5

function finish() {
    # Kill TCPDump and sync filesystem
    kill $1
    wait $1

    # Indicate successful shutdown
    sleep 1

    # Halt the system

function run() {
    /etc/init.d/sshd start &

    # Create loot directory
    mkdir -p /mnt/loot/tcpdump &> /dev/null
    # Set networking to TRANSPARENT mode and wait five seconds
    sleep 5
    # Start tcpdump on the bridge interface
    #tcpdump -i br-lan -s 0 -w /mnt/loot/tcpdump/dump_$(date +%Y-%m-%d-%H%M%S).pcap &>/dev/null &
    tcpdump -i br-lan -s 65535 -w /mnt/loot/tcpdump/traces.pcap -W 50 -C 75 &>/dev/null &
    # Wait for button to be pressed (disable button LED)
    NO_LED=true BUTTON
    finish $tpid

# This payload will only run if we have USB storage
[[ ! -f /mnt/NO_MOUNT ]] && {
    run &
    monitor_space $! &
} || {


Link to post
Share on other sites
On 8/4/2020 at 11:31 AM, Peter Luykx said:

    # Start tcpdump on the bridge interface
    #tcpdump -i br-lan -s 0 -w /mnt/loot/tcpdump/dump_$(date +%Y-%m-%d-%H%M%S).pcap &>/dev/null &
    tcpdump -i br-lan -s 65535 -w /mnt/loot/tcpdump/traces.pcap -W 50 -C 75 &>/dev/null &

Technically, the packet shouldn't be more that 0xffff(65535) in size, but this is what the man page looks like for tcpdump:


       -s snaplen
              Snarf snaplen bytes of data from each packet rather than the default of 262144 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 262144, for backwards compatibility with recent older versions of tcpdump.

0x40000(262144) is greater than 0xffff(65535), so you might be cutting off packets if you limit yourself to 65535. try using -s 0 which is setting it to the max size.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...