Bug 76849 - Wrong transmit data on /proc/net/dev with isdn (ippp0)
Wrong transmit data on /proc/net/dev with isdn (ippp0)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-28 01:50 EST by Eddy Nigg
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eddy Nigg 2002-10-28 01:50:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461; .NET 
CLR 1.0.3705)

Description of problem:
Installed one or more isdn cards, using driver hisax. /proc/net/dev reports at 
transmit only data for the master channel, but not for slaves. Recieve is OK. 
All other devices (eth) are OK.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Use ISDN with hisax driver (also other drivers???)
2.Put some load on the ISDN
3.Run "cat /proc/net/dev | grep "ippp0"
4.Recieve is OK, transmit not.
	

Actual Results:  Transmit is wrong

Expected Results:  Should be right....:-)

Additional info:
Comment 1 Eddy Nigg 2002-10-28 01:54:56 EST
Notified also fritz@isdn4linux.de and keil@isdn4linux.de authors of isdn and 
hisax driver
Comment 2 Need Real Name 2003-08-06 18:00:04 EDT
I have seen cases where the byte counts (both transmit and receive) 
in /proc/dev/net go up to 2^32-1 (over 4 gig) then stop counting. I'm not sure 
whether this is coming from the driver or not; the code that prints this is 
in /usr/src/linux/net/core/dev.c:

#ifdef CONFIG_PROC_FS

static int sprintf_stats(char *buffer, struct net_device *dev)
{
        struct net_device_stats *stats = (dev->get_stats ? dev->get_stats(dev): 
NULL)
;
        int size;

        if (stats)
                size = sprintf(buffer, "%6s:%8lu %7lu %4lu %4lu %4lu %5lu %10lu 
%9lu
%8lu %7lu %4lu %4lu %4lu %5lu %7lu %10lu\n",
                   dev->name,
                   stats->rx_bytes,
                   stats->rx_packets, stats->rx_errors,
                   stats->rx_dropped + stats->rx_missed_errors,
                   stats->rx_fifo_errors,
                   stats->rx_length_errors + stats->rx_over_errors
                   + stats->rx_crc_errors + stats->rx_frame_errors,
                   stats->rx_compressed, stats->multicast,
                   stats->tx_bytes,
                   stats->tx_packets, stats->tx_errors, stats->tx_dropped,
                   stats->tx_fifo_errors, stats->collisions,
                   stats->tx_carrier_errors + stats->tx_aborted_errors
                   + stats->tx_window_errors + stats->tx_heartbeat_errors,
                   stats->tx_compressed);
        else
                size = sprintf(buffer, "%6s: No statistics available.\n", dev-
>name);

        return size;
}

I'm suspicious of the "%8lu" format. I looked at a few of the drivers and the 
stats do appear to be 64 bits.
Comment 3 Eddy Nigg 2003-08-06 18:58:36 EDT
The bug I reported concerns only ISDN connections with slave configuration. 
However the comment from znmeb@aracnet.com is interesting too...

I did not get any answers until today. I have some ISDN backup connection with 
a master channel and many slave channels. However the transmit (UP) is 
reporting only the bytes of the master channel, even so the line is actually 
transmitting much more. 

Maybe the designers of isdn4linux never thought of this possibility??

Comment 4 Bugzilla owner 2004-09-30 11:40:08 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.