This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I have a pcap file. how can I filter out those dropped package by the linux kernel?

0

Recently, I find one of my server face a drop package problem in a specific minute

netstat -in
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
bond0      1500   0 1418046670      0    743      0 1047132418      0      0      0 BMmRU
bond1      1500   0 92980025302      3     79      0 54995070900      0      0      0 BMmRU
eth0       1500   0 924882226      0      0      0 761949059      0      0      0 BMsRU
eth1       1500   0 493164444      0    743      0 285183359      0      0      0 BMsRU
eth4       1500   0 92979828163      3     79      0 54995070878      0      0      0 BMsRU
eth5       1500   0   197139      0      0      0       22      0      0      0 BMsRU
lo        16436   0 37524597      0      0      0 37524597      0      0      0 LRU

I have use following tcpdump to capture the the eth1 traffic during that minute.

tcpdump -i eth1 -w /tmp/drop_find.pcap

How can I filter out the dropped package by the kernel or something else in this pcap file using wireshark?

Or how do I know which package is dropped by the destination? can those dropped package by destination can be captured by tcpdump?

asked 24 Nov '13, 08:14

newcryout's gravatar image

newcryout
1●1●1●1
accept rate: 0%

here is the uploaded tcpdump pcap file.

drop_link.pcap

(24 Nov '13, 08:28) newcryout

One Answer:

0

How can I filter out the dropped package by the kernel or something else in this pcap file using wireshark?

you probably can't, as the kernel might have dropped the packets due to a lack of buffer space. If that was the case, libpcap (the capture library of tcpdump) will never have seen those packets either, so those dropped packets are not in the capture file.

There is a small chance, that the packets have been dropped due to a frame checksum error. In that case you might (or might not) see those frames in the capture file. It depends where and when the kernel drops that kind of packets.

Please apply the following display filter: expert.message contains "checksum"

Or how do I know which package is dropped by the destination? can those dropped package by destination can be captured by tcpdump?

To see those dropped frames you need to do this:

  • capture all frames in front of the system, on a mirror/monitor port of the switch, with another PC
  • at the same time capture all frames on the system (with tcpdump)
  • compare the two capture files. Those frames that are in the 'external' capture file, but are missing in the 'internal' file, will be the dropped frames.

Regards
Kurt

answered 24 Nov '13, 08:28

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 24 Nov '13, 08:34

here is the uploaded tcpdump pcap file.

O.K. there are no checksum errors in that file, so I guess the dropped frames are being caused by missing buffer space at some time. In that case, please follow the procedure I mentioned.

(24 Nov '13, 08:32) Kurt Knochner ♦

Hi Kurt,

Thanks for the quick response. And you have give me a great idea of the mirror the port. before I do that, I have little more question for this drop package thing.

As you have mentioned that, when package drop because of lack of buffer and checksum. these package will never seen by tcpdump.

so if there is any other possibility that some package dropped by other reason can be seen by tcpdump (libpcap)?

or I can say, all the package dropped by the kernel will never be captured by tcpdump (libpacap)?

as I know all the tools used to capture package in linux are using the libpcap. I don't know if this libpcap can do some capture operation before linux kernel drop packages.

because this eth1 is a slave NIC for the bond0. the traffic in the eth1, should be very low. this can be confirm in the pcap file I have attached. so I think the kernel will not drop the package because of the out of buffer reason.

(24 Nov '13, 09:08) newcryout

so if there is any other possibility that some package dropped by other reason can be seen by tcpdump (libpcap)?

I can't tell you. I have seen both cases. Packtes being dropped by the kernel were seen by libpcap and some were not depends on the reason for the drop.

or I can say, all the package dropped by the kernel will never be captured by tcpdump (libpacap)?

see above.

so I think the kernel will not drop the package because of the out of buffer reason.

Who knows. Maybe there was a microburst with lots of traffic to a multicast IP/MAC address and at some time your kernel buffer was filled for a short period of time.

(24 Nov '13, 10:43) Kurt Knochner ♦