[9fans] Perhaps someone can give me an advice ...

[9fans] Perhaps someone can give me an advice ...

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

1. My problem :

I need a way to exchange images, videos and audio with smartphones, tabletts and usual computers which reside on the same wlan-router.

2. My solutions :

All my solutions have in common that I used qr to generate a qr code which consists of the ip-adress and port on which to connect to plan9 running in qemu, 9vx or natively.

2.1. httpd

I designed a web page which uses <input type="file" ...> and XMLHttpRequest inside a script. This makes it possible to select files and transfer them to plan9. The solution works in chrome and firefox while safari sometimes causes problems due to the hard coded ip address.

2.2. ftpd

I started a ftp server on plan9 which can be used by ftp clients from mobile devices which have a client app installed and this also works. 

3. My question :

Do you have any other suggestions how to solve this problem without making it necessary to write apps for the mobile device by only relying on standard protocols. Does anybody have any ideas or experience ? Would websockets be a better solution ?

Thanks in advance.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-M4cd5fc72ff668b0a39316036
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2145 bytes --]

Re: [9fans] Perhaps someone can give me an advice ...

[Skip Tavakkolian]

For android, you could try to resurrect previous work by Tim Newsham
based on Charles Forsyth's styx Java implementation:
https://github.com/9nut/styxbrowser/tree/5ed22a9238d7333ff38bc2646aeee2b2f3501136

On Wed, Mar 16, 2022 at 9:37 PM ibrahim via 9fans <9fans@9fans.net> wrote:
>
> 1. My problem :
>
> I need a way to exchange images, videos and audio with smartphones, tabletts and usual computers which reside on the same wlan-router.
>
> 2. My solutions :
>
> All my solutions have in common that I used qr to generate a qr code which consists of the ip-adress and port on which to connect to plan9 running in qemu, 9vx or natively.
>
> 2.1. httpd
>
> I designed a web page which uses <input type="file" ...> and XMLHttpRequest inside a script. This makes it possible to select files and transfer them to plan9. The solution works in chrome and firefox while safari sometimes causes problems due to the hard coded ip address.
>
> 2.2. ftpd
>
> I started a ftp server on plan9 which can be used by ftp clients from mobile devices which have a client app installed and this also works.
>
> 3. My question :
>
> Do you have any other suggestions how to solve this problem without making it necessary to write apps for the mobile device by only relying on standard protocols. Does anybody have any ideas or experience ? Would websockets be a better solution ?
>
> Thanks in advance.
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-Med820fa4842418a9262836ec
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Perhaps someone can give me an advice ...

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Thursday, 17 March 2022, at 7:53 PM, Skip Tavakkolian wrote:
> For android, you could try to resurrect previous work by Tim Newsham
based on Charles Forsyth's styx Java implementation:

Thanks for the tip but I'm looking for a solution where I don't have to provide code for android or ios. I want to use built in protocols from these devices perhaps by implementing the counterpart on plan9. ftp and http are working already but if someone knows other working protocols I would try them ...

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-M31bc71e711e44624e58006cc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1318 bytes --]

Re: [9fans] Perhaps someone can give me an advice ...

[Skip Tavakkolian]

My memory seems to be faulty. David du Colombier is the original
author of styxbrowser.
I thought Tim did the work, but the check-ins show djc and here's
David's comment on 9fans regarding this code:

https://groups.google.com/g/comp.os.plan9/c/XPIrNsPoRa0/m/F5IcwjgYOPkJ

Sorry about any confusion.

On Thu, Mar 17, 2022 at 11:53 AM Skip Tavakkolian
<skip.tavakkolian@gmail.com> wrote:
>
> For android, you could try to resurrect previous work by Tim Newsham
> based on Charles Forsyth's styx Java implementation:
> https://github.com/9nut/styxbrowser/tree/5ed22a9238d7333ff38bc2646aeee2b2f3501136
>
> On Wed, Mar 16, 2022 at 9:37 PM ibrahim via 9fans <9fans@9fans.net> wrote:
> >
> > 1. My problem :
> >
> > I need a way to exchange images, videos and audio with smartphones, tabletts and usual computers which reside on the same wlan-router.
> >
> > 2. My solutions :
> >
> > All my solutions have in common that I used qr to generate a qr code which consists of the ip-adress and port on which to connect to plan9 running in qemu, 9vx or natively.
> >
> > 2.1. httpd
> >
> > I designed a web page which uses <input type="file" ...> and XMLHttpRequest inside a script. This makes it possible to select files and transfer them to plan9. The solution works in chrome and firefox while safari sometimes causes problems due to the hard coded ip address.
> >
> > 2.2. ftpd
> >
> > I started a ftp server on plan9 which can be used by ftp clients from mobile devices which have a client app installed and this also works.
> >
> > 3. My question :
> >
> > Do you have any other suggestions how to solve this problem without making it necessary to write apps for the mobile device by only relying on standard protocols. Does anybody have any ideas or experience ? Would websockets be a better solution ?
> >
> > Thanks in advance.
> >
> > 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-M0773a4457ce38416562dbcc1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Perhaps someone can give me an advice ...

[sirjofri]

Hey,

If someone does some work on native 9p stuff for android I'd really love 
some apk. I'm not an android dev, only did very few things on android 
programming-wise.

Thanks for starting this thread.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-Me110548929bb1d7c33ce02ae
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Perhaps someone can give me an advice ...

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

On Friday, 18 March 2022, at 9:07 PM, sirjofri wrote:
> If someone does some work on native 9p stuff for android I'd really love 
some apk. I'm not an android dev, only did very few things on android 
programming-wise.

After testing smb, ftpd and httpd approaches for my current problem I decided to use the ftpd and httpd solutions. The httpd solution combined with a uplaod html page which contains javascript using the file and xmlhttprequest api works on both android and ios without any needs for supplementary apps as long as scripting isn't restricted. The ftpd and smb approach also works but makes additional apps on the user phone necessary while most of those apps are freely available (also perhaps potentially dangerous for the users). 

While for my project there are no benefits doing this its possible to write a 9p fileserver in javascript only relying on the file and xmlhttprequest using html and the js file. It would temporarily make a 9p filesystem available on the plan9 side but I'm sure the connection will be closed unexpectedly by the browsers on the phone side so this will cause more problems than bring benefits. For my project using ftpd and httpd suffice cause my users can now transfer data directly to plan9 with tools available for android and ios. 

Instead of opening a new thread : I'm interested in low budget thin client solutions with plan9 as an intranet server which than connects to a web server for data exchange. 

Currently I have tested my approch on :

Fujitsu S900, Lenovo M32, Igel M340. I didn't get my hands on a HP 610 or Fujitsu S920 perhaps someone already tried this and can share his experience. 

Also I prepare a list of low budget USB WLan Sticks which are supported by 9legacy and 9front enhancements. Currently I mastered support for sticks with Realtek RT 8188. I ordered about 20 different models with different chipsets for testing and adjusting the drivers. If somebody knows about other chipsets working with 9legacy or 9front just telling what works would be nice.

While on wait I'm intending to port the freebsd bluetooth stack (netgraph) to plan9. I would be surprised if no one started such a project till now so if someone shares this goal I would be interested in a cooperative work. 

Thanks for replies ...

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-Mab42e1f39d27c1ac16d3a01d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3349 bytes --]

Re: [9fans] Perhaps someone can give me an advice ...

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

ibrahim via 9fans writes:

> While on wait I'm intending to port the freebsd bluetooth stack (netgraph) =
> to plan9. I would be surprised if no one started such a project till now so=
>  if someone shares this goal I would be interested in a cooperative work.=20

Huh. I'd never thought about looking at that ng code as the basis for a
port.  I wouldn't have thought it's even close to being a natural port,
but my netgraph experience is rather limited ...

Bluetooth (and BLE) support woould be *very* nice to have.  It would be
really slick to get my Moolitpass MiniBLE working with factotum.  This
has been on my todo list for a while now, using USB to connect.  I need
to do USB anyway to support the older versions of the authenticator
hardware.

--lyndon

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-M632ad53f8b0181d6cbd89e8e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] bluetooth

[Richard Miller]

lyndon@orthanc.ca:
> Bluetooth (and BLE) support woould be *very* nice to have.

I have a native bluetooth host implementation for Plan 9, not ported
from anything (it's written from scratch based on published bt specs.)
I don't regard it as sufficiently debugged for a release ... it's
missing some important error handling (mandatory retries to recover from
poor reception) and it just plain doesn't work for some of the dongles
I've tried. I don't know whether it's compatible with BLE (which didn't
exist at the time I wrote it). Contact me off list if you'd like a copy.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T69704162cbe0c04a-Mf8839883c089cb58afb527cf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: bluetooth

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

I'm interested if the results will be MIT or BSD2 licensed cause I want to share the results with 9front, 9legacy. I contacted you off list. 
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T69704162cbe0c04a-Mbd443e03e4d49abe5fb798b7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 867 bytes --]

Re: [9fans] Perhaps someone can give me an advice ...

[sirjofri]

Hey,

I personally use cifsd (on 9front) and on android totalcommander+smb 
extension. It works perfectly fine without any issues across all my 
android devices. I share some of the files with other users via tcp80 
(behind tlssrv as https).

On windows I use drawterm for file transfer, but that's no comparison.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-Mfff0014eef85589f7b3671b2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Perhaps someone can give me an advice ...

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Friday, 18 March 2022, at 12:19 AM, sirjofri wrote:
> I personally use cifsd (on 9front) and on android totalcommander+smb 
extension. It works perfectly fine without any issues across all my 
android devices. I share some of the files with other users via tcp80 
(behind tlssrv as https).

I'm using totalcommander with ftp extension and didn't try smb. Thanks for the hint I'll give it a try.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-Md2fdb49288dd54d9d4a7e16e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1223 bytes --]

[9fans] bluetooth

[Skip Tavakkolian]

anyone looked at this or given it any thought?

Re: [9fans] bluetooth

[Patrick Kelly]

On Sep 22, 2009, at 3:34 PM, Skip Tavakkolian wrote:

> anyone looked at this or given it any thought?

I was going to check into it after I did some tests in the audio
system. Although I probably won't finish my tests till early-mid
october.
>
>

Re: [9fans] bluetooth

[dave.l]

A very superficial glance a long time ago suggested that it was a
twisty little maze of de-facto and de-vulgus standards.
i.e. the death of a thousand committees.

Then there's the hardware ...

On 22 Sep 2009, at 20:34, Skip Tavakkolian wrote:

> anyone looked at this or given it any thought?
>
>

Re: [9fans] bluetooth

[Richard Miller]

> A very superficial glance a long time ago suggested that it was a
> twisty little maze of de-facto and de-vulgus standards.
> i.e. the death of a thousand committees.

The core standard (defining the communication layers) is actually
not too bad, compared to some I've had to look at.  It's huge, but
a lot of it is describing low-level radio stuff (below the hci layer)
which your bluetooth chip takes care of.

All the "profiles" (application layers) have their own separate
standards documents, and there indeed is a morass of (non)design
by committee.

> Then there's the hardware ...

Maybe I was lucky, but my random choice of development hardware
(a cheap generic usb dongle with a CSR chip) has seemed to behave
just as the spec says.  Of course there have been surprises, but
so far these have been where the spec was ambiguous and my guess
didn't match the firmware designer's guess.

Re: [9fans] bluetooth

[dave.l]

Thanks a million for all your work on this:
it means I'll probably be running plan9 seriously soon:-).

To be selfish for a moment ...
Presumably there's still a medium sized asteroid of pain to go through
to get something like,
say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...)
working sensibly?

Oh, and we'll need more drivers which will need to be more complex and
more efficient and less buggy
while driving more, and more divergent hardware which is becoming ever
more complex and bigger and buggier,
of course.

OTOH, of course, we do at least have the wonderfully clean plan9 view
of all this contortionous mess,
so at least when I need to push an avrcp driver onto my stack,
I can manipulate and see the hideous vipers nest in userland and prod
it with rc.

Plus, of course, it'll be totally dandy for connecting my plan9
wristputer to my plan9 briefcase.

Well done again.

D

On 23 Sep 2009, at 15:48, Richard Miller wrote:

>> A very superficial glance a long time ago suggested that it was a
>> twisty little maze of de-facto and de-vulgus standards.
>> i.e. the death of a thousand committees.
>
> The core standard (defining the communication layers) is actually
> not too bad, compared to some I've had to look at.  It's huge, but
> a lot of it is describing low-level radio stuff (below the hci layer)
> which your bluetooth chip takes care of.
>
> All the "profiles" (application layers) have their own separate
> standards documents, and there indeed is a morass of (non)design
> by committee.
>
>> Then there's the hardware ...
>
> Maybe I was lucky, but my random choice of development hardware
> (a cheap generic usb dongle with a CSR chip) has seemed to behave
> just as the spec says.  Of course there have been surprises, but
> so far these have been where the spec was ambiguous and my guess
> didn't match the firmware designer's guess.
>
>

Re: [9fans] bluetooth

[Richard Miller]

> Presumably there's still a medium sized asteroid of pain to go through
> to get something like,
> say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...)
> working sensibly?

A2DP will need synchronous connections which aren't implemented
yet (sorry).

AVRCP itself looks straightforward, but it's mostly just a wrapper
for the AV/C command set.  The spec for AV/C looks well enough
defined, so go ahead!

> Oh, and we'll need more drivers which will need to be more complex and
> more efficient and less buggy

s/more complex/simpler/ -- we are talking about Plan 9, remember?

Re: [9fans] bluetooth

[Richard Miller]

> anyone looked at this or given it any thought?

I've been working on a bluetooth implementation which should be
ready for initial release soon.  Just the core communication layers
(usb-hci transport, hci, l2cap, rfcomm), and fairly rudimentary:
I've tried to pick a minimal useful subset rather than support
the whole 1420-page Core V2.1+EDR standard.

The interface follows the normal Plan 9 /net model, so the usual
dial/announce/listen operations work pretty much as expected,
and you can do things like:

  aux/listen1 bt!*!77 /bin/exportfs
  import -A bt!00123456789A!77 / /n/blue

A bit of tweaking to cs(8) would allow the use of "friendly"
device names in place of 12-hexdigit bluetooth device addresses.

Re: [9fans] bluetooth

[Skip Tavakkolian]

>   aux/listen1 bt!*!77 /bin/exportfs
>   import -A bt!00123456789A!77 / /n/blue

beautiful!

Re: [9fans] bluetooth

[Skip Tavakkolian]

>   import -A bt!00123456789A!77 / /n/blue

what does the device id discovery look like?

Re: [9fans] bluetooth

[Francisco J Ballesteros]

If it's useful, I'd love to beta test or alpha test or whatever.

thanks a lot for your effort!

Re: [9fans] bluetooth

[Richard Miller]

> what does the device id discovery look like?

At present:

	echo inquiry M N >/net/bt/ctl
(spend up to M seconds looking for up to N devices)
	cat /n/bt/devices
(see what devices have been found)

Re: [9fans] bluetooth

[Skip Tavakkolian]

> 	echo inquiry M N >/net/bt/ctl
> (spend up to M seconds looking for up to N devices)
> 	cat /n/bt/devices
> (see what devices have been found)

the application i have in mind inventories all device id's it sees
with a time stamp.  i need to measure the flow between two endpoints
based on the id/timestamp.  i was thinking of something like this:

while (sleep 1) {
	echo `{ls /net/bt/ids}^'@'^`{date -n}
}

i've not considered the pros/cons of each approach.

thank you for doing this. like nemo, i'd like to offer testing.

Re: [9fans] bluetooth

[lucio]

> thank you for doing this. like nemo, i'd like to offer testing.

To echo nemo and skip, I do own one USB bluetooth radio and many
mobile handsets.  Count me in, if you wish.

++L

Re: [9fans] bluetooth

[Richard Miller]

>> 	cat /n/bt/devices
>> (see what devices have been found)

Typo - should be /net/bt/devices - currently gives you device address,
class, and friendly name for all "known" devices (see below).  First
on list is self.

term% cat /net/bt/devices
00025b0011bf 020104 'atom'
00236c9dd69f 38010c 'Richard Miller’s MacBook'

> the application i have in mind inventories all device id's it sees
> with a time stamp.

What do you mean exactly by "sees"?  A device may be known
because it responded to an inquiry (probe for all devices) or a
page (probe for specific device), or because it sent you an inquiry
or a page, or because you paired with the device at some time in
the past and have a stored link key for it.  [A device may be set
to respond to page but not inquiry.  Or vice versa.]

> while (sleep 1) {
> 	echo `{ls /net/bt/ids}^'@'^`{date -n}
> }

The hardware can automatically do periodic inquiry scans in the
background.  I could add a command 'inquiry auto N' to enable this
(but I guess you would still need a 'sleep' loop to look at the
devices file).

Advice sought:
1. Would it be helpful to have a timestamp in the devices record to
give the time the device was last seen (for some value of "seen")?
2. When should a device disappear from the /net/bt/devices list?

Re: [9fans] bluetooth

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 2227 bytes --]

On Thu, Sep 24, 2009 at 09:22:17AM +0100, Richard Miller wrote:
> What do you mean exactly by "sees"?  A device may be known
> because it responded to an inquiry (probe for all devices) or a
> page (probe for specific device), or because it sent you an inquiry
> or a page, or because you paired with the device at some time in
> the past and have a stored link key for it.  [A device may be set

Shouldn't factotum be in charge of storing keys?  Or do you mean just
keys that happen to be resident in the stack right now?

> to respond to page but not inquiry.  Or vice versa.]
> 
> > while (sleep 1) {
> > 	echo `{ls /net/bt/ids}^'@'^`{date -n}
> > }
> 
> The hardware can automatically do periodic inquiry scans in the
> background.  I could add a command 'inquiry auto N' to enable this
> (but I guess you would still need a 'sleep' loop to look at the
> devices file).
> 
> Advice sought:
> 1. Would it be helpful to have a timestamp in the devices record to
> give the time the device was last seen (for some value of "seen")?
> 2. When should a device disappear from the /net/bt/devices list?

How about exposing things as an ndb db so that we can add fields as the
need arises?
  mac=00112233445566 name="Friendly Name" !secret=0x... lastseen=timestamp
  active=rfcomm3, sdp=pan,rfcomm,...,...
(that might be a bad example, if sdp is done by a separate daemon, e.g.;
am just musing).

What about letting me set a stored key by writing a line into this as a
single write of "mac=... !secret=0x..." ala factotum's ctl file?

Oh hey... why not make the file also act like the sound mixers and jccfs
journals?  That is, just stream events out to readers, starting with a full
enumeration and then updates, then the "you are about to block" empty read,
then block until the next scan or timeout which changes something.

You can give an advisory signal (mac=... gone= or somesuch) that a device
should be considered gone (and purge it from the list you'd report to a
fresh client) after some small time interval... something between 5 and 30
seconds seems reasonable to me?  People watching the event stream are free
to do their own thing.

Does that seem reasonable?
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] bluetooth

[Richard Miller]

>> ... or because you paired with the device at some time in
>> the past and have a stored link key for it.
>
> Shouldn't factotum be in charge of storing keys?  Or do you mean just
> keys that happen to be resident in the stack right now?

No, I mean keys which are kept in non-volatile store inside the
bluetooth chip.  The BT firmware kindly does this for you.

This means when you buy a secondhand phone, put a new SIM card
in it, and wipe its memory, it may still be paired with random
devices from its previous life.

> How about exposing things as an ndb db so that we can add fields as the
> need arises?
>   mac=00112233445566 name="Friendly Name" !secret=0x... lastseen=timestamp
>   active=rfcomm3, sdp=pan,rfcomm,...,...
> (that might be a bad example, if sdp is done by a separate daemon, e.g.;
> am just musing).

I think this is mixing too many unrelated things together.  Sdp is another
layer (like dns), and if you want to see active connections you can
use netstat.  /net/bt/devices is simply for relating names to addresses,
like /net/arp.

> What about letting me set a stored key by writing a line into this as a
> single write of "mac=... !secret=0x..." ala factotum's ctl file?

Where would you get the key from?  Link keys are generated internally
during the pairing transaction between devices.  The PIN used for pairing
is supplied by the user with a command to /net/bt/ctl, but this will be
different each time so there's no point giving it to factotum.

> You can give an advisory signal (mac=... gone= or somesuch) that a device
> should be considered gone (and purge it from the list you'd report to a
> fresh client) after some small time interval... something between 5 and 30
> seconds seems reasonable to me?  People watching the event stream are free
> to do their own thing.

I can't see a compelling application for this but maybe I'm unimaginative.
If you are connected to a device and it disappears you'll get a hangup.

Re: [9fans] bluetooth

[Steve Simon]

Fantastic work Richard, I too will be very interested in playing
with this once you are ready.

The only one thought - probably not mentioned as it is so obvious,
it would be neat if the plumber and thus auth/fgui could be pressed
into service for entering the pairing PIN.

-Steve

Re: [9fans] bluetooth

[Richard Miller]

> it would be neat if the plumber and thus auth/fgui could be pressed
> into service for entering the pairing PIN.

I don't quite see the connection between plumber and fgui - doesn't
fgui just read directly from /mnt/factotum/needkey?

At present there's a needkey-like mechanism for PINs - the equivalent
of fgui is this simple rc loop:

	while (bd=`{read </net/bt/pinreq}) {
		echo -n enter PIN for device `{grep $bd /net/bt/devices} ' : '
		pin=`{read}
		~ $pin '' || echo pin $bd $pin >/net/bt/ctl
	}

But now you mention it, using the plumber seems a good idea, so we
could pop up a new window to ask for a PIN when needed.

Re: [9fans] bluetooth

[rsc]

> 00236c9dd69f 38010c 'Richard Miller’s MacBook'

I was going to comment that you should use %q instead of '%s'
but now I notice that the apostrophe is 0x2019 not a simple '.
Does Bluetooth specify UTF-8 as the string encoding sent over
the network?

Russ

Re: [9fans] bluetooth

[Richard Miller]

> I was going to comment that you should use %q instead of '%s'

I do, of course.  The funny apostrophe was MacOS's idea.

> Does Bluetooth specify UTF-8 as the string encoding sent over
> the network?

No, just that the device name is encoded as UTF-8 (up to 248 octets).

Re: [9fans] bluetooth

[Skip Tavakkolian]

> What do you mean exactly by "sees"?  A device may be known
> because it responded to an inquiry (probe for all devices)

all devices that are listening on inquiry scan channels and respond to
inquiry requests.  (i'm just learning the details and my terminology
may be a bit off).

Re: [9fans] bluetooth

[Richard Miller]

>> What do you mean exactly by "sees"? ...
>
> all devices that are listening on inquiry scan channels and respond to
> inquiry requests.

It looks like your requirement might be satisfied by one or
the other of these things in the /net/bt/devices record:

- a discoverable (ie "responded to most recent inquiry") flag
- a timestamp for last inquiry response received (1 second resolution?)

I'm reluctant to remove devices altogether when they don't
respond to inquiry, because it may still be possible to
connect to a non-discoverable device by paging its address.

Re: [9fans] bluetooth

[matt]

you could just set the mtime to the time of the last successful
operation on that device

>>>What do you mean exactly by "sees"? ...
>>>
>>>
>>all devices that are listening on inquiry scan channels and respond to
>>inquiry requests.
>>
>>
>
>It looks like your requirement might be satisfied by one or
>the other of these things in the /net/bt/devices record:
>
>- a discoverable (ie "responded to most recent inquiry") flag
>- a timestamp for last inquiry response received (1 second resolution?)
>
>I'm reluctant to remove devices altogether when they don't
>respond to inquiry, because it may still be possible to
>connect to a non-discoverable device by paging its address.
>
>
>
>

Re: [9fans] bluetooth

[Skip Tavakkolian]

Now that I have a little experience, I've formed an opinion

> Advice sought:
> 1. Would it be helpful to have a timestamp in the devices record to
> give the time the device was last seen (for some value of "seen")?

Yes; this would be a good feature.

> 2. When should a device disappear from the /net/bt/devices list?

it would be good if this was settable. i think the value depends on the
application and user behavior. at a starbucks they might hang around,
but along a walkway it might be the length of time a person walks 30'.