Creation d'un serveur SANE (numérisation) sur Debian

Bonjour,

J’ai fais quelques forums ou à priori ma question n’a pas sa place.

Je dispose d’un ordinateur avec Debian sans interface graphique que j’administre à distance via SSH.
J’ai relié une imprimante/scanneur par USB. L’imprimante fonctionne via un serveur CUPS.
La partie scanneur ne fonctionne pas tout à fait. Debian partage le scanneur sur le réseau, un des clients sous Ubuntu peut le voir mais ne peut l’utiliser. Les autres clients sous W10 peuvent aussi voir le scanneur via Twain Sane mais ne peuvent l’utiliser.

Quelqu’un pourrait il m’aider ?
La documentation trouvé sur internet et les forums ne m’a pas aidé.

Alfly

Bonjour,

as tu des messages d’erreurs sur le serveur’?

Quel modèle de quelle marque ?

Sans plus d’informations, je ne vois pas.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

Merci déjà à vous 2 de me consacrer du temps.

Le scanneur est un HP deskjet 2130 comme le donne les
commandes suivantes :

scanimage -L
device `hpaio:/usb/DeskJet_2130_series?serial=CN66F4B36Y065T' is a Hewlett-Packard DeskJet_2130_series all-in-one
device `net:127.0.0.1:hpaio:/usb/DeskJet_2130_series?serial=CN66F4B36Y065T' is a Hewlett-Packard DeskJet_2130_series all-in-one

sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

found USB scanner (vendor=0x03f0 [HP], product=0xe111 [DeskJet 2130 series]) at libusb:002:003
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.

Je n’ai pas de message d’erreur sur le serveur.
Le client Ubuntu me donne « echec de numérisation, impossible de se connecter au
périphérique de numérisation ». Message similaire avec Twain Sane sous W10.

Voici ce que je peux vous donner comme infos :

Mon access list donne ceci :

cat /etc/sane.d/saned.conf

# saned.conf

# Configuration for the saned daemon

## Daemon options

# Port range for the data connection. Choose a range inside [1024 - 65535].

# Avoid specifying too large a range, for performance reasons.

#

# ONLY use this if your saned server is sitting behind a firewall. If your

# firewall is a Linux machine, we strongly recommend using the

# Netfilter nf_conntrack_sane connection tracking module instead.

#

# data_portrange = 10000 - 10100

## Access list

localhost

10.0.0.1/24

192.168.1.0/24

# A list of host names, IP addresses or IP subnets (CIDR notation) that

# are permitted to use local SANE devices. IPv6 addresses must be enclosed

# in brackets, and should always be specified in their compressed form.

#

# The hostname matching is not case-sensitive.

#scan-client.somedomain.firm

#192.168.0.1

#192.168.0.1/29

#[2001:db8:185e::42:12]

#[2001:db8:185e::42:12]/64

# NOTE: /etc/inetd.conf (or /etc/xinetd.conf) and

# /etc/services must also be properly configured to start

# the saned daemon as documented in saned(8), services(4)

# and inetd.conf(4) (or xinetd.conf(5))./

Le fichier Net.conf du serveur Sane :

cat /etc/sane.d/net.conf

# This is the net backend config file.

## net backend options

# Timeout for the initial connection to saned. This will prevent the backend

# from blocking for several minutes trying to connect to an unresponsive

# saned host (network outage, host down, ...). Value in seconds.

# connect_timeout = 60

## saned hosts

# Each line names a host to attach to.

# If you list "localhost" then your backends can be accessed either

# directly or through the net backend. Going through the net backend

# may be necessary to access devices that need special privileges.

10.0.0.1/24

localhost

Netstat :

netstat -anlp | grep 6566
tcp6       0      0 :::6566                 :::*                    LISTEN      1/init

Id saned :

id saned

uid=115(saned) gid=121(saned) groupes=121(saned),7(lp),120(scanner)

Les droits :

ls -lR /dev/bus/usb/002/003

crw-rw-rw- 1 saned saned 189, 130 nov. 22 12:04 /dev/bus/usb/002/003

Ton serveur n’écoute pas en ipv4, donc tes utilisateurs ne peuvent pas s’y connecter. Comme ta configuration des ACL et autre est en ipv4 ca ne peut pas marcher.

Comment je peux m’y prendre pour lui faire écouter en IPV4 ?

Dans le fichier /etc/service j’ai cette ligne :

sane-port 6566/tcp sane saned # SANE network scanner daemon

Sur certaines pages internet je trouve :

sane 6566/tcp saned # SANE network scanner daemon

Y a t’il une différence ?

AH… il ne s’agit pas du port, mais de l’adresse d’écoute, la configuration réseau du service.
Le port d’écoute ca vient après, ou ici avec mais c est l’adressage qu’il faut déjà considérer.

Non.
La sortie de netstat affiche tcp6, mais cela ne veut pas dire qu’il n’est pas en écoute en IPv4. Les IPv4 sont aussi des IPv6. Dès qu’un client tentera d’établir une connexion en IPv4 tcp sur Ipv4 sera visible dans la sortie de netstat.

Le retour de :

systemctl status saned.socket

indiquera l’adresse et le port d’écoute.

J’ai rien trouvé de louche dans la config reseau.

Voici le retour de la commande :

systemctl status saned.socket
● saned.socket - saned incoming socket
   Loaded: loaded (/etc/systemd/system/saned.socket; enabled; vendor preset: ena
   Active: active (listening) since Sat 2020-12-05 17:15:10 CET; 2h 58min ago
   Listen: [::]:6566 (Stream)
 Accepted: 2; Connected: 1; Refused: 1
    Tasks: 0 (limit: 4591)
   Memory: 168.0K
   CGroup: /system.slice/saned.socket

déc. 05 17:15:10 OpenMediaVault.local systemd[1]: Listening on saned incoming so
déc. 05 19:29:31 OpenMediaVault.local systemd[1]: saned.socket: Too many incoming

- 1 !!! (pour ne pas dire -47 !)
J’hallucine de voir écrit cela. IPv4 et IPv6 sont deux protocoles différents, l’adressage IP est différent, etc…

Beh, si ; si cétait le cas, netstat aurait affiché l’équivalent IPv4 - mais je peux me tromper.

https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Stateless_IP/ICMP_Translation :

Stateless IP/ICMP Translation (SIIT) translates between the packet header formats in IPv6 and IPv4.[2] The SIIT method defines a class of IPv6 addresses called IPv4-translated addresses.[3] They have the prefix ::ffff:0:0:0/96 and may be written as ::ffff:0:a.b.c.d, in which the IPv4 formatted address a.b.c.d refers to an IPv6-enabled node.

et https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses

Une adresse IPv4 peut être représentée en IPv6 ce qui permet l’usage du protocole TCP sur de l’IPV4 sur un socket IPv6.

En prenant en compte les 2 « théories » que dois-je vérifier car je suis complètement perdu là.
J’ai pensé tout refaire depuis zéro mais je crains qu’un ancien fichier de configuration ne subsiste à la désinstallation des paquets.

Peut-être représenté, en effet.

En effet !

Mais IPv4 n’est en rien de l’IPv6, ce sont ABSOLUMENT deux protocoles différents qui ne peuvent communiquer ensemble QUE SI des « ponts » sont créés pour…
Et, ce n’est pas parce que tu fais une représentation de ton adresse IPv4 en IPv6, donc sur 128 bits, au lieu des 32 bits, que tu pourras communiquer sur IPv6 ; il faut en sus utiliser une « astuce » (l’usage d’un nœud IPv6) qui le permette. De fait, ce n’est plus de l’IPv4, mais bel et bien de l’IPv6 !
Dixit :

The SIIT method defines a class of IPv6 addresses called IPv4-translated addresses

Donc, je maintiens les adresses IPv4 ne sont pas des adresses IPv6 et inversement.


Quoiqu’il en soit, on s’écarte très fortement du sujet !!!
Donc, je recadre : problème de communication avec un serveur Sane ! :wink:

[HS] C’est peut-être un raccourci, mais oui les adresses IPv4 sont aussi des adresses IPv6 et on peut communiquer ainsi en IPv4 avec une machine/un service en IPv6 de manière transparente.
cf. https://tools.ietf.org/html/rfc3493#section-3.7
Et oui c’est bien ce que j’ai dit : c’est de l’IPv6 (puisqu’encore une fois une IPv4 est représentée aussi en IPv6). Je n’ai jamais dit que l’IPv4 était de l’IPv6, merci de ne pas déformer mes propos. [/HS]

Peut-être un retour de :

scanimage -L

sur le client.

Bon concours de circonstance, Ubuntu ne veut pas démarrer. J’ai Ubuntu en virtualisé sur un W10 qui ne trouve rien via cette commande.

Je tente de relancer l’autre ordi pour faire la commande.

Le client Ubuntu renvoi :

scanimage -L
device `net:192.168.1.91:hpaio:/usb/DeskJet_2130_series?serial=CN66F4B36Y065T' is a Hewlett-Packard DeskJet_2130_series all-in-one

Il faut peut-être un pilote sur le client.
Est-ce que hplip est installé ?
Voir aussi https://wiki.debian.org/fr/SaneOverNetwork

Il est installé. Je viens de le mettre à jour. Mais toujours pareille. J’ai verifié le fichier « /etc/sane.d/net.conf » mais j’ai bien l’IP du serveur et son nom.

Le backend ‹ net › est bien activé aussi. Du coté serveur j’avais bien installé les paquets également et fait comme les explications du lien. Le serveur se met actuellement à jour, je vais voir si ça y fait.

edit : après mise à jour serveur en rad, pas de ssh, pas de connection web. Je re-install tous (pfffff) et je reviens vers vous pour vous tenir informé.

Pour ça il faut activer IPv6to4 sinon ça ne marche pas. Ca ne l’est pas en standard. Car effectivement on peut encaposuler IPv4 dans IPv6 grace à ça.
mais sin netstat ne dit pas qu’il y a un tcp ouvert sur une IPv4 c’est qu’il n’y en a pas. et de toute façon l’IPv6 en question est la boucle locale, donc inaccessible de l’exterieur.

Je t’invite à lire les liens que j’ai donné et à ne pas poursuivre le hors-sujet ici.
J’ai plusieurs services qui n’apparaissent que sous tcp6 avec netstat ou ss et qui sont parfaitement joignables en IPV4 sans aucun tunnel.