(probably this is a tech-userlevel issue, please continue
there)
Is there something to do the reverse, so that NetBSD can
offer an SPP service to another bluetooth client? The
sync interface of my phone works this way: you tickle one
of its SPP's and it disconnects and tries to make an SPP
connection back to you, expecting to find PPP running
there
What sync software would you like to use? I confess I don't
know much about that, is it possible that the phone doesn't
really expect to find a PPP interface to do the sync?
It is not difficult to write something that will listen on a
RFCMM channel (and register with SDP server), maybe
rfcomm_sppd should be able to handle something like that
there is a program in FreeBSD called rfcomm_pppd that does
handle this kind of thing for certain phones, but I didn't
port it because it seemed more useful for their user-ppp
daemon.
iain

Thu, 18 Jan 2007, Daniel Carosone wrote:

I haven't been able to get the other direction working, fwiw. While
RFCMM to other devices like the gps works, trying to use the phone's
SPP like a modem doesn't - I get a connection, but just echoes of
whatever I type and no other response to AT commands, etc. I need to
resort to irda for that.

There is some weird thing with rfcomm_sppd and pty and cu that I don't
understand ie it works for pppd but if I try to 'cu -l' the device I
get like the above. If you capture the session with hcidump you can see
that text is sent, but I've never worked it out. (also, some services
act differently)

I was working on a btcom(4) device that would just emulate a normal tty
but work has stalled and I need to get a round tuit again, sigh.

It is not difficult to write something that will listen on a
RFCMM channel (and register with SDP server), maybe
rfcomm_sppd should be able to handle something like that

That would be great, and have symmetry with the HF/HSET case for audio
in each direction.

Yeah, but its complicated - normally you would make the outgoing bluetooth
connection to the phone and either wait for an incoming call or make an
outgoing call before starting up PPP.

unless you were the phone, and its the other way around.

there is a program in FreeBSD called rfcomm_pppd that does
handle this kind of thing for certain phones, but I didn't
port it because it seemed more useful for their user-ppp
daemon.

Ahah. The doco for this even mentions the quirky 'callback' behaviour
of this phone (p900). This does seem like a more particular bit of
glue for invoking that program, a more generic SPP listener that just
made the connection appear on a pty would be fine for me.

Without making any claims, I did modify this program so that it at least
builds on NetBSD but it was a while ago so I don't know if it is of any
use to you (attached) in the meantime?

I will think about what needs to be done to rfcomm_sppd so you can set up
incoming connections that are unaware of bluetooth.

iain

Thu, 18 Jan 2007, Daniel Carosone wrote:

I haven't been able to get the other direction working, fwiw. While
RFCMM to other devices like the gps works, trying to use the phone's
SPP like a modem doesn't - I get a connection, but just echoes of
whatever I type and no other response to AT commands, etc. I need to
resort to irda for that.

I found why this happens in stdio mode. Because of the tty input
processing, no <crever gets transmitted

Then I found another problem. The slave tty was being set to raw mode and
probably it was this that made the 'cu -l ttyp9' fail to work properly

So, in the process of adding a server mode I've mostly rewritten
rfcomm_sppd.c, new version and manpage is attached Please take a look
and let me know if you can get it to work* with pppd? I'm not sure how to
go about setting that up with only one machine so I haven't tried it, but
plain connections work just fine as do outgoing PPP connections.

regards,
iain
(* or any other problems/comments :)

caveats:

1. if you do

% rfcomm_sppd -a phone -c dun -t ttyp9
<makes connection and detaches>
% cu -l ttyp9
<works fine, then exit cu>
% cu -l ttyp9

the second time you try to access the slave tty you just get Device
Busy and must HUP the rfcomm_sppd process. I'm looking into that.

2. registering services with sdpd is privileged but libsdp returns EI for
that (there is no SDP error corresponding to EPERM, so it gets lost) - use
sudo for server mode.

Wed, 24 Jan 2007, Daniel Carosone wrote:
[incoming bluetooth connections]
I'll get around to testing this part a little later, thanks again.
Hi Dan,
Have you had any joy with that?
No pressure, but if its ok I will request a pullup to netbsd-4
iain