From owner-freebsd-questions Sun Feb 2 20:56:17 2003 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C68F637B401; Sun, 2 Feb 2003 20:56:14 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46A2343F9B; Sun, 2 Feb 2003 20:56:14 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from SJDCEX01.int.exodus.net ([165.193.27.80]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Sun, 2 Feb 2003 20:56:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: PPP in -direct mode does not execute any chat scripts Date: Sun, 2 Feb 2003 20:56:13 -0800 Message-ID: <45258A4365C6B24A9832BFE224837D552B1288@sjdcex01.int.exodus.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP in -direct mode does not execute any chat scripts thread-index: AcLLPBtehfuRcb3kSp+1BQ5VcPciJwAAMgh/ From: "Maksim Yevmenkin" To: "M. Warner Losh" Cc: , X-OriginalArrivalTime: 03 Feb 2003 04:56:14.0085 (UTC) FILETIME=[93FB2350:01C2CB40] Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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}. >=20 > 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.=20 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.=20 > 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