I simulated a Denial-of-Service attack by connecting two virtual machines, i.e. attack and victim machine. The attack machine sends lots of traffic (http) against the victim machine running an application (web server).

I run tshark at the victim. At the end of a monitoring session, I see a tshark message indicating that some packets were dropped.

How do I know who dropped the packet: tshark, the application (web server), or the machine (in this case Ubuntu), or any other resource I haven't thought of? What sort of tests can I perform to verify that?

1 Answer 1


tsharck won't tell you about packet dropped by the web server or any other application or daemon. It won't tell about packet dropped at the source. It will tell only about packet received on the wire that could not be processed.

Packets can be dropped at any of the following steps, if that's too much for that step to handle:

  • packet receive by the network card driver
  • kernel receiving and duplicating packet to send to tshark
  • tshark reading packets (and filtering or decoding if either was requested)
  • tshark output for processed packets, either to display or to disk.

To prevent packet drop, try to alleviate these steps, starting by the later ones. For example, try to

  • reduce packet processing by just dumping raw packets to disk, and to a fast enough disk (SSD speed or similar is recommended)
  • when capturing to disk, to see if packet dropping is due to file writing not keeping up, check if capturing to /dev/null reduce packet dropping. If it does, try again capturing to file, but with increased capture buffer using -B <size in MiB> option, for example -B 100.
  • look for bottlenecks on your system (network card or driver overload, CPU or IRQ overload, etc.)
  • The command is tshark -i 3 -a duration:15 -w filename.pcap. After the 15 sec monitoring duration, the message is Capturing on 'eth2' <cr> 9357 <cr> 721 packets dropped.
    – Curioso
    Oct 21, 2015 at 10:59
  • thanks for these details. I updated my answer with proposal to test capture to /dev/null, and try increasing the capture buffer with -B option. Also added that tsharck will only report packet dropped at its end. So capturing at the receiving end won't tell about packet drops that could occur at the sending end.
    – CuriousFab
    Oct 22, 2015 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.