Re: Patch: rfcomm_sppd + openpty

[Iain Hibbert <plunky%ogmig.net@localhost>]

On Mon, 28 Mar 2016, Timo Buhrmester wrote:

> > What is your use case for this?
> (It has been a year since I wrote the patch so my memory is a bit foggy.)
> I'm using rfcomm_sppd to establish a bluetooth connection to a GPS
> receiver, which is then used by gpsd.
> 
> Now, the problem was that I couldn't a-priori find an unused /dev/ttyp?
> device to be used for that connection, there was something weird with
> the 16 of those devices being equivalent to or preferred over /dev/pts/*,
> so the first sixteen, say, xterms I opened would used /dev/ttyp* and only
> then start using /dev/pts/N with N >16.  Or so I think to remember, anyway.
> 
> Or put differently, with more than sixteen such devices in use, using
> rfcomm_sppd without openpty(3) became impossible at all.

Hm, I don't ever remember having any trouble just using a fixed low 
numbered pty for this, even with X running .. but perhaps there was a 
difference in those days. I know that the named pty device nodes are not 
even made any more by default, so we should certainly move on in some way 
if it is discouraged to use the named ptys.

> There's also the chance that I just misunderstood how rfcomm_sppd is
> supposed to be used.  My script essentially does:
> >	gpsd -bnN $(rfcomm_sppd -a 00:0d:b5:82:e9:30 -d ubt0 -t auto)
> Anything odd about that (apart from lack of error checking)?

No that looks fine.. the error checking is difficult in any case, its just 
annoying when it fails to connect and you have to stop and restart gpsd.

In my imagination for this, the use would have been to start an instance 
of rfcomm_sppd (at system boot), such that (eg) /dev/ttyp3 would be the 
tty configured to have the connection to your GPS as if you had reserved 
that serial port for it. However, the daemon would not try to connect 
unless the slave was opened (DTR raised?). This would mean, that for 
example when gpsd would start (on /dev/ttyp3 which you know was 
'hardwired' to the GPS) then rfcomm_sppd would notice and try to remote 
connect. When DTR was dropped (or the tty was closed) then it would drop 
the remote connection but not exit. If the Bluetooth connection was lost 
when the tty was still open then it could try to reconnect.

However, the pty driver is not capable of passing this open/close 
information as far as I know, though perhaps it is only a matter of 
extending the TIOCPKT mode to make it happen.

iain