Come faccio a sapere se una porta seriale sta effettivamente trasmettendo dati, senza aprire il dispositivo?


10

Ho un cluster ad alta disponibilità (Heartbeat) collegato tramite linea seriale e due schede di rete Ethernet. Vorrei impostare uno script di monitoraggio in grado di riconoscere la linea seriale disconnessa (sostanzialmente la stessa domanda ha avuto una risposta in SO , tuttavia non sono soddisfatto di una risposta così generale).

Non riesco semplicemente ad aprire il dispositivo seriale e leggere i dati da solo, poiché Heartbeat apre la linea seriale.

Quindi ho iniziato a cercare alcuni indizi indiretti. L'unica differenza che ho trovato finora è nei contenuti di /proc/tty/driver/serial. Ecco come appare quando è collegato:

# 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

E quando disconnesso:

# 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

Non sono abbastanza sicuro di decidere che i segnali elencati alla fine della linea abbiano il significato stesso di cavo collegato / disconnesso in quanto non ho trovato alcuna documentazione sul contenuto di / proc / tty / driver / serial. Posso solo supporre che la presenza del segnale significhi che il segnale dato è "in questo momento" (o era in passato? O?). Il Serial HOWTO afferma che i segnali aggiuntivi presenti quando il cavo è collegato (segnale di controllo del flusso CTS, DSR "Sono pronto per comunicare", CD "Modem collegato a un altro") sono tutti nella direzione "input". Quindi ci deve essere qualcuno vivo dall'altra parte.

Supponendo che il significato dei segnali sia come descritto nel Serial HOWTO, posso basare la mia decisione sulla presenza, diciamo del segnale CD. Tuttavia non ne sono davvero sicuro.

Quindi la domanda è: il mio metodo è "giusto" o ho delle opzioni migliori di cui non sono a conoscenza?

EDIT: ho fatto alcune osservazioni aggiuntive e ho parlato con il mio collega. Risulta che la presenza o l'assenza di segnali alla fine della linea è un indicatore abbastanza buono dell'attività della porta seriale, su entrambe le estremità. Tuttavia, non è un indicatore della presenza fisica di un cavo. Ogni volta che c'era un programma che scriveva sulla porta seriale erano presenti segnali in uscita (RTS | DTR). Quando l'altra parte stava scrivendo i segnali in arrivo erano presenti (CTS | DSR | CD). Quando nessuno dei lati comunica non ci sono segnali (ciò non significa necessariamente che non sia presente alcun cavo). Non dimenticare che i segnali esatti dipendono dal cablaggio del cavo (ho "null modem con handshaking parziale").


Sembra un inizio ragione e facilmente testato. Potresti anche dare un'occhiata sotto '/ sys / devices / platform / serial8250 / tty / ttyS0 /', o qualcosa di simile sul tuo sistema.
rickhg12hs,

Risposte:


5

RS232 non ha alcun indicatore "presenza cavo" di alcun tipo. Stai solo ricevendo segnali di trasmissione o metadati (controllo), o non lo fai - questo è tutto ciò che sai. Se ricevi un segnale in ingresso (CTS | DSR | CD) sai che il cavo è collegato. Se non ricevi alcun segnale in ingresso, lo stato del cavo è indeterminato e non c'è modo di determinare se è collegato senza soluzioni hardware aggiuntive o eseguire un qualche tipo di scambio con il dispositivo remoto.

L'approccio abituale consiste nell'eseguire una sorta di trasmissione "keep-alive" (anche solo metadati, ad esempio impostare momentaneamente DTR e aspettarsi CTS) ma se la disciplina del protocollo utilizzata dal software alle due estremità del cavo vieta tale scambio inattivo, si ' sei praticamente bloccato con l'uso di un saldatore per procedere.

Quello che potresti provare è una sorta di "demone" aggiuntivo che imposta una pipe, inoltra i dati tra il tuo software e il dispositivo fisico (su entrambe le estremità), incapsulandolo - ed eseguendo "controlli di connessione" se la pipe è inattiva.

Consentitemi di aggiungere una soluzione piuttosto comune: se il dispositivo endpoint non utilizza il controllo hardware, è possibile abbreviare DTR con CTS all'interno della spina sul lato host e utilizzare il "controllo hardware" sul lato host. La generazione di DTR guida automaticamente CTS, abilitando la trasmissione, se il cavo è presente, quindi la trasmissione non è interessata. Nel frattempo, con il cavo assente, il sistema reagirà alla mancanza di CTS in modo adeguato a questo evento, ad esempio generando un timeout o sospendendo la trasmissione fino a quando il cavo non viene inserito.


La cosa "daemon" è un'idea intelligente. Tuttavia, non lo implementerò poiché temo che diventerà una fonte di bug di stabilità. Continuerò a leggere i segnali da / proc e solo a indicare la presenza o l'assenza di singoli in entrata / in uscita. Questo è sufficiente per me.
Peter Kovac,

È come il gatto di Schrodinger. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
Ufoguy

0

C'è un indicatore di presenza che ti dice che hai un dispositivo collegato all'altra estremità, ma è opzionale, la trasmissione funziona con o senza il segnale di presenza.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.