How do I know if a serial port is actually transmitting data, without opening the device?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
10
down vote

favorite
2












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").










share|improve this question























  • 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














up vote
10
down vote

favorite
2












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").










share|improve this question























  • 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












up vote
10
down vote

favorite
2









up vote
10
down vote

favorite
2






2





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").










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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
















  • 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










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.






share|improve this answer






















  • 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

















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.






share|improve this answer




















    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    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

























    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.






    share|improve this answer






















    • 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














    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.






    share|improve this answer






















    • 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












    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.






    share|improve this answer














    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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
















    • 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












    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.






    share|improve this answer
























      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.






      share|improve this answer






















        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Apr 17 '15 at 12:07









        Toughy

        1011




        1011



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            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





















































            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






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?