Lots of packet drop in tcpdump tool

[sujeetkumar]

Actually i am using tcpdump tool to monitor packets in wireless network interface.

When i terminated tcpdump with Ctrl+C after few seconds and got this total summary as output:

# tcpdump -i wlan1 -s 0 -vvv 
...

313 packets captured
17320 packets received by filter
16987 packets dropped by kernel

Why is there such big dropped in number of packets captured by tcpdump?

After searching solution from the google i also tried with adding option -B 32768 with tcpdump in command line but still getting same lots of packet drop.

# tcpdump -i wlan1 -s 0 -vvv -B 32768

So how can i capture all packets at high bandwidth without dropping any packets?

Thanks in advance!

[lleachii]

Take a look at this:

@lleachii

That's normal. I think you grossly misunderstand what the output means if it concerns you:

dropped by kernel (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0).

~ from the manual

@sujeetkumar

So how can i capture all packets at high bandwidth without dropping any packets?

What device are you running?

Please provide the output of:

ubus call system board

[_bernd]

I would also use -nN to not resolve hostnames and services and in addition --immediate-mode. And yes my gut feeling says that maybe the device is to slow or the buffer is to small....

[sujeetkumar]

@lleachii

ubus call system board

root@OpenWrt:~# ubus call system board
{
        "kernel": "5.10.138",
        "hostname": "OpenWrt",
        "system": "ARMv7 Processor rev 5 (v7l)",
        "model": "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1",
        "board_name": "qcom,ap-dk01.1-c1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "22.03.0",
                "revision": "r19685-512e76967f",
                "target": "ipq40xx/generic",
                "description": "OpenWrt 22.03.0 r19685-512e76967f"
        }
}

i also tried with increasing the buffer size value.

[lleachii]

@sujeetkumar

"model": "Qualcomm

@sujeetkumar

"board_name": "qcom,ap-dk01.1-c1

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

[moeller0]

@sujeetkumar

-s 0

Instead of trying to capture full sized packets, maybe use -s 128 to only store the first 128 byte that should contain most/all headers? That way the same kernel buffer will suffice for more captured packets, which should reduce the number of dropped packets some.

[sujeetkumar]

@lleachii

It appears you are using firmware that is not from the official OpenWrt project.

No...

The firmware I'm using is built from the standard OpenWrite project.

[frollic]

@sujeetkumar

The firmware I'm using is built from the standard OpenWrite project.

from <> by, can you provide an openwrt.org DL link for the firmware ?

22.03.0 is EOL anyway, you should upgrade to .7.