How do I know if a serial port is actually transmitting data, without opening the device?
Clash Royale CLAN TAG#URR8PPP
up vote
10
down vote
favorite
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").
linux proc serial-port
add a comment |
up vote
10
down vote
favorite
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").
linux proc serial-port
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.
– rickhg12hs
Nov 26 '13 at 22:23
add a comment |
up vote
10
down vote
favorite
up vote
10
down vote
favorite
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").
linux proc serial-port
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").
linux proc serial-port
linux proc serial-port
edited May 23 '17 at 12:40
Community♦
1
1
asked Nov 26 '13 at 16:39
Peter Kovac
2402410
2402410
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.
– rickhg12hs
Nov 26 '13 at 22:23
add a comment |
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.
– rickhg12hs
Nov 26 '13 at 22:23
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.
– rickhg12hs
Nov 26 '13 at 22:23
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.
– rickhg12hs
Nov 26 '13 at 22:23
add a comment |
2 Answers
2
active
oldest
votes
up vote
5
down vote
accepted
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.
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.
– Peter Kovac
Nov 29 '13 at 8:43
It's like Schrodinger's cat. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
– Ufoguy
Jan 26 '14 at 7:24
add a comment |
up vote
0
down vote
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.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
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.
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.
– Peter Kovac
Nov 29 '13 at 8:43
It's like Schrodinger's cat. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
– Ufoguy
Jan 26 '14 at 7:24
add a comment |
up vote
5
down vote
accepted
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.
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.
– Peter Kovac
Nov 29 '13 at 8:43
It's like Schrodinger's cat. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
– Ufoguy
Jan 26 '14 at 7:24
add a comment |
up vote
5
down vote
accepted
up vote
5
down vote
accepted
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.
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.
edited Nov 20 at 8:10
answered Nov 27 '13 at 9:54
SF.
1,57921624
1,57921624
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.
– Peter Kovac
Nov 29 '13 at 8:43
It's like Schrodinger's cat. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
– Ufoguy
Jan 26 '14 at 7:24
add a comment |
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.
– Peter Kovac
Nov 29 '13 at 8:43
It's like Schrodinger's cat. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
– Ufoguy
Jan 26 '14 at 7:24
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.
– Peter Kovac
Nov 29 '13 at 8:43
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.
– Peter Kovac
Nov 29 '13 at 8:43
It's like Schrodinger's cat. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
– Ufoguy
Jan 26 '14 at 7:24
It's like Schrodinger's cat. en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
– Ufoguy
Jan 26 '14 at 7:24
add a comment |
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
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.
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
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.
answered Apr 17 '15 at 12:07
Toughy
1011
1011
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f102652%2fhow-do-i-know-if-a-serial-port-is-actually-transmitting-data-without-opening-th%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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.
– rickhg12hs
Nov 26 '13 at 22:23