The problem

The ifconfig command shows more and more dropped packets in the RX section. So, there seem to be a problem to some packets arriving from the Internet to my server.

The questions

  1. What kind of packets does this drop counter takes into account? Does it take all packets arriving, before reaching the iptables firewall, or after the packets have been accepted by iptables?

  2. How to solve the situation so that the ipconfig drop packets counter stops to increase?

Useful troubleshooting infos

Since I don't know what my problem really is, feel free to ask me to complete this section if you think some other info would be needed.


eth0      Link encap:Ethernet  HWaddr 00:cc:cc:cc:cc:cc  
          inet adr:  Bcast:  Masque:
          adr inet6: fe80::21c:c0ff:feb9:829c/64 Scope:Lien
          adr inet6: 2001:a100:1:bbbb::1/64 Scope:Global
          RX packets:113264620 errors:0 dropped:2523 overruns:0 frame:0
          TX packets:168526529 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:59171827564 (55.1 GiB)  TX bytes:223993117711 (208.6 GiB)

Note the "dropped:2523" in the RX section. This is the most important. This number is continuously increasing.

ip -4 route show

default via dev eth0 dev eth0  proto kernel  scope link  src

ip -6 route show

2001:a100:1:bbbb::1/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2001:a100:1:bbff:ff:ff:ff:ff dev eth0  metric 1024

munin graph of plugin if_err_eth0_day

enter image description here

  • 1
    ifconfig will be before the firewall. They are interface-level statistics. This link may offer one troubleshooting option. – PP. Aug 2 '13 at 16:08
  • I have already tried this, unfortunately the answer is Ring parameters for eth0: Cannot get device ring settings: Operation not supported – Fox Aug 2 '13 at 16:14
  • You're dropping 0.002% of incoming packets. Why are you worrying about it? – freiheit Aug 2 '13 at 23:19
  • 3
    Because it didn't happen before and suddenly started. A good configuration shows ZERO dropped packet (they should be dropped later, if needed, by the firewall). There is a loss of information which should reach my server and I want to know why. – Fox Aug 3 '13 at 0:08
  • 1
    @Fox: Did you find the reason for the packet-drops? I'm facing the same problem on my new rooter-server. – Biggie Feb 20 '15 at 13:49


Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet count. Before, dropped packets was most likely due to an error. Now, the rx_dropped counter shows statistics for dropped frames because of:

  • Softnet backlog full
  • Bad / Unintended VLAN tags
  • Unknown / Unregistered protocols
  • IPv6 frames when the server is not configured for IPv6


If the rx_dropped counter stops incrementing while tcpdump is running; then it is more than likely showing drops because of the reasons listed earlier.

| improve this answer | |

I've been trying to track down this issue too to no avail. I've also noticed RX packet drops at the rate of about one per second on my Ubuntu 12 box. From my searching I've found people with similar issues on various other linux platforms, SUSE, Rpi, and others. Seems like something with the linux kernel. Some more interesting clues that I've noticed make the issue disappear temporarily, but not exactly explanations.

  1. If I change my config from static to DHCP in my /etc/network/interfaces the RX packet drops cease.Maybe the unrecognized packets t have something to do with DHCP and when it's off the box doesn't know what to do with them?

  2. If I run a tcpdump the packet drops cease while the dump is running and come back when I stop it.

Maybe these clues will help get to the bottom of this?

Overall my network performance appears to be just fine, just curious to as why this is happening too.

| improve this answer | |
  • Same here, super consistent rate of 1/s (seems like they come in groups of 2 every other second, but don't quote me on that until I can actually observe them) and when I start tcpdump there is suddenly no issue anymore for the duration of the packet capture. Also with --no-promiscuous-mode it still resolves the issue O.o – Luc Jan 31 at 17:32

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.