What's the difference between "errors:" "dropped:" "overruns:" and "frame:" fields in ifconfig RX packets output?

Question

Can someone please elaborate on the difference between the various RX packets fields in ifconfig output?

For example, let's say I run ifconfig and see the following:

eth0      Link encap:Ethernet  HWaddr AA:BB:CC:DD:EE:FF  
          inet addr:1.1.1.1  Bcast:1.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:202723544 errors:0 dropped:4959 overruns:0 frame:37
          TX packets:158354057 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4261083782 (3.9 GiB)  TX bytes:1224803677 (1.1 GiB)
          Interrupt:83 Memory:f6bf0000-f6c00000 

What is the difference between errors: dropped: overruns and frame:

My guess at this point (based on some vague googling) is that frame: specifically pertains to CRC failures when the nic analyzes incoming frames and that errors: is a broader generic category. Then again... if that were the case, I would expect both of those fields to show numbers.

Answer 1

That information is poorly documented. I will tell you what I understand from my experience.

• frame counts only misaligned frames, it means frames with a length not divisible by 8. Because of that length is not a valid frame and it is simply discarded.

• Meanwhile errors counts CRC errors, too-short frames and too-long frames.

• overruns counts that times when there is FIFO overruns, caused by the rate at which the buffer gets full and the kernel isn't able to empty it.

• At last, dropped counts things like unintended VLAN tags or receiving IPv6 frames when the interface is not configured for IPv6.

Answer 2

I know this is a 1 year old question but it is 1st on Google so maybe I can add 5 cents to it.

First I was not aware of this mod 8 rule on frame field... Is it a driver rule or kernel rule?

In the little experience I have, these numbers are quite generic and more info can be obtained from ethtool (if the driver supports it) ex: this is from watch command.

Every 1s: ethtool -S eth1 | grep rx_ && echo  && ifconfig eth1                                                   1970-01-01 00:21:07

 rx_octets: 12635134290
 rx_frames: 8488675
 rx_broadcast_frames: 103
 rx_multicast_frames: 0
 rx_pause_frames: 0
 rx_64_byte_frames: 113
 rx_65_127_byte_frames: 47
 rx_128_255_byte_frames: 186340
 rx_256_511_byte_frames: 1
 rx_512_1023_byte_frames: 0
 rx_1024_1518_byte_frames: 8302174
 rx_greater_than_1518_byte_frames: 0
 rx_undersized_frames: 0
 rx_oversize_frames: 0
 rx_jabbers: 0
 rx_frame_check_sequence_errors: 0
 rx_length_field_frame_errors: 0
 rx_symbol_errors: 0
 rx_alignment_errors: 0
 rx_resource_errors: 283
 rx_overruns: 132
 rx_ip_header_checksum_errors: 0
 rx_tcp_checksum_errors: 0
 rx_udp_checksum_errors: 0

eth1      Link encap:Ethernet  HWaddr AA:BB:CC:DD:20:16  
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::a8bb:ccff:fedd:2016/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:8488675 errors:415 dropped:4 overruns:132 frame:283
          TX packets:647464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3892403548 (3.6 GiB)  TX bytes:62273943 (59.3 MiB)
          Interrupt:147 Base address:0xc000 

Depending on the driver there will be different fields in ethtool and ifconfig fields can point to undersized/oversized frames as well.

If your NIC & driver supports it you can (or should) do ex:

ifdown eth1 && modprobe -r macb && modprobe macb && ifup eth1 && ethtool -offload  eth1  rx off  tx off && ethtool -K eth1 gso off && ethtool --show-offload eth1

in order to get more info (enable letting the info to be shown in ethtool). I'm using macb driver here... so check ethtool for your driver.

ethtool -i eth1

This is what helps me to understand usually what's going on.

Sometimes there are no errors but packets are corrupted... then it is more of a PHYsical or driver problem... and sometimes sniffers show everything is correct but there is a problem after it gets to the driver/kernel (this is above's case actually).

Some more can be obtained from netstat -s, or if you put this into a script (for small embedded systems):

awk '(f==0) { i=1; while ( i<=NF) {n[i] = $i; i++ }; f=1; next} (f==1){ i=2; while ( i<=NF){ printf "%s = %d\n", n[i], $i; i++}; f=0}'  /proc/net/netstat

since netstat -s might not be available.