Discussion :

[Aurelienjjj]

Bonjour

J'aurais besoin de conseils concernant l'utilisation de ports serial sous Linux. Actuellement, je travaille sur un serveur qui envoie des informations en direction de ports serial/com (l'USB quoi) , passant par une base de données afin de savoir vers quel port envoyer telle ou telle information, et savoir qui communique avec le serveur.

Malheureusement, au redémarrage du serveur, les ports ne sont plus dans le même ordre (usb0 devient l'usb1 et l'usb1 l'usb0 par exemple), invalidant les redirections des valeurs reçues/envoyées. J'ai pensé qu'il y avait un ordre de repositionnement des ports, mais ça ne semble pas être le cas, les échanges de ports semblant anarchiques.

Ma question est donc la suivante: y a t-il moyen de renommer les ports de mon serveur de manière à ce que, par exemple, un port réponde toujours au nom "usbX", qu'il soit branché en Xeme position ou pas. Et si ce n'est pas le cas, existe-t-il des alternatives à cela?
ti
distribution: Debian Squeeze (sans mode graphique)

Ps: je ne m'y connais qu'assez peu en Linux, n'hésitez donc pas à me donner des détails sur les commandes à utiliser, ou au moins des liens vers des tutos.

Merci d'avance!

[mvvvv]

Je ne sais pas si on peut réserver un BUS/Device à l'affectation d'un périphérique usb donné

mais il est possible de trouver toutes les informations d'un device usb grace à lsusb (en utilisant son identification)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
~ > lsusb -d413c:2003
Bus 001 Device 004: ID 413c:2003 Dell Computer Corp. Keyboard

[Obsidian]

Hello,

J'aurais besoin de conseils concernant l'utilisation de ports serial sous Linux. Actuellement, je travaille sur un serveur qui envoie des informations en direction de ports serial/com (l'USB quoi)

Les ports série et l'USB n'ont rien à voir entre eux et leurs technologies respectives sont très éloignées. Cela dit, tu parles peut-être d'un adaptateur RS/232 se branchant sur le port USB et étant déclaré comme un port série du côté système.

Malheureusement, au redémarrage du serveur, les ports ne sont plus dans le même ordre (usb0 devient l'usb1 et l'usb1 l'usb0 par exemple), invalidant les redirections des valeurs reçues/envoyées. J'ai pensé qu'il y avait un ordre de repositionnement des ports, mais ça ne semble pas être le cas, les échanges de ports semblant anarchiques.

Elle ne sont pas anarchiques mais à partir du moment où tes adaptateurs peuvent être branchés sur n'importe quels ports USB et que ceux-ci peuvent accueillir n'importe quels types de périphérique, il n'y a rien qui permette au système de choisir un ordre plutôt qu'un autre. Dans ce cas, l'allocation est automatique et c'est le premier à s'énumérer qui récupérera le plus petit numéro.

Ma question est donc la suivante: y a t-il moyen de renommer les ports de mon serveur de manière à ce que, par exemple, un port réponde toujours au nom "usbX", qu'il soit branché en Xeme position ou pas. Et si ce n'est pas le cas, existe-t-il des alternatives à cela?

Il y en a mais ce n'est pas facile de prime abord. Il faut faire cela au niveau de « udev ». Il faut d'abord choisir un critère de sélection : soit tu as deux adaptateurs distincts et dans ce cas, tu les discrimines avec leur identifiants produit et fabricant comme indiqué par mvvvv, soit ce sont les mêmes et dans ce cas, tu les différencies par les ports sur lesquels ils sont branchés.

Il faut ensuite écrire la règle udev correspondante. Tu peux effectivement demander à associer un fichier spécial « /dev » donné pour cela, mais c'est un peu pénible parce que ça rentre en conflit avec d'autres règles, ainsi qu'avec les requêtes du pilote lui-même et tu te retrouves parfois avec des fichiers en double. En plus, il faut veiller à ne pas utiliser un nom de fichier habituel car celui peut avoir été déjà affecté.

Par contre, tu peux aussi demander à ce que le système crée un lien symbolique sur le fichier qu'il aura alloué tout seul ! Ça, c'est le meilleur plan car ça te permet de lui donner un nom explicite et tu sais qu'il pointera toujours le bon fichier quelque soit la manière dont le système a choisi de les répartir.

À titre d'exemple, voici ce que j'ai fait pour mes joysticks. L'un est un joystick à retour de force, l'autre est en fait un palonnier d'aviation. J'avais besoin d'avoir toujours une vue sur le premier pour faire fonctionner un pilote écrit par mes soins :

Code udev :

Sélectionner tout - Visualiser dans une fenêtre à part

KERNEL=="js*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c286", SYMLINK+="input/jslogitech3dpro"

Ces règles vont dans un des fichiers du répertoire /etc/udev/rules.d.

La marche à suivre est ici : http://www.reactivated.net/writing_udev_rules.html

[mvvvv]

@Obsidian

n'y a t il pas déjà des règles prédéfinies pour certains périphériques référencés ?

Je pense aux video0 pour les webcam ou printer pour les imprimantes ?

[mvvvv]

j'ai trouvé :

tout est sous /lib/udev/rules.d


tout est expliqué là

http://doc.ubuntu-fr.org/udev

[Obsidian]

j'ai trouvé :
tout est sous /lib/udev/rules.d

C'est ce que j'ai écrit en bas de mon commentaire, mais ce n'est pas grave.

tout est expliqué là http://doc.ubuntu-fr.org/udev

Merci pour la doc en français.

[Aurelienjjj]

Je ne sais pas si on peut réserver un BUS/Device à l'affectation d'un périphérique usb donné

mais il est possible de trouver toutes les informations d'un device usb grace à lsusb (en utilisant son identification)

Merci pour la commande, je ne connaissais pas. Ca peut toujours servir!

Les ports série et l'USB n'ont rien à voir entre eux et leurs technologies respectives sont très éloignées. Cela dit, tu parles peut-être d'un adaptateur RS/232 se branchant sur le port USB et étant déclaré comme un port série du côté système.

Oui, je me suis mal exprimé, mais c'est (a peu près) ça: le serveur est branché via ports USB (a des cartes faites maisons), qui sont considérés comme serial. Je faisais d'ailleurs bien mes tests avec un adaptateur USB-RS232. Les cartes sont reliés aux PC via de l'USB.

J'ai donc commencé à lire la doc de l'udev, j'ai essayé de faire ma propre config, mais à priori, ça n'a pas l'air de fonctionner, il y a de grandes chances donc que j'ai fait une connerie.

Pour résumer ma démarche, donc j'ai créé un fichier (nommé "10-local.rules" comme dans l'exemple de l'udev) dans etc/udev/.
Son contenu:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
KERNEL=="event0", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0024", SYMLINK+="input/event0"  NAME="USB12"
KERNEL=="event1", ATTRS{idVendor}=="1d6b", ATTRS{idProduct}=="0002", SYMLINK+="input/event0"  NAME="USB40"
KERNEL=="event2", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", SYMLINK+="input/event0"  NAME="USB44"

(Je teste sur 3 ports différents pour tester)
Avec:
KERNEL=="event0" -> nom supposé des cartes, trouvé dans /dev/input/
ATTRS{idVendor}=="8087" -> premiere valeur donnée via lsusb (merci mvvv)
ATTRS{idProduct}=="0024" -> la seconde valeur donnée via lsusb
SYMLINK+="input/event0" -> le lien vers le supposé fichier de ma carte, dans /dev/
NAME="USB40" -> le nom que je souhaiterai donner a mes ports (usb0 ou 1 ne serait pas assez flagrant)

Voila, je suppose que j'ai du faire une gourde, donc je poste l'explication de ce que j'ai fais. Merci de l'aide en tout cas.

Edit: Au passage, il faut redémarrer entre chaque modif, ou il existe une commande pour relancer l'udev?

[mvvvv]

Tu dois pouvoir enlever le discriminant Kernel ... avec les identifiants des périphériques tu es sûr de ne pas te tromper.

Et sinon essaye sans le NAME peut être (tu as oublié la virgule devant sinon)

[Obsidian]

C'est presque ça, mais le paramètre après « SYMLINK+= » est le nom que tu vas donner à ton lien symbolique (celui-là même que tu essaies de passer avec NAME). Il va automatiquement pointer le bon device.

Il faut en outre penser à séparer les différentes clauses avec une virgule « , ».

[Aurelienjjj]

Arg.

Merci de vos aides, j'ai bien vu qu'il y avait quelques problèmes dans mon code (pas de virgule, nom dupliqué, etc), j'ai refais quelques modifications, mais après pas mal de temps à tester... Je commence à baisser les bras. Je me demande s'il n'y a pas un soucis sur le serveur, tout simplement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#SUBSYSTEM=="tty", ATTRS{Serial}=="A400eNQQ", SYMLINK+="USB42", NAME="Port0"
#SUBSYSTEM=="tty", ATTRS{iSerial}=="A400eNQM", SYMLINK+="USB43"
#SUBSYSTEM=="tty", ATTRS{iSerial}=="A400eNJT", SYMLINK+="USB44", NAME="Port2"
#SUBSYSTEM=="usb", ATTRS{iSerial}=="A400eNQM", KERNEL=="ttyUSB*", NAME="input/Port1", SYMLINK+="USB43"
 
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{serial}=="A400eNQQ", SYMLINK+="MonUSB0"

Même un simple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SUBSYSTEMS=="tty", NAME="input/port1"

Ne fonctionne pas, l'entrée /dev/input/port1 (qui devrait correspondre à ce que je reçois dans mon code, lorsque je fais un port.getname() ) n'apparait pas. Je continue de plancher, et je posterai la réponse si je la trouve, mais je pense qu'il y a un soucis.

[mvvvv]

n'hésite pas à parcourir toutes les configurations sous /lib/udev/rules.d

Déjà tu y trouveras comment tes périphériques sont gérés par défaut.

Bon courage

[Obsidian]

Que donnerait ceci ?

Code udev :

Sélectionner tout - Visualiser dans une fenêtre à part

SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0024", SYMLINK+="USB12"

Si tu ne vois pas apparaître « USB12 », fais une recherche avec find sur le répertoire /dev et tout ce qu'il y a au-dessous.

Ne te focalise pas sur « input/ ». C'est un répertoire réservé aux périphériques de classe INPUT sur les infrastructures qui la définissent. Autrement dit, tous les périphériques de saisie : clavier, souris, tablettes, touchpads, joysticks, etc. à l'exception de ceux qui se branchent déjà sur les ports natifs consacrés à cet effet : clavier/souris sur le port PS/2 ou série, joystick sur le port joystick lorsqu'il existent encore, etc. Ça veut dire aussi qu'ils sont gérés en partie par un module noyau particulier, qui prend en charge tout ce qui est commun à ces périphériques lorsque ceux-ci sont capables de se déclarer comme tels.

[Aurelienjjj]

Bien!

Voilà ou j'en suis (pour ceux que ça pourrait aider): à priori, ma prise en charge par Linux est bonne, le changement de nom se fait bel et bien:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{Serial}=="A400eNQQ", SYMLINK+="USB12", NAME="ttyUSB12"

Un "udevadm info -a -n USB12" me confirme bien que ce port contient ce qui m'est demandé, la partie Linux du problème semble résolue.
Le problème, c'est que le code Java distribuant les données (via la bibliothèque RxTx) ne prend pas cette modification en compte: mon port.getname() me renvoie toujours les ports "ttyUSB0/1/2" en entrée, aucun port 12 en vue (alors que mon USB12 est bien connecté à un device contenant mon serial).
Bref, deux solutions pour moi: une solution logicielle (un port.get"truc_qui_m_arrange_pour_repererl_e_port"(mais c'est pas le bon forum pour cela)), soit une modification d'une donnée qui sera prise par le code java port.getname() ...

Bref, arg.

(Dois-je mettre en résolu?)

[Obsidian]

Le problème, c'est que le code Java distribuant les données (via la bibliothèque RxTx) ne prend pas cette modification en compte: mon port.getname() me renvoie toujours les ports "ttyUSB0/1/2" en entrée, aucun port 12 en vue (alors que mon USB12 est bien connecté à un device contenant mon serial).

Déjà, « USB12 » est-il bien au même endroit que les autres ?

Ensuite, j'ai effectivement le même problème avec d'autres logiciels, comme X-Plane. Il y a plusieurs raisons possibles à cela :

• soit le logiciel s'appuie sur le préfixe du fichier et dans ce cas, tu peux essayer de remplacer « USB12 » par « ttyUSBmachintruc12 » ;
• soit le logiciel vérifie que le fichier qu'il lit dans le répertoire est bien un fichier spécial et, dans ce cas, il passe le lien symbolique. Dans ce cas, il faudra utiliser NAME pour en faire un vrai. Le problème, c'est qu'au niveau du système, il s'agit alors de deux fichiers spéciaux distincts qui, en coulisses, accèdent au même périphérique et ça peut court-circuiter certains contrôles comme l'ouverture exclusive ;
• soit le logiciel s'appuie sur le préfixe ET le suffixe, genre « ttyUSB0 » , « ttyUSB1 » et si le suffixe ne correspond pas à un numéro valide, ça peut suffire à le faire échouer.

[Aurelienjjj]

En fait, j'utilise déjà NAME, mais le fichier correspondant au NAME n'apparait pas dans le dossier /dev (alors quel es SYSLINK, eux, apparaissent bien... )... Je flaire l'erreur quelque part, mais je ne vois pas où.

[mvvvv]

A en croire la doc, il est sensible : comme il s'agit du node d'accès au périphérique.

à en croire le man udev :

NAME
What a network interface should be named.

Also, as a temporary workaround, this is what a device node should be named; usually the kernel
provides the defined node name or creates and removes the node before udev even receives any
event. Changing the node name from the kernel's default creates inconsistencies and is not
supported. If the kernel and NAME specify different names, an error is logged. udev is only
expected to handle device node permissions and to create additional symlinks, not to change
kernel-provided device node names. Instead of renaming a device node, SYMLINK should be used.
However, symlink names must never conflict with device node names, as that would result in
unpredictable behavior.

[Aurelienjjj]

Arg... Alors, y a pas moyen de forcer le nom des ports USB sur une valeur alors?

Mince, ça fait vraiment chier.

[mvvvv]

Tu dois d'ailleurs voir les erreurs de ton NAME dans tes DMESG.


Si j'ai bien compris c'est ton code java qui te casse les pieds ? De quelle classe s'agit-il ?

[Aurelienjjj]

Difficile à dire. J'ai vérifié dans le /var/log/Dmesg, je n'ai rien trouvé de mon oeil de newbie Linux (mais j'ai redémarré et retiré mes NAME inutiles, donc il est possible que les logs d'erreurs ait simplement été supprimés/écrasés)

C'est bien le code java qui "casse les pieds" en quelque sorte, j'utilise la classe RxTx pour communiquer via les ports USB, le soucis étant que l'utilisation de plusieurs ports implique une redirection, qui n'est faisable qu'en aveugle et via des ports connus (je veux dire: il n'y a "aucun" moyen de reconnaitre un périphérique branché sur tel ou tel port via les informations en transit, il faut donc connaitre d'avance quel périphérique est branché sur quel port, d’où l’intérêt de noms fixes pour les ports) . Pour communiquer via ces ports, j'ouvre la communication sur les ports detectés(RxTx.open(port.getname() ) en gros).

Je peux, comme solution "sale", brancher les appareils dans l'ordre de découverte machine des ports usb (ainsi au redémarrage, les ports sont toujours dans le même ordre), mais c'est sale, et un renommage fixe et stable serait plus intéressant pour moi.

[mvvvv]

Bha sinon tu recherches le node rattaché à ton symlink (qui devient juste un index)