I have my server set up as a web server running redhat 8.
It allows http & ssh
It seems to keep "going to sleep" in that you can't communicate with it if left to it's own devices for a while.
If you ping the hell out of it, usually it comes back to life. Typically it takes 200 - 800 pings to get it too respond.

Any ideas / things to look at gratefully received

Thanks
Mark

eeeeh very strange...
I think you should first try to turn off any powersaving thing around (there's some in the kernel and some directly in RedHat).
You can also try to start your http/ssh daemons outside xinetd (superdaemon), maybe it will fix the problem... During the "down" is there any special kernel log?

Have turned off power saving (I think), no difference.
Will look at those other issues you raised and let u know.

Thanks
Mark

in the meantime, setup a cron job to have your server ping somewhere every now and again to see if that keeps it alive...

what services do you have running?

We do have a job that pings out on startup to kick start things, but it still drops connectivity.

Apparently (after much investigation) there is an issue with the MAC address, in that it keeps getting dropped or being changed. Therefore the associated networking infrastructure loses contact with the server.
Very strange.
As I am no networking expert I don't really understand how this is possible.

To be more precise:

The ifconfig settings are all fine and the card comes up at boot time. I am using a Dell PowerEdge 2600 with RedHat 8.0. The card does not ARP it's MAC address to the network. Result: I need to manually ping out of the box to instigate a connection that frequently times out, especially after extended quiet periods.

Not using DHCP (will try next). The card is an Intel Pro 100/1000 (or so) and the same problem occurs with the embedded NIC as well as the additional one that we have in Slot 7. Have tried new cards, new motherboard, changing cables.

What the?

ok I'm not alone....I'm going through the EXACT same problem with my server.

At first being in a rush I thought it may be a software problem with Fedora Core2. But I put in Slackware 9.1 and the same damn thing!

So then I'm thinking ok must be a kernel thing. But FC2 uses 2.6.6 (which has ACPI support built in which has a known bug to cause packet loss on the eth...) and slack was installed with 2.4.22 and updated to 2.4.26....But I was still thinking it was a kernel thing...So I recompiled my kernel with any IP options and eth options built it....SAME THING!

So now I went back to the kernel looking for anything to do with ARP. And the option isn't suggested to load (its experimental and obsolete according to the docs).

So how the heck do you force your card to ARP properlly?

Something else for you to check mark is look at the "carrier" flag in ifconfig. Is the number going up? Rapidly? Almost as fast as your TX packets?

Have you tried changing your duplex mode? I've had to force mine to 100 HD in order to stop the carrier problems. I believe this is due to a lack of flow control which I also have no clue how to turn on.

Only solution I've found so far is I had my MAC statically routed on the switch which seems to have helped keep the box responding.

If anyone knows the REAL way to fix this problem PLEASE POST IT!!!! I'm totally stumped!

Thanks!

PS tried swapping NICs too. currently using a 3com 3c905c-TX-M.

bump!

Well we finally nailed the problem and all it was, was the drivers for the NICs.

Ended up getting a specialist linux mob involved and they nailed it smartly.

Regards
Mark