Comment savoir si un port série transmet réellement des données sans ouvrir l'appareil?


10

J'ai un cluster à haute disponibilité (Heartbeat) connecté via une ligne série et deux cartes réseau Ethernet. Je voudrais mettre en place un script de surveillance capable de reconnaître la ligne série déconnectée (essentiellement la même question a été répondue à SO , mais je ne suis pas satisfait d'une réponse aussi générale).

Je ne peux pas simplement ouvrir le périphérique série et lire les données moi-même, car la ligne série est ouverte par Heartbeat.

J'ai donc commencé à chercher des indices indirects. La seule différence que j'ai trouvée jusqu'à présent réside dans le contenu de /proc/tty/driver/serial. Voici à quoi cela ressemble quand il est connecté:

# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:2722759 rx:2718165 brk:1 RTS|CTS|DTR|DSR|CD

Et une fois déconnecté:

# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:2725233 rx:2720703 brk:1 RTS|DTR

Je ne suis pas assez confiant pour décider que les signaux répertoriés à la fin de la ligne ont la même signification que de câble connecté / déconnecté car je n'ai trouvé aucune documentation sur le contenu de / proc / tty / driver / serial. Je peux seulement supposer que la présence du signal signifie que le signal donné est activé "en ce moment" (ou était dans un passé récent? Ou?). Le Serial HOWTO dit que les signaux supplémentaires présents lorsque le câble est connecté (signal de contrôle de flux CTS, DSR "Je suis prêt à communiquer", CD "Modem connecté à un autre") sont tous dans le sens "entrée". Il doit donc y avoir quelqu'un en vie à l'autre bout.

En supposant que la signification des signaux est telle que décrite dans le Serial HOWTO, je peux baser ma décision sur la présence, par exemple, d'un signal CD. Mais je n'en suis pas vraiment sûr.

La question est donc: ma méthode est-elle "correcte", ou ai-je de meilleures options que je ne connais pas?

EDIT: J'ai fait quelques observations supplémentaires et j'ai eu une conversation avec mon collègue. Il s'avère que la présence ou l'absence de signaux à la fin de la ligne est un assez bon indicateur de l'activité du port série, aux deux extrémités. Cependant, ce n'est pas un indicateur de la présence physique d'un câble. Chaque fois qu'un programme écrivait sur le port série, des signaux sortants étaient présents (RTS | DTR). Lorsque l'autre côté écrivait, des signaux entrants étaient présents (CTS | DSR | CD). Quand aucun des côtés ne communique, il n'y a aucun signal (cela ne signifie pas nécessairement qu'il n'y a pas de câble présent). N'oubliez pas que les signaux exacts dépendent du câblage du câble (j'ai "null modem avec prise de contact partielle").


Cela ressemble à un démarrage raisonnable et à un test facile. Vous pouvez également consulter «/ sys / devices / platform / serial8250 / tty / ttyS0 /», ou quelque chose de similaire sur votre système.
rickhg12hs

Réponses:


5

RS232 n'a aucun indicateur de "présence de câble" d'aucune sorte. Vous ne faites que transmettre des signaux de transmission ou de métadonnées (contrôle), ou vous ne le faites pas - c'est tout ce que vous savez. Si vous recevez un signal entrant (CTS | DSR | CD), vous savez que le câble est connecté. Si vous ne recevez aucun signal entrant, l'état du câble est indéterminé et il n'y a aucun moyen de déterminer s'il est branché sans solutions matérielles supplémentaires - ou d'effectuer une sorte d'échange avec le périphérique distant.

L'approche habituelle consiste à effectuer une sorte de transmission "persistante" (même juste des métadonnées - par exemple, définissez momentanément DTR et attendez CTS), mais si la discipline du protocole utilisé par les logiciels aux deux extrémités du câble interdit un tel échange inactif, vous '' re à peu près coincé avec l'utilisation d'un fer à souder pour continuer.

Ce que vous pourriez essayer, c'est une sorte de "démon" supplémentaire qui configure un canal, transmettant des données entre votre logiciel et le périphérique physique (aux deux extrémités), l'encapsulant - et effectuant des "vérifications de connexion" si le canal est inactif.

Permettez-moi d'ajouter une solution plutôt courante: si votre périphérique d'extrémité n'utilise pas le contrôle matériel, vous pouvez court-circuiter DTR avec CTS à l'intérieur de la prise côté hôte et utiliser le «contrôle matériel» côté hôte. La génération de DTR entraîne automatiquement CTS, permettant la transmission, si le câble est présent, de sorte que la transmission n'est pas affectée. Pendant ce temps, en l'absence de câble, le système réagira au manque de CTS d'une manière appropriée à cet événement, par exemple en générant un timeout ou en suspendant la transmission jusqu'à ce que le câble soit branché.


La chose "démon" est une idée intelligente. Cependant, je ne vais pas l'implémenter car j'ai peur qu'il devienne une source de bugs de stabilité. Je m'en tiendrai à la lecture des signaux de / proc et à l'indication de la présence ou de l'absence de chants entrants / sortants. Ca suffit pour moi.
Peter Kovac

C'est comme le chat de Schrodinger. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
Ufoguy

0

Un indicateur de présence vous indique que vous avez un appareil connecté à l'autre extrémité, mais il est facultatif, la transmission fonctionne avec ou sans le signal de présence.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.