[solved] losing lan connection to zentyal temporary

[Lueghi]

When my XP-Clients are logged in to my Zentyal-server (working as PDC, DHCP, DNS, MAIL, Gateway etc.) and there is temporary no active traffic from the client to the server, very often the lan connection is lost. There is no way to ping the server. All the other IP's in my network I can ping. It happens too when the notebooks are reactivated after a standby. The internal NIC in the server has 3 additional IP's. To get the connection working again I have to ping a couple of times to the different server-IP's and as if by a miracle the ping to the server is working again and 'normal' work for the clients is possible.

First I thought I made some misconfiguration in the DNS/DHCP area. So I set up a new server without editing manually the config files (what I did for the first time in the DNS/DHCP area). I also read the parts of the documentation to do the configuration right. But the problem is still existing.

I configured the DNS as dynamic. Could the problem result in this? How can I deactivate the dynamic? When I edit the DNS section in the GUI there is no possibilty to deactivte it. I'm working on a linux server as a small home server for a couple of years. In the past I used debian and I did all the configuration manually. I was hard work (for me) but it ran finally. But I never had problems like this.

[edit]
I don't think it's a hardware problem, because the new server has complete different hardware.
[/edit]

So what can I do? Which information I have to post to get some help?

[christian]

In order to isolate domains for investigation: what if you ping IP address instead of FQDN? (this to ensure DNS is not used and out of the investigation scope).
And what if you "traceroute"?

BTW, which version are you using? I'm asking because Linux kernel solved (I hope) some similar issue with Realtek network some time ago...

[Lueghi]

In order to isolate domains for investigation: what if you ping IP address instead of FQDN? (this to ensure DNS is not used and out of the investigation scope).

timeout

And what if you "traceroute"?

also timeout

BTW, which version are you using? I'm asking because Linux kernel solved (I hope) some similar issue with Realtek network some time ago...

That sound interesting. I will check if I use Realtek NIC. My Version is [edit]2.02.[/edit]

[Lueghi]

@christian: I'm using a VIA Rhine NIC ...

[Lueghi]

This weekend I did some testing and the result is surprising for me:

I worked on a WinXP client and I had an open DOS Window. Additionally I had an ssh client session to my server. While the ping in the dos box gets the timeout error, the connection in the ssh session still worked .... ? Both session were using the name of the server and not the IP address to get the connection.

So is there someone with an idea?

[DWAM]

It could be a switch problem... or an ethernet cable problem...

While the ping in the dos box gets the timeout error, the connection in the ssh session still worked .... ?

Are you sure ? Your SSH session might be closed and reconnected before it declares itself as closed.
Can you ping your XP host from your server at the same time ?

Are you sure you do not have 2 DHCP servers running concurrently on your LAN ?

Did you try the command "ipconfig /all" at your XP host when your server seems unreachable ?

[christian]

@christian: I'm using a VIA Rhine NIC ...

Any IRQ erlated message in /var/messages or syslog?

[christian]

I worked on a WinXP client and I had an open DOS Window. Additionally I had an ssh client session to my server. While the ping in the dos box gets the timeout error, the connection in the ssh session still worked .... ? Both session were using the name of the server and not the IP address to get the connection.

You demonstrated with previous test that problem occurs with both FQDN and IP, thus DNS is not the faulty one.
Problem you describe really looks like the one I was referring  to with Realtek. Performing some additional search, I discovered that similar problem occurred in the past with VIA Rhine. (Google is your friend  ) but I believe it's solved with current kernels.

Did you try not to set up multiple IPs in this interface (server side)?

Definitely I would investigate deeper in logs server side 

I know the Realtek issue because I had to face it and this pushed me to jump asap to Ubuntu 9.10
1 - What is the output of "dmesg | grep via-rhine" ?
2 - Is there a way to disable ACPI in your BIOS?

[Lueghi]

@christian:
I will try to change the NIC and I will post the results.

[christian]

OK, thank you. I think this is the ultimate test 

[half_life]

As another possibility,  check in bios to make sure that any "green" settings are not enabled on the server or client.  Also business class Cisco switches have similar green settings that might be effecting you.  This sounds like some device in the physical path is going to sleep and powering down.

[Lueghi]

Here is the preliminary result:

I installed another NIC and I disabled the Onboard-NIC. Since two hours the problem is gone  .... and I hope it will stay away  .

Because I did my tries with different hardware I assumed that I did some misconfiguration and that there is no hardware problem. But I used very similar mainboards both with a f***ing VIA Rhine NIC onboard .

So thank you to all the guys who led me to the hardware way ...... and yes: Zentyal is a great system with a fantastic forum .

[christian]

Good to know that your problem is somewhat solve.
Problem you initially described was very similar to the one I got with Realtek, reason why I made this comment in my first reply.
Then, issue has been solved in kernel for Realtek. Perhaps it's worth to check status for you VIA Rhine card...

[Lueghi]

My problem is still gone .... 

Good to know that your problem is somewhat solve.
Problem you initially described was very similar to the one I got with Realtek, reason why I made this comment in my first reply.
Then, issue has been solved in kernel for Realtek. Perhaps it's worth to check status for you VIA Rhine card...

I assume that there is a hardware problem with both onboard NIC's and that it wasn't a problem of ubuntu ....