rfcomm_sppd

[Iain Hibbert]

On Wed, 24 Jan 2007, Yevmenkin, Maksim wrote:

> Into /etc/ppp/ppp.conf file, it never quite worked when executed from
> console/terminal. I have a patch sitting in my tree that fixes it and
> makes rfcomm_sppd behave like cu.

Yeah, I have something like this also ("stty -icanon -echo -icrnl" might
do it?). I'm not quite sure if its proper, but I think a program like pppd
that expects a certain state would probably set raw mode in any case..

> > I get a "Device Busy" error.  I tracked this down to the fact that cu
> > sets TIOCEXCL but never unsets it.
>
> I'm not sure why you getting this error. I just tried it on my machine
> and it works just fine. Perhaps there are some minor differences between
> FreeBSD and netbsd, or, more likely, I'm doing something wrong :)

It could be the fault of our cu - last year NetBSD switched from Taylor
UUCP cu to the BSD one that is included with tip, probably some
differences..

> Rfcomm_sppd will open and hold slave tty open until Bluetooth connection
> is terminated. The idea was to create an illusion of "real" serial port,
> just like /dev/ttydX. One can re-connect to rfcomm serial device as many
> times as needed as along as Bluetooth connection is up (in a sense
> serial device is present in the system).

Yeah I read that in the manpage, but closing the slave device doesn't make
anything happen on the master on NetBSD, maybe thats a difference..

> Bluetooth serial port server which I never got around to do because I'm
> still not sure about the semantics. Who should "own" serial port offered
> to the remote devices: specific user or system?

Well, there are lots of ownership issues with bluetooth that are yet
unaddressed - I think that deep down, baseband connections should be owned
by the user who creates them, but I'm not thinking about that because its
going to be difficult.

regards,
iain