Linux

RESETTING THE COUNTERS

Lets say you want to reset all of the counters to 0.

Given this, we need this:

# ifconfig eth0
RC packets:12341234 errors: 0 dropped:0 overruns:0 frame:0
TX packets:61123 errors:0 dropped:0 overruns:0 carrier:2
collisions: 0 txqueuelen:1000
RX bytes: 1234123412 (1.8 GB) TX bytes: 86012341234 (86.0 MB)

You want this:

# ifconfig eth0
RC packets:0 errors: 0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions: 0 txqueuelen:1000
RX bytes: 0 (0.0 B) TX bytes: 0 (0.0 MB)

 REQUIREMENTS:

– have ethtool: apt-get install ethtool
– Have a physical connection to the device:
If you only have a network connection to a device this will be impossible, unless you have another means of connection to the device such as via

THE CATCH:

There are 2 situations, one in which you can reset the counters and one in which you cant.

The current way to reset the counters is to just disable the driver and then renable it. Not all drivers can be disables. Here are the 2 situations.

STEPS:

Lets find out if your in 1st or 2nd situation.

Look at the counters and identify the interface name:

# ifconfig

In this case its eth0, lets get the driver name:

# ethtool -i eth0
driver: e1000e

Here the driver name showed me the interface is e1000e (this is an Intel driver)

We will run “# modprobe -D DRIVERNAME” and based on the output find out if you can reset them or not.

# modprobe -D e1000e
insmod /lib/modules/3.1.3.5-vanillaice/kernel/drivers/pps/pps_core.ko
insmod /lib/modules/3.1.3.5-vanillaice/kernel/drivers/ptp/ptp.ko
insmod /lib/modules/3.1.3.5-vanillaice/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko

The above output shows that the driver is dependent on other drivers, and mainly it doesnt say that its kernel built-in driver. Thus this is situation 1 and you can reset the counters.

Another example of situation 1 is very similar output, but take the Atheros atl1c driver on my PC (the driver in this case is also not kernel built-in).

# modprobe -D atl1c
insmod /lib/modules/3.13.5-vanillaice/kernel/drivers/net/ethernet/atheros/atl1c/atl1c.ko

The above is also module driver (even though it doesnt list any dependencies but only lists it self). Thus this falls into the case that you can reset the counters.

OR…

Below is the other type of output from modprobe -D

# modprobe -D e1000e
modprobe: module e1000e is builtin

The above is situation 2, the driver is kernel-built in. Thus you cant reset the counters

Here is the summary of both cases:

…1… DRIVER MODULE
If your driver is not kernel-built in but it is a module that is added in via “insmod” or “modprobe”. Therefore you can see it with “lsmod”.

First run ifconfig to get the interface name:

# ifconfig

Now run ethtool to get the driver name (or however you want to get the driver name). Lets imagine its eth0.

# ethtool -i eth0

In this case lets pretend the driver name DRIVERNAME. Now check that the driver is not a kernel built-in driver with modprobe.

# modprobe -D DRIVERNAME

If it doesnt say “kernel built-in” then you can proceed with resetting the counters (By first removing/disabling the driver). If it says the driver is “kernel built-in” then you cannot proceed with resetting the counters (read …2… below).

Remove the driver (This doesnt really remove the driver, it just disables it):

# modprobe -r DRIVERNAME

At this point if you were sshed/telneted in or connected via network protocol, you will lose connection and you will need to reconnect physically to the PC/device via console or physical acccess (keyboard/monitor)

Now you can enable the driver:

# modprobe DRIVERNAME

Now look at the counters they should be all 0:

# ifconfig

…2… DRIVER IS KERNEL BUILT-IN

If your drive is kernel built-in, then there is no way currently to reset the driver. As you cant turn off the driver and reenable it. Currently that is the only way to reset those counters.

Why cant we reset drivers that are kernel built-in? Check out this link

http://www.ducea.com/2006/09/08/resetting-ifconfig-counters/

Author says:

  • ” module built-in the kernel: in this case there is no way to reset the counters (of course without rebooting the system) if the particular network module driver has not a way to reset them using some code written inside the driver. From what I have seen in the source code of the modules I had used, none of them had such a software hook. But there might be other modules that offer this functionality just that I have not personally seen it on the common NIC drivers I have used.”

 

4 thoughts on “Resetting the RX/TX and Error Counters on ifconfig”

    1. Wow! Cool stuff, I love kernelling – im a noob at it, but I love it.

      UPDATE – TRIED “crash”, BUT IT DIDNT WORK, GOT “.gnu_debuglink missing” ERROR – SEEMS MIGHT NEED TO RECOMPILE KERNEL…

      Well I tried “crash”, but it seems that it doesnt work for every kernel. Here is my troubles with using “crash” a couple of minutes: If we are going to be “crash”ing a live machine we need the kernel vmlinuz file & /dev/mem (luckily your article explains what to do if its locked, and for it wasnt). The problem is the vmlinuz file, not all OS provide kernels vmlinuz files (such as containers from openvz), and if they are provided they might be hidden (such as on a NAS device from certain vendors), and if you were to somehow unhide it, you could still face the next problem & another problem after that. The next problem being if you were to get the kernel it could be compressed – lucky for us thats easy fix: decompress with extract-vmlinux.sh
      Check this link out https://github.com/torvalds/linux/blob/master/scripts/extract-vmlinux

      For “crash” you need an extracted kernel/vmlinuz file – Here is how I got it extracted (vmlinux can be extracted via below script, which sits in scritps folder of kernel source code tree):

      wget https://raw.githubusercontent.com/torvalds/linux/master/scripts/extract-vmlinux;
chmod +x extract-vmlinux;
./extract-vmlinux /boot/vmlinuz-3.2.0-4-686-pae > mlinuz-3.2.0-4-686-pae-extracted

      I did mention there might be another problem – here it was for me, lets say we get it extracted (first problem solved), the next problem is the kernel could be compiled without the right module? Im not sure but from my reading it look like the bug im getting here means i dont have the right module:

      Note I ran crash like this:

      crash vmlinuz-3.2.0-4-686-pae-extracted /dev/mem

      Note: My /dev/mem didnt seem to be locked, so I didnt need to unlock at as per your 2nd link.

      Here is the error I got:

      crash: vmlinuz-3.2.0-4-686-pae-extracted: no .gnu_debuglink section
crash: vmlinuz-3.2.0-4-686-pae-extracted: no debugging data available

      I dont have an idea how I can just insert the correct modules (mentioned here http://stackoverflow.com/questions/4168480/no-debugging-data-in-vmlinux) into my current running kernel without doing a full on recompile and telling my bootloader to use this new kernel (the problem is sometimes we cant get access to the bootloader, or at least its a very lengthy process)

      Do you by chance know the fix to .gnu_debuglink, without recompiling the kernel?

      Reply

  2. damn, you’re right. I’m so used to redhat at the office I forgot to test at home on my funtoo.

    Long story short, the “debuginfo” are debugging information in a separate file instead of built in the binary. This allows debugging of a production image without the overhead of debug information. GDB (on which crash is built) works like this.
    To manipulate binary data, we have a few (very useful) tools : strip, objdump, objcopy, ar…
    The idea for the kernel (and its modules) is to compile them with debugging, copy these debug detail to another file (objcopy) and remove them from the bin (strip).

    As long as you are able to compile a kernel with the same options used to get your running one, you don’t need to reboot or change the kernel. We’ll only extract the debug information.

    Sooo, 2 ways to get these debuginfo :
    – If you are using a kernel published by your distribution, most of the time they may provide the debuginfo package (or in another name, like dbgsym for debian).
    If they don’t, you may check for their tutorial on how to compile the kernel, and add a flag they omitted (it’s really distro dependant, just check the help).
    – If you are making your own kernel (like I do on Gentoo) you’ll need to do it by yourself. It may be worth checking the configuration

    “Kernel Hacking => Compile the kernel with debug info”

    A stackoverflow thread looks correct but you’ll need to do it for every kernel module.
    If you want to save some time, you may just do this for the modules loaded :
    for i in $(lsmod|awk 'NR>1{print $1}'); do
    file="$(modinfo -F filename $i)"
    echo ${file#/lib/modules/*/}
    done

    If I got some time, I’ll try to script these steps also…

    Have fun.

    Reply

    1. Yes, please provide that script! all info is appreciated.

      My XMAS wishes:

      (1) I wish there was a guide on how to get “debug” and “crash” running for a live debian system – for a live system thats running a common kernel (which anyone can download via apt-get). this way anyone can debug a common system

      (2) And also if there was a guide on how to get “debug” and “crash” running for a live debian system – for a live system thats running a non-common kernel (a user compiled kernel), and where, of course, the whole kernel source tree is available. this way anyone can debug a non-common system

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *