Forum Linux.debian/ubuntu CUPS a des problèmes réseaux...

Posté par (page perso) .
Tags : aucun
0
30
avr.
2008
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 ?
  • # A mon avis, ce n'est pas CUPS

    Posté par . Évalué à 2.

    Le titre de ton message est un peu méchant. La sémantique de connect(); l'appel fait pour établir une connexion, ne permet pas de distinguer la réception du SYN/ACK du ACK suivant; donc s'il y a un bug à ce niveau, c'est dans le kernel linux et pas dans CUPS

    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 (page perso) . Évalué à 2.

      Et regarde aussi tes logs cups.
      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 (page perso) . Évalué à 1.

        Hello,

        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 . Évalué à 2.

          Ne serait-ce pas l'IP deton serveur CUPS ui est dupliquée?

          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 (page perso) . Évalué à 1.

            Encore du neuf à s'arracher les cheveux. J'ai l'impression que c'est cette satanée imprimante qui joue des siennes. En effet, lorsque je la réinitialise (peu importe son adresse IP), je peux la pinguer de mon serveur pendant 7 pings. Après, je ne reçois plus rien !
            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)...
  • # Ah marche

    Posté par (page perso) . Évalué à 1.

    Encore du neuf...
    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.