J'ai un serveur de messagerie interne sous Mandrake 9.2.
Des pcs sous Linux et Windows (ttes versions) qui s'y connectent sans
problème, sauf pour les Pcs sous XP.
Pour les XP (SP2 à jour), il y a un délai de 40 secondes ou plus avant
la récupération des messages en POP3.
J'ai essayé "telnet mon-serveur 110" et le délai est le même avant qu'il
m'affiche l'invite telnet.
J'ai essayé "telnet IP_de_mon_serveur 110" et le délai est identique (40
sec).
La même commande depuis d'autres OS que XP sur le même réseau m'affiche
l'invite telnet instantanément.
J'ai cherché sur le net, mais n'ai rien trouvé de probant.
Je ne pense pas à un pbm de configuration de OE, puisque telnet
rencontre le même délai.
Pas de pbm réseau, puisque les dizaines d'autres PCs récupèrent leurs
mèls tout à fait rapidement.
NB : les mêmes PCs qui rencontrent des pbms de délai en interne,
récupèrent leurs mèls instantanément sur les serveurs Oléane.
Quelqu'un ici a t-il déjà eu vent de lenteurs de ce type sous XP ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
J'ai un serveur de messagerie interne sous Mandrake 9.2. Des pcs sous Linux et Windows (ttes versions) qui s'y connectent sans problème, sauf pour les Pcs sous XP.
Pour les XP (SP2 à jour), il y a un délai de 40 secondes ou plus avant la récupération des messages en POP3.
J'ai essayé "telnet mon-serveur 110" et le délai est le même avant qu'il m'affiche l'invite telnet.
J'ai essayé "telnet IP_de_mon_serveur 110" et le délai est identique (40 sec).
La même commande depuis d'autres OS que XP sur le même réseau m'affiche l'invite telnet instantanément.
La cause probable est que le serveur fait une requête IDENT (TCP 113) sur le client mais ce dernier a un pare-feu qui bloque silencieusement la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le serveur attend une réponse un certain temps puis abandonne. Justement, XP a un pare-feu intégré mais pas les versions précédentes de Windows.
A vérifier avec un logiciel de capture de paquets réseau, ou avec "netstat -t" sur le serveur pendant le délai pour voir les demandes de connexions TCP en cours.
Solution 1 : ouvrir le port TCP 113 en entrée dans le pare-feu des postes XP, ou si possible configurer le pare-feu pour rejeter les connexions sur ce port au lieu de les bloquer.
Solution 2 : configurer le serveur POP3 pour ne plus faire de requête IDENT sur les clients, ça ne sert pas à grand chose.
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans news:fr.comp.reseaux.ip.
Salut,
J'ai un serveur de messagerie interne sous Mandrake 9.2.
Des pcs sous Linux et Windows (ttes versions) qui s'y connectent sans
problème, sauf pour les Pcs sous XP.
Pour les XP (SP2 à jour), il y a un délai de 40 secondes ou plus avant
la récupération des messages en POP3.
J'ai essayé "telnet mon-serveur 110" et le délai est le même avant qu'il
m'affiche l'invite telnet.
J'ai essayé "telnet IP_de_mon_serveur 110" et le délai est identique (40
sec).
La même commande depuis d'autres OS que XP sur le même réseau m'affiche
l'invite telnet instantanément.
La cause probable est que le serveur fait une requête IDENT (TCP 113)
sur le client mais ce dernier a un pare-feu qui bloque silencieusement
la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le
serveur attend une réponse un certain temps puis abandonne. Justement,
XP a un pare-feu intégré mais pas les versions précédentes de Windows.
A vérifier avec un logiciel de capture de paquets réseau, ou avec
"netstat -t" sur le serveur pendant le délai pour voir les demandes de
connexions TCP en cours.
Solution 1 : ouvrir le port TCP 113 en entrée dans le pare-feu des
postes XP, ou si possible configurer le pare-feu pour rejeter les
connexions sur ce port au lieu de les bloquer.
Solution 2 : configurer le serveur POP3 pour ne plus faire de requête
IDENT sur les clients, ça ne sert pas à grand chose.
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans
news:fr.comp.reseaux.ip.
J'ai un serveur de messagerie interne sous Mandrake 9.2. Des pcs sous Linux et Windows (ttes versions) qui s'y connectent sans problème, sauf pour les Pcs sous XP.
Pour les XP (SP2 à jour), il y a un délai de 40 secondes ou plus avant la récupération des messages en POP3.
J'ai essayé "telnet mon-serveur 110" et le délai est le même avant qu'il m'affiche l'invite telnet.
J'ai essayé "telnet IP_de_mon_serveur 110" et le délai est identique (40 sec).
La même commande depuis d'autres OS que XP sur le même réseau m'affiche l'invite telnet instantanément.
La cause probable est que le serveur fait une requête IDENT (TCP 113) sur le client mais ce dernier a un pare-feu qui bloque silencieusement la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le serveur attend une réponse un certain temps puis abandonne. Justement, XP a un pare-feu intégré mais pas les versions précédentes de Windows.
A vérifier avec un logiciel de capture de paquets réseau, ou avec "netstat -t" sur le serveur pendant le délai pour voir les demandes de connexions TCP en cours.
Solution 1 : ouvrir le port TCP 113 en entrée dans le pare-feu des postes XP, ou si possible configurer le pare-feu pour rejeter les connexions sur ce port au lieu de les bloquer.
Solution 2 : configurer le serveur POP3 pour ne plus faire de requête IDENT sur les clients, ça ne sert pas à grand chose.
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans news:fr.comp.reseaux.ip.
nwjb
Le Thu, 23 Nov 2006 11:56:14 +0100, Pascal Hambourg a écrit:
Salut,
J'ai un serveur de messagerie interne sous Mandrake 9.2. Des pcs sous Linux et Windows (ttes versions) qui s'y connectent sans problème, sauf pour les Pcs sous XP. Pour les XP (SP2 à jour), il y a un délai de 40 secondes ou plus avant la récupération des messages en POP3. J'ai essayé "telnet mon-serveur 110" et le délai est le même avant qu'il m'affiche l'invite telnet. J'ai essayé "telnet IP_de_mon_serveur 110" et le délai est identique (40 sec). La même commande depuis d'autres OS que XP sur le même réseau m'affiche l'invite telnet instantanément.
La cause probable est que le serveur fait une requête IDENT (TCP 113) sur le client mais ce dernier a un pare-feu qui bloque silencieusement la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le serveur attend une réponse un certain temps puis abandonne. Justement, XP a un pare-feu intégré mais pas les versions précédentes de Windows.
A vérifier avec un logiciel de capture de paquets réseau, ou avec "netstat -t" sur le serveur pendant le délai pour voir les demandes de connexions TCP en cours.
Solution 1 : ouvrir le port TCP 113 en entrée dans le pare-feu des postes XP, ou si possible configurer le pare-feu pour rejeter les connexions sur ce port au lieu de les bloquer.
Solution 2 : configurer le serveur POP3 pour ne plus faire de requête IDENT sur les clients, ça ne sert pas à grand chose.
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans news:fr.comp.reseaux.ip.
Certains serveurs telnet linux ont pour politique de répondre lentement aux clients inconnus. Mettre les adresses des PC clients dans /etc/hosts du serveur traite cela.
Une piste ?
-- J.Bratières
Enlever paspub pour répondre Please remove paspub when answering
Le Thu, 23 Nov 2006 11:56:14 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> a écrit:
Salut,
J'ai un serveur de messagerie interne sous Mandrake 9.2.
Des pcs sous Linux et Windows (ttes versions) qui s'y connectent sans
problème, sauf pour les Pcs sous XP.
Pour les XP (SP2 à jour), il y a un délai de 40 secondes ou plus avant
la récupération des messages en POP3.
J'ai essayé "telnet mon-serveur 110" et le délai est le même avant
qu'il m'affiche l'invite telnet.
J'ai essayé "telnet IP_de_mon_serveur 110" et le délai est identique
(40 sec).
La même commande depuis d'autres OS que XP sur le même réseau
m'affiche l'invite telnet instantanément.
La cause probable est que le serveur fait une requête IDENT (TCP 113)
sur le client mais ce dernier a un pare-feu qui bloque silencieusement
la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le
serveur attend une réponse un certain temps puis abandonne. Justement,
XP a un pare-feu intégré mais pas les versions précédentes de Windows.
A vérifier avec un logiciel de capture de paquets réseau, ou avec
"netstat -t" sur le serveur pendant le délai pour voir les demandes de
connexions TCP en cours.
Solution 1 : ouvrir le port TCP 113 en entrée dans le pare-feu des
postes XP, ou si possible configurer le pare-feu pour rejeter les
connexions sur ce port au lieu de les bloquer.
Solution 2 : configurer le serveur POP3 pour ne plus faire de requête
IDENT sur les clients, ça ne sert pas à grand chose.
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans
news:fr.comp.reseaux.ip.
Certains serveurs telnet linux ont pour politique de répondre lentement
aux clients inconnus.
Mettre les adresses des PC clients dans /etc/hosts du serveur traite cela.
Une piste ?
--
J.Bratières
Enlever paspub pour répondre
Please remove paspub when answering
Le Thu, 23 Nov 2006 11:56:14 +0100, Pascal Hambourg a écrit:
Salut,
J'ai un serveur de messagerie interne sous Mandrake 9.2. Des pcs sous Linux et Windows (ttes versions) qui s'y connectent sans problème, sauf pour les Pcs sous XP. Pour les XP (SP2 à jour), il y a un délai de 40 secondes ou plus avant la récupération des messages en POP3. J'ai essayé "telnet mon-serveur 110" et le délai est le même avant qu'il m'affiche l'invite telnet. J'ai essayé "telnet IP_de_mon_serveur 110" et le délai est identique (40 sec). La même commande depuis d'autres OS que XP sur le même réseau m'affiche l'invite telnet instantanément.
La cause probable est que le serveur fait une requête IDENT (TCP 113) sur le client mais ce dernier a un pare-feu qui bloque silencieusement la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le serveur attend une réponse un certain temps puis abandonne. Justement, XP a un pare-feu intégré mais pas les versions précédentes de Windows.
A vérifier avec un logiciel de capture de paquets réseau, ou avec "netstat -t" sur le serveur pendant le délai pour voir les demandes de connexions TCP en cours.
Solution 1 : ouvrir le port TCP 113 en entrée dans le pare-feu des postes XP, ou si possible configurer le pare-feu pour rejeter les connexions sur ce port au lieu de les bloquer.
Solution 2 : configurer le serveur POP3 pour ne plus faire de requête IDENT sur les clients, ça ne sert pas à grand chose.
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans news:fr.comp.reseaux.ip.
Certains serveurs telnet linux ont pour politique de répondre lentement aux clients inconnus. Mettre les adresses des PC clients dans /etc/hosts du serveur traite cela.
Une piste ?
-- J.Bratières
Enlever paspub pour répondre Please remove paspub when answering
Pascal Hambourg
Certains serveurs telnet linux ont pour politique de répondre lentement aux clients inconnus.
Aux clients dont l'adresse IP n'a pas de de reverse DNS, tu veux dire ? J'ai déjà observé ça et j'y ai pensé, mais pourquoi cela n'affecterait-il que les postes sous Windows XP et pas les autres ?
Certains serveurs telnet linux ont pour politique de répondre lentement
aux clients inconnus.
Aux clients dont l'adresse IP n'a pas de de reverse DNS, tu veux dire ?
J'ai déjà observé ça et j'y ai pensé, mais pourquoi cela
n'affecterait-il que les postes sous Windows XP et pas les autres ?
Certains serveurs telnet linux ont pour politique de répondre lentement aux clients inconnus.
Aux clients dont l'adresse IP n'a pas de de reverse DNS, tu veux dire ? J'ai déjà observé ça et j'y ai pensé, mais pourquoi cela n'affecterait-il que les postes sous Windows XP et pas les autres ?
nwjb
Le Thu, 23 Nov 2006 12:12:49 +0100, Pascal Hambourg a écrit:
Certains serveurs telnet linux ont pour politique de répondre lentement aux clients inconnus.
Aux clients dont l'adresse IP n'a pas de de reverse DNS, tu veux dire ? J'ai déjà observé ça et j'y ai pensé, mais pourquoi cela n'affecterait-il que les postes sous Windows XP et pas les autres ?
Je n'allais même pas jusque là. Mais sur les serveurs que nous installons (redHat et Suse) les connexions telnet (par adresse IP et non par nom (pas deDNS)) sont très longues à établir tant que l'adresse du client n'est pas dans le fichiers hosts. Cela paraît logique pour des raisons de sécurité en empêchant des tentatives automatiques répétées pour casser un mot de passe par exemple.
J'avais supposé que les autres postes 'pouvaient' être dans hosts et pas ceux sous XP.... simplement.
La suite m'intéresse..
-- J.Bratières
Enlever paspub pour répondre Please remove paspub when answering
Le Thu, 23 Nov 2006 12:12:49 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> a écrit:
Certains serveurs telnet linux ont pour politique de répondre
lentement aux clients inconnus.
Aux clients dont l'adresse IP n'a pas de de reverse DNS, tu veux dire ?
J'ai déjà observé ça et j'y ai pensé, mais pourquoi cela
n'affecterait-il que les postes sous Windows XP et pas les autres ?
Je n'allais même pas jusque là. Mais sur les serveurs que nous installons
(redHat et Suse)
les connexions telnet (par adresse IP et non par nom (pas deDNS)) sont
très longues à établir
tant que l'adresse du client n'est pas dans le fichiers hosts. Cela paraît
logique pour
des raisons de sécurité en empêchant des tentatives automatiques répétées
pour casser un mot de
passe par exemple.
J'avais supposé que les autres postes 'pouvaient' être dans hosts et pas
ceux sous XP.... simplement.
La suite m'intéresse..
--
J.Bratières
Enlever paspub pour répondre
Please remove paspub when answering
Le Thu, 23 Nov 2006 12:12:49 +0100, Pascal Hambourg a écrit:
Certains serveurs telnet linux ont pour politique de répondre lentement aux clients inconnus.
Aux clients dont l'adresse IP n'a pas de de reverse DNS, tu veux dire ? J'ai déjà observé ça et j'y ai pensé, mais pourquoi cela n'affecterait-il que les postes sous Windows XP et pas les autres ?
Je n'allais même pas jusque là. Mais sur les serveurs que nous installons (redHat et Suse) les connexions telnet (par adresse IP et non par nom (pas deDNS)) sont très longues à établir tant que l'adresse du client n'est pas dans le fichiers hosts. Cela paraît logique pour des raisons de sécurité en empêchant des tentatives automatiques répétées pour casser un mot de passe par exemple.
J'avais supposé que les autres postes 'pouvaient' être dans hosts et pas ceux sous XP.... simplement.
La suite m'intéresse..
-- J.Bratières
Enlever paspub pour répondre Please remove paspub when answering
fred.fm
Bonjour,
La cause probable est que le serveur fait une requête IDENT (TCP 113) sur le client mais ce dernier a un pare-feu qui bloque silencieusement la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le serveur attend une réponse un certain temps puis abandonne. Justement, XP a un pare-feu intégré mais pas les versions précédentes de Windows.
Très bien vu ... Je n'avais pas vérifié le pare-feu car j'étais sûr qu'il était désactivé, puisque c'est une règle dans l'entreprise .... nous avons un pare-feu général. Mais il était pourtant actif, et le fait de le désactiver a résolu le pbm immédiatement. Merci beaucoup pour vos réponses...
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans news:fr.comp.reseaux.ip.
... et désolé d'avoir posté sur le mauvais forum.
-- à plus. Fred
Bonjour,
La cause probable est que le serveur fait une requête IDENT (TCP 113)
sur le client mais ce dernier a un pare-feu qui bloque silencieusement
la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le
serveur attend une réponse un certain temps puis abandonne. Justement,
XP a un pare-feu intégré mais pas les versions précédentes de Windows.
Très bien vu ...
Je n'avais pas vérifié le pare-feu car j'étais sûr qu'il était
désactivé, puisque c'est une règle dans l'entreprise .... nous avons un
pare-feu général.
Mais il était pourtant actif, et le fait de le désactiver a résolu le
pbm immédiatement.
Merci beaucoup pour vos réponses...
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans
news:fr.comp.reseaux.ip.
La cause probable est que le serveur fait une requête IDENT (TCP 113) sur le client mais ce dernier a un pare-feu qui bloque silencieusement la requête au lieu de la rejeter, c'est-à-dire répondre "port fermé". Le serveur attend une réponse un certain temps puis abandonne. Justement, XP a un pare-feu intégré mais pas les versions précédentes de Windows.
Très bien vu ... Je n'avais pas vérifié le pare-feu car j'étais sûr qu'il était désactivé, puisque c'est une règle dans l'entreprise .... nous avons un pare-feu général. Mais il était pourtant actif, et le fait de le désactiver a résolu le pbm immédiatement. Merci beaucoup pour vos réponses...
Comme ceci n'a rien à voir avec ethernet, je redirige la suite dans news:fr.comp.reseaux.ip.
