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.

Solution 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.

Solution 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.

Comments

[Mike B]

Thanks. I found blog post with similar findings. blog.hyfather.com/blog/2013/03/04/ifconfig

[kostix]

Thanks for heads-up on ethtool -S

[mdo123]

How did you figure this out, where are your sources? I'm curious because I'm looking for these answers myself and can't seem to find them anywhere but blogs, or posts such as this. Any man pages or official documentation?

[John]

@slm Does 'errors' count the checksum(which is involved in TCP header) error?