Re: [PATCH2] PPP in -direct mode does not execute any chat scripts

[Maksim Yevmenkin]

Hello Brian,

Yes, this looks fine, although I think this shows that the -direct
description is wrong.  Perhaps this is more appropriate:
-direct
   This is used for communicating over an already established connection,
   usually when receiving incoming connections accepted by getty(8).  ppp
   ignores the ``set device'' line and uses descriptor 0 as the link.  ppp
   will ignore any configured chat scripts unless the ``force-scripts''
   option has been enabled.
   If callback

Do you agree with this description ?  If so, I'll go ahead and commit the
yes, this is more accurate description. i missed it.

changes.  Just to be picky, I'll re-sort the OPT_ variables too :*P
no problem :)

And thanks for the patches.
thank you for reviewing them :)
max


On Mon, 03 Feb 2003 14:45:37 -0800, Maksim Yevmenkin wrote:

Dear Brian and Hackers,

Please find updated proposed version of the patch. As suggested by
Warner option has been renamed to 'force-sripts' and now works for
both 'direct' and 'dedicated' modes. Also as suggested by Terry the
man page has been updated to document side effect of 'direct'.
-direct
  This is used for receiving incoming connections.  ppp ignores the
  ``set device'' line and uses descriptor 0 as the link.  ppp will
  never use any configured chat scripts unless ``force-scripts''
  option has been enabled.
  If callback is configured, ppp will use the ``set device'' infor-
  mation when dialing back.
-dedicated
  This option is designed for machines connected with a dedicated
  wire.  ppp will always keep the device open and will never use
  any configured chat scripts unless ``force-scripts'' option has
  been enabled.
force-scripts
  Default: Disabled. Forces execution of the configured chat
  scripts in direct and dedicated modes.

Please find attached patch that adds new option to the PPP.

run-scripts-in-direct-mode
  Default: Disabled. This allows to run chat scripts in
  direct mode.
did i miss anything? objections? comments? reviews?


First comment: run it past Brian Somers <[EMAIL PROTECTED]>; it's
his baby, and he's the active maintainer.
I have sent him e-mail.


Rest of comments:

Actually, why doesn't "-direct" allow a chat script by default?
The man page doesn't document that as a side-effect of "-direct",
only of "-dedicated", but it's been there since the import.
Should this really be a "negotiate" section command, rather than
just a command or a "set" command?
Also, there are only two other commands even have a "-" in them,
and both of them only have one (just seems a little long, compared
to, say, "rsid" or "direct-with-script", or even "force-script").
Personal preference: don't make it conditional on "-direct", let
it also work with "-dedicated", and call it "force-script" or
something, instead.
done


The man page should be updated -- including the undocumented
side-effect of "-direct" disabling scripts).
done

thanks
max





___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH2] PPP in -direct mode does not execute any chat scripts

[Brian Somers]

Hi,

Yes, this looks fine, although I think this shows that the -direct
description is wrong.  Perhaps this is more appropriate:

-direct
   This is used for communicating over an already established connection,
   usually when receiving incoming connections accepted by getty(8).  ppp
   ignores the ``set device'' line and uses descriptor 0 as the link.  ppp
   will ignore any configured chat scripts unless the ``force-scripts''
   option has been enabled.

   If callback

Do you agree with this description ?  If so, I'll go ahead and commit the
changes.  Just to be picky, I'll re-sort the OPT_ variables too :*P

And thanks for the patches.

On Mon, 03 Feb 2003 14:45:37 -0800, Maksim Yevmenkin wrote:
> Dear Brian and Hackers,
> 
> Please find updated proposed version of the patch. As suggested by
> Warner option has been renamed to 'force-sripts' and now works for
> both 'direct' and 'dedicated' modes. Also as suggested by Terry the
> man page has been updated to document side effect of 'direct'.
> 
> -direct
>This is used for receiving incoming connections.  ppp ignores the
>``set device'' line and uses descriptor 0 as the link.  ppp will
>never use any configured chat scripts unless ``force-scripts''
>option has been enabled.
> 
>If callback is configured, ppp will use the ``set device'' infor-
>mation when dialing back.
> 
> -dedicated
>This option is designed for machines connected with a dedicated
>wire.  ppp will always keep the device open and will never use
>any configured chat scripts unless ``force-scripts'' option has
>been enabled.
> 
> force-scripts
>Default: Disabled. Forces execution of the configured chat
>scripts in direct and dedicated modes.
> 
> >>Please find attached patch that adds new option to the PPP.
> >>
> >>run-scripts-in-direct-mode
> >>Default: Disabled. This allows to run chat scripts in
> >>direct mode.
> >>
> >>did i miss anything? objections? comments? reviews?
> > 
> > 
> > First comment: run it past Brian Somers <[EMAIL PROTECTED]>; it's
> > his baby, and he's the active maintainer.
> 
> I have sent him e-mail.
> 
> > Rest of comments:
> > 
> > Actually, why doesn't "-direct" allow a chat script by default?
> > The man page doesn't document that as a side-effect of "-direct",
> > only of "-dedicated", but it's been there since the import.
> > 
> > Should this really be a "negotiate" section command, rather than
> > just a command or a "set" command?
> > 
> > Also, there are only two other commands even have a "-" in them,
> > and both of them only have one (just seems a little long, compared
> > to, say, "rsid" or "direct-with-script", or even "force-script").
> > 
> > Personal preference: don't make it conditional on "-direct", let
> > it also work with "-dedicated", and call it "force-script" or
> > something, instead.
> 
> done
> 
> > The man page should be updated -- including the undocumented
> > side-effect of "-direct" disabling scripts).
> 
> done
> 
> thanks
> max
> 


-- 
Brian <[EMAIL PROTECTED]>   <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !   <[EMAIL PROTECTED]>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: [PATCH2] PPP in -direct mode does not execute any chat scripts

[Maksim Yevmenkin]

Terry,

> > seems like it :) just got report back from one of the testers.
> > he got connected to the internet over his T39m bluetooth enabled
> > cell phone. the cool thing is that you can make CSD, GPRS or HSCSD
> > calls. its just a matter of init string you send to the phone :)
> > still waiting on t68i and Nokia 7650 reports.
> 
> What kind of security negotiation occurs between devices, or
> can I use anyone's cell phone, as long as we are in the same
> restaurant, and I get a table in the middle?  8-) 8-).

you can if person with the cell phone is stupid :) and
you do not have to get table in the middle. you have
to be within ~10 meters radius. you also can get access
to person's address book, calendar etc. as well :)

all authentication and encryption based around link keys.
one link key for each pair of devices. link key can be:

1) programmed into device itself (up to 16 keys)
2) can be requested from the user via HCI events
3) can be generated from the PIN code, PIN code 
   is requested from the user via HCI event.

normally what happens is:

1) device A tries to connect to device B
2) device B now looks for the link key that corresponds
   to device A's BDADDR. if found then key is used
3) if no link key found then both device A and
   device B locally generate Link_Key_Request event
4) both device A and B either get the keys from user 
   A and user B, or if there is still no link key
   user sends Link_Key_Negative_Reply command
5) if no link key was received then both devices
   locally generate PIN_Code_Request
6) now both user A and user B have to enter PIN
   codes. the link key will be calculated from the
   PIN code. if no PIN code exists then user sends
   PIN_Code_Negative_Reply command to the device.

this is implemented inside hcsecd.

the user has option to disable authentication and in this case
anyone can connect and no link key is required. also user can
prevent device from peforming inquiry scan, i.e. the device
will not respond to inquiry requests from other devices. user
also can prevent device from performing page scans, i.e. device
will not accept connections.

thanks,
max


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Re: [PATCH2] PPP in -direct mode does not execute any chat scripts

[Terry Lambert]

Maksim Yevmenkin wrote:
> seems like it :) just got report back from one of the testers.
> he got connected to the internet over his T39m bluetooth enabled
> cell phone. the cool thing is that you can make CSD, GPRS or HSCSD
> calls. its just a matter of init string you send to the phone :)
> still waiting on t68i and Nokia 7650 reports.

What kind of security negotiation occurs between devices, or
can I use anyone's cell phone, as long as we are in the same
restaurant, and I get a table in the middle?  8-) 8-).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Re: [PATCH2] PPP in -direct mode does not execute any chat scripts

[Maksim Yevmenkin]

Terry,


Maksim Yevmenkin wrote:


force-scripts
  Default: Disabled. Forces execution of the configured chat
  scripts in direct and dedicated modes.



Outstanding!  If Brian doesn't veto, I'd say it's gold, and
someone should commit it; so I guess this fixes the last Bluetooth
Cell phone PPP problem, right?


seems like it :) just got report back from one of the testers.
he got connected to the internet over his T39m bluetooth enabled
cell phone. the cool thing is that you can make CSD, GPRS or HSCSD
calls. its just a matter of init string you send to the phone :)
still waiting on t68i and Nokia 7650 reports.


PS: I can't believe that Warner and I came within one letter of
suggesting the same option name.  8-) 8-).


:)

thanks,
max


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Re: [PATCH2] PPP in -direct mode does not execute any chat scripts

[M. Warner Losh]

My un-trained eye says this is good.  Thanks for turning around the
feedback so quickly.  Now, we wait for Brian to review it.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Re: [PATCH2] PPP in -direct mode does not execute any chat scripts

[Terry Lambert]

Maksim Yevmenkin wrote:
> force-scripts
>Default: Disabled. Forces execution of the configured chat
>scripts in direct and dedicated modes.

Outstanding!  If Brian doesn't veto, I'd say it's gold, and
someone should commit it; so I guess this fixes the last Bluetooth
Cell phone PPP problem, right?

PS: I can't believe that Warner and I came within one letter of
suggesting the same option name.  8-) 8-).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

[PATCH2] PPP in -direct mode does not execute any chat scripts

[Maksim Yevmenkin]

Dear Brian and Hackers,

Please find updated proposed version of the patch. As suggested by
Warner option has been renamed to 'force-sripts' and now works for
both 'direct' and 'dedicated' modes. Also as suggested by Terry the
man page has been updated to document side effect of 'direct'.

-direct
  This is used for receiving incoming connections.  ppp ignores the
  ``set device'' line and uses descriptor 0 as the link.  ppp will
  never use any configured chat scripts unless ``force-scripts''
  option has been enabled.

  If callback is configured, ppp will use the ``set device'' infor-
  mation when dialing back.

-dedicated
  This option is designed for machines connected with a dedicated
  wire.  ppp will always keep the device open and will never use
  any configured chat scripts unless ``force-scripts'' option has
  been enabled.

force-scripts
  Default: Disabled. Forces execution of the configured chat
  scripts in direct and dedicated modes.


Please find attached patch that adds new option to the PPP.

run-scripts-in-direct-mode
   Default: Disabled. This allows to run chat scripts in
   direct mode.

did i miss anything? objections? comments? reviews?



First comment: run it past Brian Somers <[EMAIL PROTECTED]>; it's
his baby, and he's the active maintainer.


I have sent him e-mail.


Rest of comments:

Actually, why doesn't "-direct" allow a chat script by default?
The man page doesn't document that as a side-effect of "-direct",
only of "-dedicated", but it's been there since the import.

Should this really be a "negotiate" section command, rather than
just a command or a "set" command?

Also, there are only two other commands even have a "-" in them,
and both of them only have one (just seems a little long, compared
to, say, "rsid" or "direct-with-script", or even "force-script").

Personal preference: don't make it conditional on "-direct", let
it also work with "-dedicated", and call it "force-script" or
something, instead.


done


The man page should be updated -- including the undocumented
side-effect of "-direct" disabling scripts).


done

thanks
max

diff -ru8 ppp.orig/bundle.h ppp/bundle.h
--- ppp.orig/bundle.h   Mon Feb  3 10:34:44 2003
+++ ppp/bundle.hMon Feb  3 14:08:06 2003
@@ -44,16 +44,17 @@
 #define OPT_LOOPBACK   0x0040
 #define OPT_PASSWDAUTH 0x0080
 #define OPT_PROXY  0x0100
 #define OPT_PROXYALL   0x0200
 #define OPT_SROUTES0x0400
 #define OPT_TCPMSSFIXUP0x0800
 #define OPT_THROUGHPUT 0x1000
 #define OPT_UTMP   0x2000
+#define OPT_FORCE_SCRIPTS 0x4000 /* force chat scripts */
 
 #define MAX_ENDDISC_CLASS 5
 
 #define Enabled(b, o) ((b)->cfg.opt & (o))
 
 /* AutoAdjust() values */
 #define AUTO_UP1
 #define AUTO_DOWN  2
diff -ru8 ppp.orig/command.c ppp/command.c
--- ppp.orig/command.c  Mon Feb  3 10:34:45 2003
+++ ppp/command.c   Mon Feb  3 14:26:37 2003
@@ -2830,16 +2830,19 @@
 
   return 0;
 }
 
 static struct cmdtab const NegotiateCommands[] = {
   {"filter-decapsulation", NULL, OptSet, LOCAL_AUTH,
   "filter on PPPoUDP payloads", "disable|enable",
   (const void *)OPT_FILTERDECAP},
+  {"force-scripts", NULL, OptSet, LOCAL_AUTH,
+   "Force execution of the configured chat scripts", "disable|enable",
+   (const void *)OPT_FORCE_SCRIPTS},
   {"idcheck", NULL, OptSet, LOCAL_AUTH, "Check FSM reply ids",
   "disable|enable", (const void *)OPT_IDCHECK},
   {"iface-alias", NULL, IfaceAliasOptSet, LOCAL_AUTH,
   "retain interface addresses", "disable|enable",
   (const void *)OPT_IFACEALIAS},
 #ifndef NOINET6
   {"ipcp", NULL, OptSet, LOCAL_AUTH, "IP Network Control Protocol",
   "disable|enable", (const void *)OPT_IPCP},
@@ -2861,19 +2864,19 @@
   {"tcpmssfixup", "mssfixup", OptSet, LOCAL_AUTH, "Modify MSS options",
   "disable|enable", (const void *)OPT_TCPMSSFIXUP},
   {"throughput", NULL, OptSet, LOCAL_AUTH, "Rolling throughput",
   "disable|enable", (const void *)OPT_THROUGHPUT},
   {"utmp", NULL, OptSet, LOCAL_AUTH, "Log connections in utmp",
   "disable|enable", (const void *)OPT_UTMP},
 
 #ifndef NOINET6
-#define OPT_MAX 13 /* accept/deny allowed below and not above */
+#define OPT_MAX 14 /* accept/deny allowed below and not above */
 #else
-#define OPT_MAX 11
+#define OPT_MAX 12
 #endif
 
   {"acfcomp", NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
   "Address & Control field compression", "accept|deny|disable|enable",
   (const void *)NEG_ACFCOMP},
   {"chap", "chap05", NegotiateSet, LOCAL_AUTH | LOCAL_CX,
   "Challenge Handshake Authentication Protocol", "accept|deny|disable|enable",
   (const void *)NEG_CHAP05},
diff -ru8 ppp.orig/datalink.c ppp/datalink.c
--- ppp.orig/datalink.c Mon Feb  3 10:34:45 2003
+++ ppp/datalink.c  Mon Feb  3 14:17:52 2003
@@ -956,17 +956,18 @@
   free(dl);
 
   return result;
 }
 
 void
 datalink_Up(struct datalink *dl, int runscripts, int packetmode)
 {
-  if (dl->physical->type & (PHYS_DIRECT|PHYS_DEDICATED))
+  if (!Enabled(dl->bundle, OPT_FORCE_SCRIPTS) &&
+  (d

Re: [PATCH] PPP in -direct mode does not execute any chat scripts

[Terry Lambert]

Maksim Yevmenkin wrote:
> Please find attached patch that adds new option to the PPP.
> 
> run-scripts-in-direct-mode
> Default: Disabled. This allows to run chat scripts in
> direct mode.
> 
> did i miss anything? objections? comments? reviews?

First comment: run it past Brian Somers <[EMAIL PROTECTED]>; it's
his baby, and he's the active maintainer.

Rest of comments:

Actually, why doesn't "-direct" allow a chat script by default?
The man page doesn't document that as a side-effect of "-direct",
only of "-dedicated", but it's been there since the import.

Should this really be a "negotiate" section command, rather than
just a command or a "set" command?

Also, there are only two other commands even have a "-" in them,
and both of them only have one (just seems a little long, compared
to, say, "rsid" or "direct-with-script", or even "force-script").

Personal preference: don't make it conditional on "-direct", let
it also work with "-dedicated", and call it "force-script" or
something, instead.

The man page should be updated -- including the undocumented
side-effect of "-direct" disabling scripts).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Re: [PATCH] PPP in -direct mode does not execute any chat scripts

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Maksim Yevmenkin <[EMAIL PROTECTED]> writes:
: Dear Hackers,
: 
: Please find attached patch that adds new option to the PPP.
: 
: 
: run-scripts-in-direct-mode
:   Default: Disabled. This allows to run chat scripts in
:   direct mode.
: 
: did i miss anything? objections? comments? reviews?

Maybe it would be better to call this "force-scripts" or something
more general purpose so that one could force the use of scripts
anywhere.  Making direct mode have a special case override seems a
little too restrictive.  The heart of the patch would become:

-  if (dl->physical->type & (PHYS_DIRECT|PHYS_DEDICATED))
+  if (!Enabled(dl->bundle, OPT_FORCE_SCRIPTS) &&
+  (dl->physical->type & (PHYS_DIRECT|PHYS_DEDICATED))
 /* Ignore scripts */
 runscripts = 0;

with corresponding changes to the docs, defines, etc.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

[PATCH] PPP in -direct mode does not execute any chat scripts

[Maksim Yevmenkin]

Dear Hackers,

Please find attached patch that adds new option to the PPP.


run-scripts-in-direct-mode
	Default: Disabled. This allows to run chat scripts in
	direct mode.

did i miss anything? objections? comments? reviews?

thanks,
max



I'm working on the Bluetooth stack for FreeBSD and currently
doing testing for new in-kernel RFCOMM code. RFCOMM is a way
to emulate serial link over Bluetooth.

In particular Bluetooth spec defines two RFCOMM based profiles
LAN (Network Access profile) and DUN (DialUp Networking profile).
Both profiles use PPP.

My current in-kernel RFCOMM code provides SOCK_STREAM sockets
interface, i.e. when application wants to talk RFCOMM it just
opens a socket. The next step is to run PPP, so the launcher
program opens RFCOMM connection then dup() socket to stdin and
stdout and exec() PPP in direct mode.

Everything works great for the LAN profile, where null-modem
connection is assumed and both client and server start talking
PPP right after RFCOMM connection is established.

However the DUN profile is more tricky. In this scenario client
just connected to the virtual serial port on the server. Now to
start PPP session client must "dial a number". i.e. there is
still need for a little chat script.

Here is an example:

1) I'd like to use my GPRS and Bluetooth enabled cell phone to
   access the Internet
2) I open a RFCOMM connection to the cell phone and get connected
   to the virtual serial port on the cell phone.
3) Now i must dial a "special" GRPS number, i.e. something like
   ATD*98***1# and wait for CONNECT string from the phone
4) Now i can talk PPP.

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.

thanks,
max
diff -ru8 ppp.orig/bundle.h ppp/bundle.h
--- ppp.orig/bundle.h   Mon Feb  3 10:34:44 2003
+++ ppp/bundle.hMon Feb  3 10:36:56 2003
@@ -44,16 +44,17 @@
 #define OPT_LOOPBACK   0x0040
 #define OPT_PASSWDAUTH 0x0080
 #define OPT_PROXY  0x0100
 #define OPT_PROXYALL   0x0200
 #define OPT_SROUTES0x0400
 #define OPT_TCPMSSFIXUP0x0800
 #define OPT_THROUGHPUT 0x1000
 #define OPT_UTMP   0x2000
+#define OPT_RSIDM  0x4000 /* run-scripts-in-direct-mode */
 
 #define MAX_ENDDISC_CLASS 5
 
 #define Enabled(b, o) ((b)->cfg.opt & (o))
 
 /* AutoAdjust() values */
 #define AUTO_UP1
 #define AUTO_DOWN  2
diff -ru8 ppp.orig/command.c ppp/command.c
--- ppp.orig/command.c  Mon Feb  3 10:34:45 2003
+++ ppp/command.c   Mon Feb  3 10:57:05 2003
@@ -2851,29 +2851,32 @@
   {"loopback", NULL, OptSet, LOCAL_AUTH, "Loop packets for local iface",
   "disable|enable", (const void *)OPT_LOOPBACK},
   {"passwdauth", NULL, OptSet, LOCAL_AUTH, "Use passwd file",
   "disable|enable", (const void *)OPT_PASSWDAUTH},
   {"proxy", NULL, OptSet, LOCAL_AUTH, "Create a proxy ARP entry",
   "disable|enable", (const void *)OPT_PROXY},
   {"proxyall", NULL, OptSet, LOCAL_AUTH, "Proxy ARP for all remote hosts",
   "disable|enable", (const void *)OPT_PROXYALL},
+  {"run-scripts-in-direct-mode", NULL, OptSet, LOCAL_AUTH,
+   "Run char scripts in direct mode", "disable|enable",
+   (const void *)OPT_RSIDM},
   {"sroutes", NULL, OptSet, LOCAL_AUTH, "Use sticky routes",
   "disable|enable", (const void *)OPT_SROUTES},
   {"tcpmssfixup", "mssfixup", OptSet, LOCAL_AUTH, "Modify MSS options",
   "disable|enable", (const void *)OPT_TCPMSSFIXUP},
   {"throughput", NULL, OptSet, LOCAL_AUTH, "Rolling throughput",
   "disable|enable", (const void *)OPT_THROUGHPUT},
   {"utmp", NULL, OptSet, LOCAL_AUTH, "Log connections in utmp",
   "disable|enable", (const void *)OPT_UTMP},
 
 #ifndef NOINET6
-#define OPT_MAX 13 /* accept/deny allowed below and not above */
+#define OPT_MAX 14 /* accept/deny allowed below and not above */
 #else
-#define OPT_MAX 11
+#define OPT_MAX 12
 #endif
 
   {"acfcomp", NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
   "Address & Control field compression", "accept|deny|disable|enable",
   (const void *)NEG_ACFCOMP},
   {"chap", "chap05", NegotiateSet, LOCAL_AUTH | LOCAL_CX,
   "Challenge Handshake Authentication Protocol", "accept|deny|disable|enable",
   (const void *)NEG_CHAP05},
diff -ru8 ppp.orig/datalink.c ppp/datalink.c
--- ppp.orig/datalink.c Mon Feb  3 10:34:45 2003
+++ ppp/datalink.c  Mon Feb  3 11:03:48 2003
@@ -956,17 +956,18 @@
   free(dl);
 
   return result;
 }
 
 void
 datalink_Up(struct datalink *dl, int runscripts, int packetmode)
 {
-  if (dl->physical->type & (PHYS_DIRECT|PHYS_DEDICATED))
+  if ((dl->physical->type & PHYS_DEDICATED) ||
+  ((dl->physical->type & PHYS_DIRECT) && !Enabled(dl->bundle, OPT_RSIDM)))
 /* Ignore scripts */
 runscripts = 0;
 
   switch (dl->state) {
 case DATALINK_CLOSED:
   

RE: PPP in -direct mode does not execute any chat scripts

[Maksim Yevmenkin]

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

[Maksim Yevmenkin]

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

[M. Warner Losh]

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

[Daniel O'Connor]

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

[Maksim Yevmenkin]

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

[Daniel O'Connor]

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

[Maksim Yevmenkin]

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

[M. Warner Losh]

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

[Maksim Yevmenkin]

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

[Daniel O'Connor]

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

PPP in -direct mode does not execute any chat scripts

[Maksim Yevmenkin]

Dear Hackers,

I'm working on the Bluetooth stack for FreeBSD and currently
doing testing for new in-kernel RFCOMM code. RFCOMM is a way
to emulate serial link over Bluetooth.

In particular Bluetooth spec defines two RFCOMM based profiles
LAN (Network Access profile) and DUN (DialUp Networking profile).
Both profiles use PPP.

My current in-kernel RFCOMM code provides SOCK_STREAM sockets
interface, i.e. when application wants to talk RFCOMM it just
opens a socket. The next step is to run PPP, so the launcher
program opens RFCOMM connection then dup() socket to stdin and
stdout and exec() PPP in direct mode.

Everything works great for the LAN profile, where null-modem
connection is assumed and both client and server start talking
PPP right after RFCOMM connection is established.

However the DUN profile is more tricky. In this scenario client
just connected to the virtual serial port on the server. Now to
start PPP session client must "dial a number". i.e. there is
still need for a little chat script.

Here is an example:

1) I'd like to use my GPRS and Bluetooth enabled cell phone to
   access the Internet
2) I open a RFCOMM connection to the cell phone and get connected
   to the virtual serial port on the cell phone.
3) Now i must dial a "special" GRPS number, i.e. something like
   ATD*98***1# and wait for CONNECT string from the phone
4) Now i can talk PPP.

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.

thanks,
max


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message