Bug 56584 - (NET 8139TOO) Network connection lost in few mins
(NET 8139TOO) Network connection lost in few mins
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Jay Turner
:
: 56586 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-21 08:12 EST by Need Real Name
Modified: 2015-01-07 18:53 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-05 15:29:05 EST
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 Need Real Name 2001-11-21 08:12:20 EST
Description of Problem:

When i boot the linux system everything seems to be fine even the network 
, i can able to connect to the network , telnet it and everything.After 
few minutes the network drops out.It happens constantly.I have tried with 
network restart samba restart and ifconfig up/down.But no use.All of a 
sudden i can see the network from my windows machine , if i ping it its 
coming with reply followed by request time out.It happens constantly.The 
network is not at all consistant.

Version-Release number of selected component (if applicable):
red hat linux 7.1

How Reproducible:
i can reproduce this every time

Steps to Reproduce:
1. boot the sytem ping it from someother system or even telnet it
2. wait and watch , after few mins the network drops u cant even do 
anything
3. its disappering from the network neighbourhood.

Actual Results:
   network dropping
 
Expected Results:
  i should be able to see the network

Additional Information:
  iam using Ethernet RTL 8139
Comment 1 Greg DeKoenigsberg 2001-11-27 16:48:20 EST
This is not an RHN bug.  Jay, please reassign or close as you see fit.
Comment 2 Cristian Gafton 2002-04-12 00:38:17 EDT
*** Bug 56586 has been marked as a duplicate of this bug. ***
Comment 3 Cristian Gafton 2002-04-12 00:39:21 EDT
dcm can figure it out
Comment 4 Greg DeKoenigsberg 2002-05-07 12:18:12 EDT
Changing the component to get this in the right bug list
Comment 5 Trond Eivind Glomsrxd 2002-05-07 14:32:06 EDT
Uh... there's no indication at all of this being a samba bug. The report says
networking in general stops working. I'd expect NAT timeouts, but it's not a
samba bug. If it is a software bug (which I doubt), it would be a kernel
issue... does dmesg say anything?
Comment 6 Christopher Chan 2002-10-10 10:52:44 EDT
I am also having recurring problems with my network connection (using a realtek
8139 nic)...I use pppoe on this particular connection
I have no problems with my internal connection which is an Intel nic

I am using 2.4.9-34athlon on a Duron box. RH7.1

dmesg does not say anything but I did find a few lines like the one below
Oct 10 22:39:52 ctp pppoe[860]: Bad TCP checksum bfff

ping the machine from another generated some out of the ordinary messages during
the periods when I have lost connectivity to the box.

[chris@admin odsclient-1.02]$ ping diverse-computing.nofw.org
PING diverse-computing.nofw.org (203.218.19.154) from 192.168.1.11 : 56(84)
bytes of data.
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=2 ttl=248
time=1072 ms
wrong data byte #14 should be 0xe but was 0x0
#8      8 9 a b c d 0 90 1a 1 3 55 0 50 fc 28 71 98 88 64 11 0 1c 71 0 56 0 21
45 0 0 54
#40     ab 72 0 0 ff 1 6f af cb da 13 9a ca 51 f6 c0
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=7 ttl=248
time=1046 ms
wrong data byte #14 should be 0xe but was 0x0
#8      8 9 a b c d 0 90 1a 1 3 55 0 50 fc 28 71 98 88 64 11 0 1c 71 0 56 0 21
45 0 0 54
#40     ab 77 0 0 ff 1 6f aa cb da 13 9a ca 51 f6 c0
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=9 ttl=248
time=46.3 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=10 ttl=248
time=44.7 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=11 ttl=248
time=45.8 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=12 ttl=248
time=44.2 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=13 ttl=248
time=45.7 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=14 ttl=248
time=52.7 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=15 ttl=248
time=49.6 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=16 ttl=248
time=109 ms

--- diverse-computing.nofw.org ping statistics ---
16 packets transmitted, 10 received, 37% loss, time 15132ms
rtt min/avg/max/mdev = 44.265/255.780/1072.286/402.226 ms, pipe 2
[chris@admin odsclient-1.02]$ ping diverse-computing.nofw.org
PING diverse-computing.nofw.org (203.218.19.154) from 192.168.1.11 : 56(84)
bytes of data.
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=2 ttl=248
time=1050 ms
wrong data byte #14 should be 0xe but was 0x0
#8      8 9 a b c d 0 90 1a 1 3 55 0 50 fc 28 71 98 88 64 11 0 1c 71 0 56 0 21
45 0 0 54
#40     ab 82 0 0 ff 1 6f 9f cb da 13 9a ca 51 f6 c0

--- diverse-computing.nofw.org ping statistics ---
8 packets transmitted, 1 received, 87% loss, time 7020ms
rtt min/avg/max/mdev = 1050.109/1050.109/1050.109/0.000 ms, pipe 2
[chris@admin odsclient-1.02]$ ping diverse-computing.nofw.org
PING diverse-computing.nofw.org (203.218.19.154) from 192.168.1.11 : 56(84)
bytes of data.
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=2 ttl=248
time=1064 ms
wrong data byte #14 should be 0xe but was 0x0
#8      8 9 a b c d 0 90 1a 1 3 55 0 50 fc 28 71 98 88 64 11 0 1c 71 0 56 0 21
45 0 0 54
#40     ab 8a 0 0 ff 1 6f 97 cb da 13 9a ca 51 f6 c0
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=8 ttl=248
time=57.7 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=9 ttl=248
time=56.5 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=10 ttl=248
time=65.2 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=11 ttl=248
time=58.6 ms
64 bytes from pcd174154.netvigator.com (203.218.19.154): icmp_seq=12 ttl=248
time=70.0 ms

--- diverse-computing.nofw.org ping statistics ---
12 packets transmitted, 6 received, 50% loss, time 11133ms
rtt min/avg/max/mdev = 56.509/228.856/1064.946/373.940 ms, pipe 2
Comment 7 Christopher Chan 2002-10-12 09:29:17 EDT
I haven't had time to investigate but today 13th Oct, 2002 when I sshed into my
box on the internal side, (Intel nic) I had weird but short periods of no
response from the box that I never had before when using the kernel that comes
with RH7.1...

e.g. typing in putty...there would be periods where nothing seems to have been
typed...the box is not loaded and this is over 100Mbits/second switched network...
Comment 8 Christopher Chan 2002-10-12 09:30:24 EDT
sorry, 12th October...
Comment 9 Jeff Garzik 2002-10-25 14:27:01 EDT
Can you reproduce with current errata kernel or 8.0 kernel?
(or stock kernel.org kernel 2.4.20-preXX?)
Comment 10 Christopher Chan 2002-10-28 00:10:17 EST
Yes. It still happens with the current errata kernel....

uname -a
Linux ctp 2.4.18-17.7.x #1 Tue Oct 8 11:49:30 EDT 2002 i686 unknown

No errors or odd messages in dmesg or /var/log/messages....

Unfortunately I am not on site right now when these problems started so I cannot
verify whether I still get the odd delays when using ssh on the internal nic (Intel)

The ping results that follow are the ones to the pppoe connection via the
realtek-based nic.

PING diverse-computing.nofw.org (203.218.231.11) from 192.168.2.65 : 56(84)
bytes of data.
64 bytes from pcd441011.netvigator.com (203.218.231.11): icmp_seq=9 ttl=55
time=1025 ms
wrong data byte #14 should be 0xe but was 0x0
#8      8 9 a b c d 0 90 1a 1 3 55 0 50 fc 28 71 98 88 64 11 0 17 d0 0 56 0 21
45 0 0 54
#40     f2 3 0 0 40 1 2b f4 cb da e7 b ca 4d df 7d
64 bytes from pcd441011.netvigator.com (203.218.231.11): icmp_seq=10 ttl=55
time=1076 ms
wrong data byte #14 should be 0xe but was 0x0
#8      8 9 a b c d 0 90 1a 1 3 55 0 50 fc 28 71 98 88 64 11 0 17 d0 0 56 0 21
45 0 0 54
#40     f2 4 0 0 40 1 2b f3 cb da e7 b ca 4d df 7d
64 bytes from pcd441011.netvigator.com (203.218.231.11): icmp_seq=20 ttl=55
time=1025 ms
wrong data byte #14 should be 0xe but was 0x0
#8      8 9 a b c d 0 90 1a 1 3 55 0 50 fc 28 71 98 88 64 11 0 17 d0 0 56 0 21
45 0 0 54
#40     f2 e 0 0 40 1 2b e9 cb da e7 b ca 4d df 7d

--- diverse-computing.nofw.org ping statistics ---
23 packets transmitted, 3 received, 86% loss, time 22018ms
rtt min/avg/max/mdev = 1025.599/1042.477/1076.152/23.826 ms, pipe 2
Comment 11 Christopher Chan 2002-12-12 09:22:54 EST
are you saying that this is a 8139 specific problem?

I never had this problem in the stock 7.1 kernel(the 2.4.2) and it only appeared
in the 2.4.9-xx kernels and beyond.  Connectivity being and lost and regained
occurs with both NIC's whether Realtek or Intel.
Comment 12 Dave Jones 2003-12-16 22:21:27 EST
And with the 2.4.20 errata kernels ?
(or even current distros ?)

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