RE: PPP in -direct mode does not execute any chat scripts
Daniel, > > 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 registration. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Warner,
> : So you see it is probably possible to build a tty-like interface,
> : but i do not think it really worth the trouble. In fact one
> : can do it right now with the help of nmdm(4) driver. It is a
> : simple wrapper that would pass the data between socket and
> : /dev/nmdm0{A|B}.
>
> That's one way.
too many moving parts :)
> Another is to have some control program that interacts with RFCOMM to
> establish a 'connection' between endpoints and sets the various
> parameters and gives userland access to it as a tty.
sure, but userland somehow *must* know which tty to use. only
control program knows which tty it just created, so the control
program *must* run userland and *must* tell which tty to use.
again if you want to run server, than control program somehow
must be informed that incomming connections on RFCOMM channel X
should be handled by server application Y.
all this make control program somewhat like inetd.
my point is that in most cases you do not need all this stuff.
there is no point in tty interface. even if you do something
like wireless printing (BTW this also goes via RFCOMM). all
you need to do is just setup filter that would accept data,
open RFCOMM connection and feed data into printer via RFCOMM.
> barring that, you'll may be able to run chat on stdin/stdout before
> ppp gets into the act and get the number dialed that way and have ppp
> -direct run afterwards.
that's another option. but why duplicate the code and make things
more complicated for user? why user have to setup additional chat
script just to dial a GPRS number? if i add 'enable scripts-in-direct-mode'
option to PPP all user would have to do is to add 'set dial
Re: PPP in -direct mode does not execute any chat scripts
In message: <[EMAIL PROTECTED]>
"Maksim Yevmenkin" <[EMAIL PROTECTED]> writes:
: So you see it is probably possible to build a tty-like interface,
: but i do not think it really worth the trouble. In fact one
: can do it right now with the help of nmdm(4) driver. It is a
: simple wrapper that would pass the data between socket and
: /dev/nmdm0{A|B}.
That's one way.
Another is to have some control program that interacts with RFCOMM to
establish a 'connection' between endpoints and sets the various
parameters and gives userland access to it as a tty.
barring that, you'll may be able to run chat on stdin/stdout before
ppp gets into the act and get the number dialed that way and have ppp
-direct run afterwards.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
On Mon, 2003-02-03 at 14:41, Maksim Yevmenkin wrote: > 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 :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Daniel, > > Is there any reason that RFCOMM doesn't give full tty support, like > > the various USB modem drivers do? That's likely the best way to deal > > with this. Then ppp or whatever application you want will just work. > > Maybe it is necessary/useful to 'steer' PPP from the RFCOMM end? > > eg 'when you get a connection from this device connect via PPP on > stdin/stdout' 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. > 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 :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: PPP in -direct mode does not execute any chat scripts
On Mon, 2003-02-03 at 13:48, M. Warner Losh wrote: > Is there any reason that RFCOMM doesn't give full tty support, like > the various USB modem drivers do? That's likely the best way to deal > with this. Then ppp or whatever application you want will just work. Maybe it is necessary/useful to 'steer' PPP from the RFCOMM end? eg 'when you get a connection from this device connect via PPP on stdin/stdout' Still I guess you could just run 'ppp rfcomm' instead.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Warner,
> Is there any reason that RFCOMM doesn't give full tty support, like
> the various USB modem drivers do? That's likely the best way to deal
> with this. Then ppp or whatever application you want will just work.
Yes, there is. RFCOMM connection can only be established when
baseband link is open. Also RFCOMM connection exists between
pair of device and identified by source address, destination
address and channel. In fact up to 60 RFCOMM channels can exist
on the same baseband link between the same pair of devices.
So, with tty device things look a bit weird. for example if
user wants to dial out then user must do three things:
1) establish binding between source, destination address, channel
and particular tty device;
2) open RFCOMM channel on the tty device;
3) start PPP on the tty device.
Things gets even more tricky when you want to run server
on specific RFCOMM channel. In this case tty device does not
exist at all until RFCOMM connection is establised. So it is
really hard to do binding between connection and tty device.
May be if we could clone tty devices then if would be easier.
Also Bluetooth spec. has redefined some aspects of GSM 07.10
spec. and all Bluetooth 1.1 devices do not use modem signals
defined in GSM 07.10. Instead there is something called
'credit based flow control'.
So you see it is probably possible to build a tty-like interface,
but i do not think it really worth the trouble. In fact one
can do it right now with the help of nmdm(4) driver. It is a
simple wrapper that would pass the data between socket and
/dev/nmdm0{A|B}.
thanks,
max
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
Re: PPP in -direct mode does not execute any chat scripts
Is there any reason that RFCOMM doesn't give full tty support, like the various USB modem drivers do? That's likely the best way to deal with this. Then ppp or whatever application you want will just work. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Daniel, > > So the questions is: would it be possible to enable PPP chat > > in "direct" mode? Is there any reason to not allow this? It > > seems 'login' script would do just fine. Is there any other/ > > better way to do this? One possible option right now is to > > execute /bin/chat from the launcher program before executing > > PPP, but i'd rather keep all chat scripts in PPP. > > You'd need to add an option to do this - enabling it by default would > break a lot of stuff (eg I use ppp -direct for incoming PPP calls). If > -direct *by default* used chat then I would have to change my ppp.conf > and that would suck :) > > Perhaps have 'enable usechatindirect' or some such.. i agree, it would break things if the 'default' section in the ppp.conf has 'set dial foo' and 'set login bar' lines in it (which is most likely the case) *and* if you use the same ppp.conf for both dialing out and receiving calls. in order to make things work people would have to put 'set dial' and 'set login' lines for the labels used in 'direct' mode. i guess it is better to add the option. back to PPP hacking then :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: PPP in -direct mode does not execute any chat scripts
On Mon, 2003-02-03 at 08:18, Maksim Yevmenkin wrote: > So the questions is: would it be possible to enable PPP chat > in "direct" mode? Is there any reason to not allow this? It > seems 'login' script would do just fine. Is there any other/ > better way to do this? One possible option right now is to > execute /bin/chat from the launcher program before executing > PPP, but i'd rather keep all chat scripts in PPP. You'd need to add an option to do this - enabling it by default would break a lot of stuff (eg I use ppp -direct for incoming PPP calls). If -direct *by default* used chat then I would have to change my ppp.conf and that would suck :) Perhaps have 'enable usechatindirect' or some such.. (You might want to forward the email to the PPP maintainer BTW) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
