Network description:

INET --> Router (U.S. Robotics MaxG ADSL Gateway) --> Switch --> Server (Debian etch stock kernel 2.6.18-6-686)

The server has 2 Gbps Ethernet adapters with offloading capabilities. eth0 = 192.168.1.55, eth1 is disabled. GW = 192.168.1.1.

Problem description:

When I try to ping the router the first 8-13 replies come back and then everything stops working. No replies and no connectivity whatsoever. The router's (USR) arp table is as follows:

> arp show

IP address HW type Flags HW address Mask Device
192.168.1.2 0x1 0x2 AA:00:04:00:0A:04 * br0
192.168.1.4 0x1 0x2 00:191:31:70:8A * br0
192.168.1.10 0x1 0x2 00:1A:70:99:60:F6 * br0
192.168.1.55 0x1 0x0 00:30:48:66:21:58 * br0

As you may see the only difference between the server and all other hosts is that the flag is set to 0x0 (which i don't know what it means, because i wasn't able to find any documentation whatsoever on ARP flags). After the arp cache is flushed on the router I can ping it with the server again for about 8 times and the problem comes back. Same thing using any network interface eth0 or eth1, with offloading enabled or disabled.

If I bring down the link between the switch and the router, the server can ping all hosts in the network for an indefinite amount of time but if I bring it up again, whenever I can't ping the router, I can't ping any host on the network and also no host on the network can ping the server (Host unreachable).

I have looked into the arp flux problem and tried fixing it with arp_filter but it seems that was not the solution.

My questions for networking tuxes out there:

What does the 0x0 flag mean?
What could cause such strange behaviour in the router?
Any ideea on a fix for this?

Humble thanks to all those who read everything I wrote.

New test results:

There is NO arping reply from the server's ethernet card. But arping from it seems to work fine.

It seems that Debian Etch stock kernel has a problem regarding some Intel ethernet adapters. After some time the 2.6.18 standard kernel stops sending the correct opcode in ARP reply packets sending instead of 0x00-02 it sends 0x00-00. Don't know why that happens, I'm no Debian developer BUT it can be made to temp. work using arping to ping the gateway interface. That way the gateway will have the correct MAC address in it's cache and it will route (switch respectively) the server's packets. In that time, a kernel can be downloaded and compiled from http://kernel.org . The interfaces run fine using 2.6.25.4 stable kernel.

Cheers to all!

Thread still open for discussion if anyone is interested in getting to the bottom of this problem.

Thanks for taking the time to post your solution for the rest of us. We appreciate it.