Problème avec poste windows 7 et server debian

Bonjour,
Voila je vais tenter d’expliquer le problème que je rencontre depuis plusieurs mois chez un client qui utilisent des postes clients sous W7 64 BIT (à jour) avec des serveur de fichiers sous debian 5 et 6 (pas de controleur de domaine, simple utilisation de SAMBA).
tout les sites du client sont relié en VPN et chaque site possède 1 serveur de fichier sous Debian.
Le problème est que par période -1 à 6 fois par jours et cela pendant quelques jours et que sur certains postes- l’accès au serveur ne fonctionne plus, les lecteur réseau sont toujours présents mais affiche simplement “NTFS” à la place de l’espace disque restant.
A partir de ce même poste l’accès à d’autre serveur de fichier sur d’autre site fonctionne.

Après quelques test je me suis aperçu que le poste tente de contacter le serveur de fichiers sur le port 80 !!! pourquoi ? je ne sais pas…
Voici un exemple via tcpdump, le poste commence à communiquer correctement avec le serveur puis passe sur le port 80…

15:30:34.615554 IP 192.168.18.54.137 > 192.168.18.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 15:30:34.677226 IP 192.168.18.54.49277 > 192.168.18.55.139: S 2315819758:2315819758(0) win 8192 <mss 1460,nop,nop,sackOK> 15:30:34.677235 IP 192.168.18.55.139 > 192.168.18.54.49277: R 0:0(0) ack 1 win 0 15:30:34.678559 IP 192.168.18.54.137 > 192.168.18.55.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST 15:30:34.678719 IP 192.168.18.55.137 > 192.168.18.54.137: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 15:30:34.679208 IP 192.168.18.54.49275 > 192.168.18.55.445: S 708393128:708393128(0) win 8192 <mss 1460,nop,nop,sackOK> 15:30:34.679217 IP 192.168.18.55.445 > 192.168.18.54.49275: R 0:0(0) ack 1 win 0 15:30:34.679512 IP 192.168.18.54.49279 > 192.168.18.55.139: S 4257438329:4257438329(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK> 15:30:34.679522 IP 192.168.18.55.139 > 192.168.18.54.49279: R 0:0(0) ack 4257438330 win 0 15:30:34.683188 IP 192.168.18.54.49276 > 192.168.18.55.445: S 563965008:563965008(0) win 8192 <mss 1460,nop,nop,sackOK> 15:30:34.683198 IP 192.168.18.55.445 > 192.168.18.54.49276: R 0:0(0) ack 1 win 0 15:30:34.684197 IP 192.168.18.54.49274 > 192.168.18.55.445: S 399655334:399655334(0) win 8192 <mss 1460,nop,nop,sackOK> 15:30:34.684206 IP 192.168.18.55.445 > 192.168.18.54.49274: R 0:0(0) ack 1 win 0 15:30:35.184255 IP 192.168.18.54.49279 > 192.168.18.55.139: S 4257438329:4257438329(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK> 15:30:35.184264 IP 192.168.18.55.139 > 192.168.18.54.49279: R 0:0(0) ack 1 win 0 15:30:35.365373 IP 192.168.18.54.137 > 192.168.18.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 15:30:35.694320 IP 192.168.18.54.49279 > 192.168.18.55.139: S 4257438329:4257438329(0) win 8192 <mss 1460,nop,nop,sackOK> 15:30:35.694330 IP 192.168.18.55.139 > 192.168.18.54.49279: R 0:0(0) ack 1 win 0 15:30:35.713883 IP 192.168.18.54.49280 > 192.168.18.55.80: S 3778130488:3778130488(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK> 15:30:35.713892 IP 192.168.18.55.80 > 192.168.18.54.49280: R 0:0(0) ack 3778130489 win 0 15:30:36.073042 IP 192.168.18.54.63555 > 224.0.0.252.5355: UDP, length 22 15:30:36.115404 IP 192.168.18.54.137 > 192.168.18.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 15:30:36.172498 IP 192.168.18.54.63555 > 224.0.0.252.5355: UDP, length 22 15:30:36.213368 IP 192.168.18.54.49280 > 192.168.18.55.80: S 3778130488:3778130488(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK> 15:30:36.213383 IP 192.168.18.55.80 > 192.168.18.54.49280: R 0:0(0) ack 1 win 0 15:30:36.372944 IP 192.168.18.54.137 > 192.168.18.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 15:30:36.713368 IP 192.168.18.54.49280 > 192.168.18.55.80: S 3778130488:3778130488(0) win 8192 <mss 1460,nop,nop,sackOK> 15:30:36.713377 IP 192.168.18.55.80 > 192.168.18.54.49280: R 0:0(0) ack 1 win 0 15:30:36.733639 IP 192.168.18.54.49281 > 192.168.18.55.80: S 2778879320:2778879320(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK> 15:30:36.733714 IP 192.168.18.55.80 > 192.168.18.54.49281: R 0:0(0) ack 2778879321 win 0

Es ce le client ou le serveur qui impose l’utilisation de ce port 80 ?!

Certaines fois la seule solution pour retrouver l’accès aux fichiers partagés est de soit redémarrer le poste client soit le serveur debian.

Donc voila si quelqu’un à déjà eu écho de ce genre de problème, je serai content d’obtenir des avis et conseils merci !

bonjour,
j’ai eu le même soucis, avec un nas Qnap et un poste sous seven. il a fallut que je redémarre puis que je cherche dans les favoris réseaux //serveur/.

Depuis que j’ai connecté un lecteur réseaux en automatique ça va mieux, mais c’est pas le pied car mon PC démarre trop vite (saleté de ssd :-° ) du coup le nas n’a pas le temps de répondre, et donc mon lecteur réseau n’est pas connecté. Donc tous les matins, il faut que je le reconnecte avant de le lancer mes applications métiers…

Je me demande si dans ton cas, il faudrait pas rajouter l’adresse IP de ton seveur dans le fichier c:/Windows/System32/drivers/etc/hosts…

pour mon problème, il faudrait que je scripte pour la connexion de mon lecteur réseau

tu as un netlogon pour mapper les lecteurs réseau ?

jimbo, j’avoue ne pas comprendre la question :

je laisse windows gérer le montage de mes lecteurs réseaux, mais si le problème persiste, je vais sans doute passer au script avec net use

tu peux créer un netlogon qui se lance à l’ouverture de session qui te mape les lecteurs réseauc avec netuse machin