9

I have a high-availability cluster (Heartbeat) connected via serial line and two ethernet NICs. I'd like to set up a monitoring script capable of recognizing disconnected serial line (basically the same question was answered at SO, however I am not satisfied with such a general answer).

I cannot simply open the serial device and read the data myself, since the serial line is opened by Heartbeat.

So I started to look for some indirect clues. The only difference I have found so far is in the contents of /proc/tty/driver/serial. This is how it looks like when it's connected:

# 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

And when disconnected:

# 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

I'm not confident enough to decide that the signals listed at the end of the line have the very meaning of connected/disconnected cable as I have not found any documentation on the contents of the /proc/tty/driver/serial. I can only assume that the presence of the signal means the given signal is on "right now" (or was in recent past? or?). The Serial HOWTO says that additional signals present when the cable is connected (CTS flow control signal, DSR "I'm ready to communicate", CD "Modem connected to another") are all in the "input" direction. So there has to be somebody alive at the other end.

Assuming that meaning of signals is as described in the Serial HOWTO, I can base my decision on the presence of, say CD signal. However I am not really sure.

So the question is: is my method "right", or do I have any better options I am not aware of?

EDIT: I did some additional observations and had a talk with my colleague. Turns out the presence or absence of signals at the end of the line is quite good indicator of the serial port activity, on both ends. However, it's not an indicator of physical presence of a cable. Whenever there was a program writing to serial port outgoing signals were present (RTS|DTR). When the other side was writing incoming signals were present (CTS|DSR|CD). When none of the sides communicates there are no signals at all (that does not necessarily mean there is no cable present). Don't forget that the exact signals depend on the wiring of the cable (I have "null modem with partial handshaking").

Improve this question
1
  • Sounds like a reasonabke start and one easily tested. You might also have a look under '/sys/devices/platform/serial8250/tty/ttyS0/', or something similar on your system. Commented Nov 26, 2013 at 22:23

2 Answers 2

Reset to default
5

RS232 has no "cable presence" indicator of any kind. You're just getting transmission or metadata (control) signals through, or you don't - that's all you know. If you receive an incoming signal (CTS|DSR|CD) you know the cable is connected. If you don't receive any incoming signal, the state of the cable is indeterminate and there is no way to determine if it's plugged in without additional hardware solutions - or performing some kind of exchange with the remote device.

The usual approach is performing some kind of "keep-alive" transmissions (even just metadata - e.g. momentarily set DTR and expect CTS) but if the discipline of protocol used by software at the two ends of the cable forbids such idle exchange, you're pretty much stuck with using a soldering iron to proceed.

What you might try, is some kind of additional "demon" that sets up a pipe, forwarding data between your software and the physical device (on both ends), encapsulating it - and performing "connection checks" if the pipe is idle.

Let me add one rather common solution: if your endpoint device doesn't use hardware control, you can short DTR with CTS inside the plug on the host side and use 'hardware control' on the host side. Generating DTR automatically drives CTS, enabling the transmission, if the cable is present, so transmission is unaffected. Meanwhile, with cable absent, the system will react to lack of CTS in a manner appropriate to this event, e.g. generating a timeout or suspending transmission until the cable is plugged in.

Improve this answer
2
  • The "daemon" thing is a clever idea. However, I'm not going to implement it since I'm afraid it will become a source of stability bugs. I'll stick to reading signals from /proc and just indicating the presence or absence of incoming/outcoming singals. That's enough for me. Commented Nov 29, 2013 at 8:43
  • It's like Schrodinger's cat. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat Commented Jan 26, 2014 at 7:24
0

There is a presence indicator to tell you that you have a device connected to the other end, but it is optional, transmission works with or without the presence signal.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.