> > yes. that is one example. but the real trouble with tty is the
> > server application that wants to listen on wildcard address. for
> > example Network Access point that listens on RFCOMM channel 1. no
> > matter what client comes in the server will just accept connection
> > on the socket, fork and run PPP in direct mode.
> > also there are other things besides PPP that use RFCOMM. OBEX
> > is another example, where clients will put/get objects from
> > the server.
> OK, it is a pity you can't define variables when invoking PPP I guess :)
> > > Still I guess you could just run 'ppp rfcomm' instead..
> > it will only work for in RFCOMM client case. i do not know
> > how to build server applications with tty interface (pty's
> > do not count :)
> Heh, I use birda for IRDA, it's strictly userland and uses pty's.. Works
> really well :)
pty does not save you here. original RFCOMM code is a 100% userland
and uses pty's. the original code redirects pty's slave side to
stdin/stdout and runs PPP in -direct mode.
also all bluetooth devices make use of something called SDP (Service
Discovery Protocol) this is the way to advertise the service to the
rest of the world.
now with tty interface the server application will only be launched
when connection is established and tty exits. but in order to establish
RFCOMM connection clients must first talk SDP to figure out what
services are available on which RFCOMM channel. thus something
else must register services with local SDP daemon.
with sockets interface there is no problem. server application
just register service with local SDP daemon and listen()s on
RFCOMM socket. when server application exits it removes service
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message