commit db7e150c57ed24474b8d241b143638c17ac6f38d
parent 6346d6d543ca1bdb9568f0572504c41faa34dfa4
Author: Christoph Lohmann <20h@r-36.net>
Date: Fri, 25 Mar 2022 18:56:53 +0100
Add README.md.
Diffstat:
| README.md | | | 53 | +++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 53 insertions(+), 0 deletions(-)
diff --git a/README.md b/README.md
@@ -0,0 +1,53 @@
+# RFCOMMd, a rfcomm daemon.
+
+## RFCOMM
+
+RFCOMM is a sub standard of bluetooth, allowing serial communication via
+some bluetooth channel.
+
+## What is this?
+
+The rfcomm daemon will offer some rfcomm service for any device and based
+on the id of the device, users can run different scripts, daemons or
+filters for serial link output.
+
+## Installation
+
+ $ make
+ $ make PREFIX=/usr install
+ # Copy over init scripts from etc/* for your needs.
+ # Copy over sample filters from filters/* for your needs.
+
+## Filters
+
+A filter is a simple script, where the first argument is the rfcomm
+device, like /dev/rfcomm0. The script can then do whatever it likes on
+this pseudo tty. See the example filters for how to properly configure
+the device to your needs using stty.
+
+Using this logic, you can use whatever daemon allowing serial
+communication as a filter script.
+
+## Types of Connection
+
+Depending on how crappy someone implemented bluetooth, I observed
+following device behaviours:
+
+1.) The device will connect, output content and then disconnect.
+
+2.) The device connects and stays connected.
+
+Since rfcommd does no child process management, which would be too much
+for it, you need to consider this for anything restarting rfcommd. Maybe
+in the future a better logic can be implemented.
+
+## Bugs / Patches
+
+Send bugs / patches to:
+
+ Christoph Lohmann <20h@r-36.net>
+
+## Have fun!
+
+Have fun using this!
+
