Re: Patch: rfcomm_sppd + openpty

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

On Mon, 28 Mar 2016, Timo Buhrmester wrote:

> I've been running the below patch for about a year, which makes
> rfcomm_sppd (bluetooth-related) optionally use openpty(3) when the
> argument to -t is "auto".
> 
> I'm neither sure this is the right way to do it, nor that support for
> manually specifying a tty is still needed at all.
> 
> Anyway I figured I toss it here for people to look at.  If it is
> considered okay, I'd also update the man page to reflect the change.
> 
> It might be somewhat hackish.
> 
> Any comments?

Well, I think FreeBSD switched to using openpty() altogether in the past 
some time but I didn't change ours because although I think that a dynamic 
system may be better I'm not sure if it was helpful -- the problem I saw 
with this is that rfcomm_sppd is used to set up an IO channel, and the 
script or whatever that is using it then doesn't know the name of the 
channel (it has to parse the output - and there are sometimes problems 
opening Bluetooth connections) but then I'm not sure if the current method 
where you set up a channel with the pre-configure name directly is useful 
either.  What is your use case for this?

The one way I did use this program intensively in the past was with pppd 
which runs the rfcomm_sppd program directly and uses stdio to communicate 
with the remote.

I possibly have another use case for the future, but I haven't set it up 
yet - on my boat I have a NMEA->RS232C output for the instrument data. 
Then, I have a RS232C->Bluetooth serial dongle which provides a RFCOMM 
channel. I was hoping to connect this to OpenCPN one day but I don't know 
what would be the best system for that. I can set up OpenCPN I think to 
communicate with a named tty but I don't think it can run a program or use 
Bluetooth directly.

personally in a style way, I don't like to overload functions or options 
in this way, perhaps better to use a separate function and -T flag ?

iain