My HPNC3123 NIC falls unresponsive to inbound traffic

[Wayne Shappard]

I am running Red Hat Enterprise Linux ES v 2.1 on a Proliant ML-530 G2. My NIC is an HP/Compaq NC3123, it is correctly set to be 100base-TX FD, with no Auto-Negotiation.

My problem is that I get no response when I attempt to ping this server from any remote machine, UNTIL I go to the server's console and initiate some network activity (such as a ping) from there.

Once the server has made some network connection, remote machines can then successfully communicate with it, UNTIL it has had no network activity for some brief period of time. Once the server's NIC has been idle long enough, it once again falls unresponsive.

I do know that this NIC does have WOL (Wake On LAN), and I have used ethtool to (I believe) disable WOL with a:

ethtool -s eth0 wol d

but this has had no effect.

I also swapped the NIC with an identical one from another server, and I still have the problem.

Does this at all sound familiar to anybody? Is there some additional NIC driver setting I need to make?

I would appreciate hearing from anyone who might have an idea on what I am facing here.

Thanks

[Steven E. Protter]

a few things to check.

What are the settings in the file /etc/sysconfig/network-scripts/ifcfg-eth0

Replace the zero with the actual number of the NIC.

If the thing is set to be on at boot time, you should not be having this problem. I suspect this is not the case.

Prior to waking it up, ifconfig eth0

If it doesn't say up, you have not configured the card.

Now if you are in a multiple NIC environment there could be a conflict between the NIC card and another one, or with another machine on the network.

SEP

[Wayne Shappard]

Steve,

Thanks for responding. I worked along the lines you recommended, and this is what I found.

I rebooted my server and then pinged it from my desktop. Result: no response. I went to the server console and did a "ifconfig eth0" (which is the interface I am using). I found that its status was "UP BROADCAST RUNNING MULTICAST", no different from the embedded e100 running without problems on a DL360 I also have running RHAS 2.1.

As a test, I went back to my desktop and pinged the server several times again. On returning to the console and running ifconfig again, I found that the RX packets had increased, while the TX packets remained unchanged. I repeated this test several times with the same result. (BTW, no error packets were reported in either direction.) It was not until I issued a single ping from the server ("one ping, Vasili"), that it responded to pings from my desktop.

Here are the contents of my /etc/sysconfig/network-scripts/ifcfg-eth0 file:

CE=eth0
BOOTPROTO=none
BROADCAST=10.1.4.255
IPADDR=10.1.4.42
NETMASK=255.255.255.0
NETWORK=10.1.4.0
ONBOOT=yes
GATEWAY=10.1.4.1
TYPE=Ethernet
USERCTL=no
PEERDNS=no

What is curious to me is that this file is different in content from the same file found on my DL360, which works with no problems:

DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.1.255
IPADDR=192.168.1.86
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes

What I find curious is that I have not touched these files, and I cannot account for their differences. The only circumstance that comes to mind is that linux was first installed on this server with the wrong IP address, which was afterwards corrected from the GNOME network configuration applet.

I will make this file consistent with that found on my working system and see what I get. If, on the other hand, this additional information I have given you triggers some revelation, I would certainly appreciate hearing back from you.

In any respect, thanks again for responding.

[Steven E. Protter]

A few things jumped out at me though nothing totally explains the behavior.


This 10.1 network is more generally used as a class B network, with netmask 255.255.0.0

That is how we do it. Check the netmask configuration of some other machine on the 10.1 network. If they match, I'm wrong, if they are 255.255.0.0 change this machine and then do this:

service network restart

This assumes your users can tolerate a short(3-5 second) system outage.


CE=eth0
BOOTPROTO=none
BROADCAST=10.1.4.255
IPADDR=10.1.4.42
NETMASK=255.255.255.0
NETWORK=10.1.4.0
ONBOOT=yes
GATEWAY=10.1.4.1
TYPE=Ethernet
USERCTL=no
PEERDNS=no

What is curious to me is that this file is different in content from the same file found on my DL360, which works with no problems:

DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.1.255
IPADDR=192.168.1.86
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes


BOOTPROTO=static
I would think that should be the same in the 10.1 file because we're manually assinging IP addresses, not letting a DCHP server assign it.

Why don't you look into what I pointed out and see if it resolves the problem. I turn into a pumpkin as it were around 8 p.m. tonight for a couple of days. I'll check back a few more times if family considerations permit.

SEP