Windows xp é desconectado pelo samba após 10 minutos

[joserley]

Em um servidor com Ubuntu Server e Samba 3.5.6 existem 8 estações com Windows 7 pro e tudo funciona bem.

Recentemente foi adicionada uma nova estação porém com windows xp pro. Aparentemente tudo funciona muito
bem. A estação reconheceu o domínio as pastas com as permissões, enfim tudo como deveria ser...

Só que a estação com windows xp é desconectada da pasta que se encontra após 10 minutos.
Na tela do windows apareçe a mensagem: "Não foi possível localizar a pasta destino...etc..."

No log gerado pelo samba apareçe a mensagem:
"Error was transport endpoint is not connected".
"read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by peer
"Closed connection to service"

Mas a estação não é desconectada do domínio. Apenas perde a conexão com a pasta que se encontra no momento.
Basta o usuário sair e entrar novamente na mesma pasta e a conexão é reestabelecida... mas é desconectado novamente exatamente 10 minutos depois...

As permissões estão corretas. Tanto que o usuário trabalha normalmente com a pasta por até 10 minutos.
Isto só está acontecendo com o windows xp. Com o windows 7 está tudo em ordem...

Alguma pista deste curioso ?

Agradeço muito...
Joserley.

[Tota]

Ola,

Eu começaria pela placa de rede do xp.

Verificar nas propriedades da placa de rede como estão os modulos de energia, se ela se desliga na ausência de trafego.

eliminaria toda a gestão de energia do xp para testes e testaria outra placa de rede.

Após se certificar que o problema não é de placa ou gestão de energia eu passaria a examinar o trafego de pacotes, certificação de cabeamento e assim sucessivamente, até chegar ao servidor.

Só aí examinar se o problema é no servidor ou no Samba.

[]'s

[zekkerj]

Eu já tive esse problema em uma instalação. Pra falar a verdade, não lembro exatamente qual a solução que dei; mas passou por:

1. Não deixar o Thunderbird do Windows criar pastas com mais de 1GB.
2. Desativar algumas opções da placa de rede do Linux (protocol offload, flow control, etc).
3. Rever o cabeamento e os switchs da rede (no caso, era um switch DLink de 24 portas que eu confesso que coloquei muito mais confiança do que ele merecia).

[joserley]

Ola pessoal !
Testei as dicas que vocês me deram acima mas não resolveu.

Entretanto, ---achei o problema---
Uma regra do iptables bloqueava todas as portas udp de 0 a 25000,
liberando somente as portas 9 e 53.
O problema foi resolvido quando todas as portas udp de 0 a 25000 foram liberadas.
As portas acima de 25000 já estavam liberadas.

Esta ideia de bloquear as portas udp de 0 a 25000 foi retirada de um "forum por aí" que
recomendava como medida de segurança. Ao que pareçe mais dá problema do que
segurança.
Mas agora está resolvido.

Agradeço a atenção e a colaboração de vocês.

Joserley !