Bug 10888 - (NET) Impossible to ping card and network
(NET) Impossible to ping card and network
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Garzik
Depends On:
  Show dependency treegraph
Reported: 2000-04-18 00:22 EDT by Stanley Suan
Modified: 2013-07-02 22:04 EDT (History)
4 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Stanley Suan 2000-04-18 00:22:09 EDT
I get very strange bug with nic2003, nic2005 and 3com plug&play

first card are not detecting correctly (bad driver for card) at
autodetection at boot time
I give some course in linux and three teams in laboratory get
the same error.
Impossible to ping own network pc card. (there are one nic2003 or 2005-use
ne.o driver- and one 3com -use 3c59x.o driver-  network card inside). So I
use manually configuration
ifconfig eth0 down, rmmod modules. install modules again, changes modules,
ifconfig eth0, ifconfig and output of netstat -rn are correct
impossible to ping. Mmmm!! change ip number ofr that's work now
incroyable. Mmm may be there procedure to verify same ip adress?? I put two
station in cross connect same result. I reproduced this error on two team.
I didn't know what happen. I get old ne.o and 3c59x.o modules on my redhat
5.2 server but code change so much (library...).
Comment 1 Anonymous 2000-04-26 13:17:59 EDT
I have found a similar problem. It doesn't matter if I use a NE2000, Ne2k-pci or
 DEC 21041 NIC with the appropriate drivers, I get the exact same results.
Symptoms: I can ping the main server, but I can't ping anybody else on the
sub-net. Everyone can ping the machine. I can telnet, ftp, whatever, I just
can't ping anybody but one machine. I have put a sniffer on the wire, and can
follow the conversation between the various machines, and ping is working,
except on the higher layers....Any help?
Comment 2 keith.moore 2000-08-17 07:56:24 EDT
I think the two here are not the same, on the second one, try mounting an NFS
drive.  If this fails it's probably a reverse routing issue (TCP works, but not

To the first, on the same machines, can you get other cards to work properly?

-- Keith Moore
Comment 3 Jay R. Ashworth, http://baylink.pitas.com 2000-10-19 10:47:40 EDT
This seems similar to the problem I'm having; I'll post it here rather than on a new bug for the moment:

RH6.2, Compaq Armada 7730MT laptop, 3c589.  It's been working fine, but a couple of times now, networking's crapped it's drawers, for no apparent 
reason.  The symptoms are these: I can ping the laptop successfully from other machines on the subnet.  If I ping out from the laptop, tcpdump in 
another window can see the outbound ICMP ping and inbound ICMP pong packets... but they never get back up to userland.  The MAC addresses of the 
remote machines, however, *do* get added to the arp table, if they weren't already there.

Removing the default route makes the machine again behave properly WRT the local net.  Adding static routes to remote machines works fine, too.

One other point of note: the ifup script, called from the PCMCIA stuff, seems to add *two* default routes, one with metric 0, and one with metric 1.  
everything is otherwise working ok, this causes networking not to work until one of them is deleted.  Right now, both need to be removed.

This behavior survives the ejection of the 3c589, manual down and up on the if, a reboot, and a power off. 

But it *did* crop up once before, and then go away.  I thought the replacement of the 3c589 was what fixed it, but I see I'm wrong.

The original was a 3c589c, the current card's a TPO.  The cable is, obviously, 10BaseT.

This appears to be a bug in the routing kernel, but I can't pin it down any further than that, just yet.

I'm all over my mailbox on this one; any help will be greatly appreciated; I'll be glad to compile kernels, or swap them, etc, if necessary (I'm a unix guy of 
15 years, and my first Linux box ran .99pl12f for almost 2 years; I've got a bit o' experience on this stuff).

Heeellpppp!  :-)
Comment 4 Jay R. Ashworth, http://baylink.pitas.com 2000-10-19 10:49:50 EDT
Oh: when the machine is misbehaving this way, I can ping localhost, but cannot even ping my card's address.

This behavior cropped up with, so far as I can tell, no networking reconfig's.  (See: "But I didn't change anything!" :-)
Comment 5 Jay R. Ashworth, http://baylink.pitas.com 2000-10-31 11:30:15 EST
I've now seen this problem in at least 3 environments.  It appears to have something possibly to do with the 2.2.16 kernel sending out bad ARP packets, 
because rebooting the gateway on the network makes the workstation come back to life.  This looks like it might be a fairly serious bug; is anyone 
paying attention?
Comment 6 Unstable Boy 2001-01-26 14:28:46 EST
I appear to be having the same problem. I have noticed some other things on my machine 1: ftp and telnet to the machine is extreamly slow. 2: if I add the remote machine to the /etc/hosts file it seems to clear up for that machine only. I am running 6.2 on a Umax laptop w/ 3com nic.
Comment 7 Jay R. Ashworth, http://baylink.pitas.com 2002-08-19 21:34:38 EDT

I've gotten this characterized quite a bit more tightly in the *24 months* 
since this boog was opened.

What appears to be happening is that *if the resolv.conf points to a broken or 
missing server*, and there is a default route, then packets are accepted in by 
the IP kernel, but not handed up to the upper layers.

I can ping to such a machine with no trouble.

If I try to ping out *from* such a machine, I can see the echo reply packets 
coming in on the interface in tcpdump in a separate window, but they aren't 
handed upstairs to ping for a *long* time -- the delay on the packets is 
repeatable and looks like: 

Those are in *seconds*.

The sequence numbers are in order.

Obviously, as long as you can either dump the default route, or modify the 
resolv.conf, you can get around this, but neither's a great answer, and if 
you're trying to use Linux on, say, a laptop, as a diagnostic tool, it's 

Any chance someone might look into this further?

Comment 8 Arjan van de Ven 2002-08-20 13:12:30 EDT
Maybe a stupid question, but have you tried ping -n yet? (eg to avoid ping doing
dns lookups)
Comment 9 Jay R. Ashworth, http://baylink.pitas.com 2002-08-20 20:31:17 EDT
Yeah, this happens both ways.  Because, let's face it, ping is only gonna do 
those lookups once, at the beginning, right?

And leaving DNS broken but removing the default route fixes the problem.

I can even construct a *specific* route to a remote network via my router and 
everything works fine.  So it's not packets with remote addresses.

Sorry; what I'm pinging for test is always *on* the local network, which, to 
date, has been 192.168.n/24.

(nice to know we woke someone up; thanks. :-)
Comment 10 Jay R. Ashworth, http://baylink.pitas.com 2003-06-13 18:48:02 EDT
But I see we didn't wake anyone up all that far. 
Is anyone still seeing this?  I'm about to load yet a third new laptop -- with 7.3, cause I'm not 
happy with 9.0 as a production release yet.  More then.  But, really, is *anyone* with a 
redhat.com address listening? 
Cause, y'know, if you're not... close the damn bug or shut down the bz. 
Comment 11 Jay R. Ashworth, http://baylink.pitas.com 2003-06-14 14:45:26 EDT
FOLO: a small amount of free time having cropped up, I tried to reproduce on RH9, which I 
have on a test box. 
Here it doesn't happen: placing an invalid nameserver address in resolv.conf does not make 
pings to the local network take forever. 
And one further comment: when I was seeing this problem on 7.2, it didn't appear to affect 
telnet -- I could telnet to local hosts just fine.  It was *just* ICMP, so far as I could determine. 
Comment 12 Jay R. Ashworth, http://baylink.pitas.com 2003-06-14 14:46:41 EDT
Clarification: I originally noted the problem on 6.2; it survived an upgrade to 7.3. 

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