You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,13 +14,14 @@ This project is made up of a set of scripts, services and libraries "used loosel
14
14
These scripts and services basicaly utilize *screen* and *rfcomm* to "bridge" a connection between the *master*, and the *slave* you are attempting to connect to.
15
15
- By design, this prject does not have security in mind, preferring instead to focus on easy discovery, pairing, and connectivity to allow the network administrator to focus on getting their work done.
16
16
- The Bridge will always be discoverable, and will not require a pin to complete the pairing process.
17
-
- This has been tested with *master* devices using the following Operating Systems: Linux, Android, Windows 10, and ChromeOS (with caveats).
18
-
- When connecting to the bridge over bluetooth, the administrator will be auto logged-in as pi.
19
-
- This will in no way affect access to the _slave_ device. If the _slave_ requires a username/password to access it, you will still be required to use those credentials.
17
+
-*ser2bt-bridge* has been tested with *master* devices using the following Operating Systems: Linux, Android, Windows 10, and ChromeOS (with caveats).
18
+
- Although I do not own a mac, I have no reason to belive it won't work with *ser2bt-bridge*.
19
+
- When connecting to the bridge over bluetooth, the administrator will be auto logged-in as user pi.
20
+
- This will in no way affect access to the _slave_ device. If the _slave_ requires a username/password to administer it, then you will still be required to use those credentials.
20
21
- Connection between the *master* and the *bridge* will be 9600 Baud - this is to maximize range.
21
22
- Once the *master* is connected to the *bridge*, it will attempt to look for any available serial (usb or acm) ports. At this point one of three things are expected to occur:
22
23
- If the *bridge* was connected to a single *slave*, then it will open a *screen* session to that serial port outomagically.
23
-
- If the *bridge* was connected (via OTG usb hub), then it will create one *screen* session for each serial port it found, list them on your display, and exit to shell.
24
+
- If the *bridge* was connected (via OTG usb hub) to multiple switches, then it will create one *screen* session for each active serial port found, list them on your display, and exit to shell.
24
25
- If the *bridge* does not detect any new usb/acm ports, then the it will state that fact and then drop to the *bridges* bash shell.
25
26
- The connection between the *bidge* and the *slave* is set to 9600 Baud. I'm looking to set this as a configurable element in the future.
26
27
- While connected to a *slave*, the *bridge* will begin logging all session traffic between the *master* and *slave*. (This is why it is important to make sure the *bridge* somehow either has its time set manually, or receives its time from an external source, such as ntp server and/or an onboard rtc.)
0 commit comments