_Robust_ bluetooth serial port console/tty












1















I've managed to create and connect to a console via bluetooth, as is described in many Q&A's FAQs Guides etc found via a google search.



Briefly, in sudo mode,



/usr/sbin/hciconfig hci0 piscan
/usr/bin/sdptool add --channel=3 SP
/usr/bin/rfcomm watch /dev/rfcomm0 3 /sbin/agetty rfcomm0 9600 vt100


That's all well and good if the bluetooth connection is stable.



My question is how to make this more robust for a headerless system (raspberry pi). If the bluetooth connection is lost, I find myself having to reboot the headerless system. There may be several (non-concurrent) users on the system, and it will be inevitable that one of the users will walk out with the bluetooth client device without logging off first, leaving the next user unable to log in!



Slight edit: a possible ugly workaroud would be to monitor for dropped connections and then kill/restart the appropriate processes. Not sure what the best way of doing this would be (not sure the correct processes to kill (after killing rfcomm, new connections can't be made)) nor the correct thing to monitor(tty and/or bluetooth disconnects?)!










share|improve this question
















bumped to the homepage by Community 5 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.




















    1















    I've managed to create and connect to a console via bluetooth, as is described in many Q&A's FAQs Guides etc found via a google search.



    Briefly, in sudo mode,



    /usr/sbin/hciconfig hci0 piscan
    /usr/bin/sdptool add --channel=3 SP
    /usr/bin/rfcomm watch /dev/rfcomm0 3 /sbin/agetty rfcomm0 9600 vt100


    That's all well and good if the bluetooth connection is stable.



    My question is how to make this more robust for a headerless system (raspberry pi). If the bluetooth connection is lost, I find myself having to reboot the headerless system. There may be several (non-concurrent) users on the system, and it will be inevitable that one of the users will walk out with the bluetooth client device without logging off first, leaving the next user unable to log in!



    Slight edit: a possible ugly workaroud would be to monitor for dropped connections and then kill/restart the appropriate processes. Not sure what the best way of doing this would be (not sure the correct processes to kill (after killing rfcomm, new connections can't be made)) nor the correct thing to monitor(tty and/or bluetooth disconnects?)!










    share|improve this question
















    bumped to the homepage by Community 5 mins ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.


















      1












      1








      1








      I've managed to create and connect to a console via bluetooth, as is described in many Q&A's FAQs Guides etc found via a google search.



      Briefly, in sudo mode,



      /usr/sbin/hciconfig hci0 piscan
      /usr/bin/sdptool add --channel=3 SP
      /usr/bin/rfcomm watch /dev/rfcomm0 3 /sbin/agetty rfcomm0 9600 vt100


      That's all well and good if the bluetooth connection is stable.



      My question is how to make this more robust for a headerless system (raspberry pi). If the bluetooth connection is lost, I find myself having to reboot the headerless system. There may be several (non-concurrent) users on the system, and it will be inevitable that one of the users will walk out with the bluetooth client device without logging off first, leaving the next user unable to log in!



      Slight edit: a possible ugly workaroud would be to monitor for dropped connections and then kill/restart the appropriate processes. Not sure what the best way of doing this would be (not sure the correct processes to kill (after killing rfcomm, new connections can't be made)) nor the correct thing to monitor(tty and/or bluetooth disconnects?)!










      share|improve this question
















      I've managed to create and connect to a console via bluetooth, as is described in many Q&A's FAQs Guides etc found via a google search.



      Briefly, in sudo mode,



      /usr/sbin/hciconfig hci0 piscan
      /usr/bin/sdptool add --channel=3 SP
      /usr/bin/rfcomm watch /dev/rfcomm0 3 /sbin/agetty rfcomm0 9600 vt100


      That's all well and good if the bluetooth connection is stable.



      My question is how to make this more robust for a headerless system (raspberry pi). If the bluetooth connection is lost, I find myself having to reboot the headerless system. There may be several (non-concurrent) users on the system, and it will be inevitable that one of the users will walk out with the bluetooth client device without logging off first, leaving the next user unable to log in!



      Slight edit: a possible ugly workaroud would be to monitor for dropped connections and then kill/restart the appropriate processes. Not sure what the best way of doing this would be (not sure the correct processes to kill (after killing rfcomm, new connections can't be made)) nor the correct thing to monitor(tty and/or bluetooth disconnects?)!







      raspberry-pi tty bluetooth reboot serial-console






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 10 '15 at 11:37







      bmcws

















      asked Apr 2 '15 at 17:39









      bmcwsbmcws

      64




      64





      bumped to the homepage by Community 5 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 5 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
























          1 Answer
          1






          active

          oldest

          votes


















          0














          OK, I've come up with a solution myself - it might not be optimal though, so and comments and advice appreciated.



          Following on from my 'slight edit', I wrote a script to monitor the rfcomm connection and if the bluetooth is disconnected but the tty is still attached, then kill the processes on the device:



          check_rfcomm



          rfcomm show /dev/rfcomm0 2>/dev/null | grep "channel 3 closed" | grep "tty-attached"
          if [ $? -eq 0 ]; then
          kill -9 `lsof -t /dev/rfcomm0`
          fi


          I then added the script to crontab:



          * * * * * /usr/local/bin/check_rfcomm >>/var/log/check_rfcomm.log 2>&1


          Seems to work, but with minimal testing. Not sure how robust it is!






          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',
            autoActivateHeartbeat: false,
            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%2f194067%2frobust-bluetooth-serial-port-console-tty%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            OK, I've come up with a solution myself - it might not be optimal though, so and comments and advice appreciated.



            Following on from my 'slight edit', I wrote a script to monitor the rfcomm connection and if the bluetooth is disconnected but the tty is still attached, then kill the processes on the device:



            check_rfcomm



            rfcomm show /dev/rfcomm0 2>/dev/null | grep "channel 3 closed" | grep "tty-attached"
            if [ $? -eq 0 ]; then
            kill -9 `lsof -t /dev/rfcomm0`
            fi


            I then added the script to crontab:



            * * * * * /usr/local/bin/check_rfcomm >>/var/log/check_rfcomm.log 2>&1


            Seems to work, but with minimal testing. Not sure how robust it is!






            share|improve this answer




























              0














              OK, I've come up with a solution myself - it might not be optimal though, so and comments and advice appreciated.



              Following on from my 'slight edit', I wrote a script to monitor the rfcomm connection and if the bluetooth is disconnected but the tty is still attached, then kill the processes on the device:



              check_rfcomm



              rfcomm show /dev/rfcomm0 2>/dev/null | grep "channel 3 closed" | grep "tty-attached"
              if [ $? -eq 0 ]; then
              kill -9 `lsof -t /dev/rfcomm0`
              fi


              I then added the script to crontab:



              * * * * * /usr/local/bin/check_rfcomm >>/var/log/check_rfcomm.log 2>&1


              Seems to work, but with minimal testing. Not sure how robust it is!






              share|improve this answer


























                0












                0








                0







                OK, I've come up with a solution myself - it might not be optimal though, so and comments and advice appreciated.



                Following on from my 'slight edit', I wrote a script to monitor the rfcomm connection and if the bluetooth is disconnected but the tty is still attached, then kill the processes on the device:



                check_rfcomm



                rfcomm show /dev/rfcomm0 2>/dev/null | grep "channel 3 closed" | grep "tty-attached"
                if [ $? -eq 0 ]; then
                kill -9 `lsof -t /dev/rfcomm0`
                fi


                I then added the script to crontab:



                * * * * * /usr/local/bin/check_rfcomm >>/var/log/check_rfcomm.log 2>&1


                Seems to work, but with minimal testing. Not sure how robust it is!






                share|improve this answer













                OK, I've come up with a solution myself - it might not be optimal though, so and comments and advice appreciated.



                Following on from my 'slight edit', I wrote a script to monitor the rfcomm connection and if the bluetooth is disconnected but the tty is still attached, then kill the processes on the device:



                check_rfcomm



                rfcomm show /dev/rfcomm0 2>/dev/null | grep "channel 3 closed" | grep "tty-attached"
                if [ $? -eq 0 ]; then
                kill -9 `lsof -t /dev/rfcomm0`
                fi


                I then added the script to crontab:



                * * * * * /usr/local/bin/check_rfcomm >>/var/log/check_rfcomm.log 2>&1


                Seems to work, but with minimal testing. Not sure how robust it is!







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Apr 15 '15 at 13:33









                bmcwsbmcws

                64




                64






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f194067%2frobust-bluetooth-serial-port-console-tty%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

                    CARDNET

                    Boot-repair Failure: Unable to locate package grub-common:i386

                    濃尾地震