Bonjour,
je dispose d'un serveur CUPS sur une distribution Debian Sarge qui me permet d'utiliser des imprimantes réseaux distantes. Ces machines sont toutes sur le réseau local (pas de passage de passerelle ni de routeur donc) et elles utilisent toutes un protocole TCP sur port 9100 (le protocole réseau des HP par exemple).
Sur une de ces machines, CUPS se casse les dents...
Concrètement, au niveau de l'utilisateur, une demande d'impression peut mettre plus de 10 minutes avant que l'imprimante ne sorte le papier. Au niveau du système, il semble que ce soit CUPS qui me bloque temporairement l'impression: le fichier est complètement spoolé (CUPS n'est pas en attente du fichier du client), CUPS tente de contacter l'imprimante ( à la bonne adresse IP et sur le bon port) qui semble ne pas lui répondre tout de suite. Le temps avant impression est variable (des fois immédiat, des fois 5 minutes, des fois plus...).
Au niveau réseau (j'ai fait une capture avec tcpdump), l'affaire se corse: J'ai bien un paquet sortant du serveur vers l'imprimante en TCP/SYN. La capture me montre que par 3 fois, l'imprimante renvoie un paquet TCP/SYN ACK (fonctionnement normal). Après ces 3 paquets SYN ACK, le serveur (via CUPS) relance un paquet TCP/SYN identique au premier envoyé.
Par rapport à cette capture, j'ai l'impression que le serveur fait une demande de connexion TCP, le kernel reçoit bien le(s) paquet(s) de réponse de l'imprimante (sinon ils ne seraient pas passés dans la capture) mais le service CUPS ne semble pas en tenir compte.
Voilà ce que j'ai vérifié:
- pas de problème de câble ni de prises (changé)
- l'impression IPP directe depuis une autre machine que le serveur fonctionne à tous les coups (pas le problème indiqué)
- J'ai vérifié que je n'avais pas trop de limites tcp au niveau du kernel (tcp_mem).
Comment se fait-il que pour ce serveur là, CUPS semble ne pas tenir compte du SYN ACK de l'imprimante ? Au bout de X minutes, après avoir tenté n connexions TCP, CUPS récupère bien le paquet SYN ACK de l'imprimante et poursuit le traitement de l'envoi normalement (pas d'autres erreurs TCP rencontrées)...
Votre avis sur la question ?
Forum Linux.debian/ubuntu CUPS a des problèmes réseaux...
30
avr.
2008
# A mon avis, ce n'est pas CUPS
Posté par Sébastien Koechlin . Évalué à 2.
As-tu essayé d'établir toi même une connexion depuis le serveur vers l'imprimante ? Avec "telnet imprimante 9100" par exemple ? Qu'est ce qu'en dit tcpdump ?
Est-ce qu'il y a des règles de Firewall sur le serveur ? Des bits étranges positionnés dans le SYN-ACK de l'imprimante ? Un problème de netmask ?
As-tu essayé de faire un strace sur CUPS ? Est-ce que le connect() est bloqué ? Ou bien quelle valeur de retour a-t-il ?
[^] # Re: A mon avis, ce n'est pas CUPS
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
Tu peut essayer LogLevel debug ou même LogLevel debug2.
Si ça donne trop : LogLevel info.
[^] # Re: A mon avis, ce n'est pas CUPS
Posté par Médéric RIBREUX (site web personnel) . Évalué à 1.
un peu de neuf:
j'ai visiblement un problème IP avec cette machine: je ne peux pas pinguer correctement l'imprimante à partir d'elle: j'ai parfois 1 paquet sur 100 qui passe mais, en règle générale, rien n'arrive.
Pour information, cette machine fait de l'ipaliasing (une seule adresse en alias).
Le niveau de log ne m'indique rien de probant: juste que le job a été envoyé.
L'utilisation de strace me montre que la commande connect retourne un timeout...
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(9100), sin_addr=inet_addr("x.x.x.x")}, 16) = -1 ETIMEDOUT (Connection timed out)
close(4) = 0
write(2, "ERROR: Unable to connect to prin"..., 83) = 83
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({30, 0}, {30, 0}) = 0
Il n'y a pas de firewall sur cette machine et j'arrive à pinguer sans problème l'imprimante depuis une autre machine qui utilise le même équipement actif et qui est identique en matériel et en système (juste l'IP qui change). Rien du côté du switch en terme de bloquage !
Je vais essayer de changer l'adresse IP de l'imprimante, on verra bien si ça résoud mon problème. Sinon, je vais mettre mon kernel à jour !
Merci pour vos informations...
[^] # Re: A mon avis, ce n'est pas CUPS
Posté par totof2000 . Évalué à 2.
Essaie si tu peux de le débrancher et de pinguer (au passage, fais de même avec l'imprimante).
[^] # Re: A mon avis, ce n'est pas CUPS
Posté par Médéric RIBREUX (site web personnel) . Évalué à 1.
De n'importe quelle autre machine que ce serveur, je peux pinguer sans problème l'imprimante.
J'ai donc arrêté ce serveur et j'ai affecté son adresse IP à une autre machine. Devinez ce qui se passe: j'ai droit à 7 pings et je ne reçois plus rien ! En gros l'imprimante doit faire un bloquage sur cette adresse IP en particulier. Pourtant, il n'y a aucune règle de filtrage sur cette machine (imprimante) et rien dans l'interface de config n'est prévu pour débloquer ma situation. J'ai juste activé le réseau TCP et désactivé tout le reste.
Je vais voir s'il existe une MAJ du firmware de la machine (une Kyocera 6950-FS pour info). En cas de problème, je peux toujours changer l'IP de mon serveur (mais ça m'embête car ça veut dire encore un arrêt de production)...
[^] # Re: A mon avis, ce n'est pas CUPS
Posté par totof2000 . Évalué à 2.
[^] # Re: A mon avis, ce n'est pas CUPS
Posté par totof2000 . Évalué à 2.
# Ah marche
Posté par Médéric RIBREUX (site web personnel) . Évalué à 1.
J'ai changé l'IP de mon serveur et depuis tout est OK ! Plus aucun problème... Je ne comprends pas ce qui pouvait bloquer. L'essentiel est que ça fonctionne.
Tchuss
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.