Hi list,

I've had some feedback from Paul Mackerras concerning pppd and Macs.  His
email is attached at the bottom of this message.

If you recall, my problem was:

- ppp connections worked fine manually
BUT
- pppd locked up during a diald connect

Ed Dekker suggested using /dev/cua0 rather than /dev/ttyS0 - this works but
the use of cua0 is 'deprecated'.  Paul's email explains why there is a
difference between these two interfaces.  The Mac does not support use of
the DCD line (only DTR and CTS).

Paul suggests use of the pppd 'local' option.  However, this is incompatible
with diald.  I've tried putting local in the ppp options and (as expected)
it doesn't work.

The diald documentation states for pppd-options that "In particular you
should not specify the tty device .... local, mtu and proxyarp.  Use the
equivalent diald commands to control these pppd settings".  However, there
doesn't appear to be a diald equivalent to pppd's 'local'  ;-)

Clearly there is a need for a solution within diald for this problem -
otherwise Macs won't work with diald without the coded change cited below.
Suggestions (apart from slinging my Macs) are welcome!

  Iain Stevenson



Paul's response follows:


> Ed Dekker suggested to me that one should use /dev/cua0 in preference to
> /dev/ttyS0.  This works and diald starts pppd just fine.  So the first
question
> is why are these two interfaces behaving differently?  It seems that /dev/cua0
> cannot be scrapped for Mac users at least.

The thing is that cua0 won't wait for the carrier detect line (DCD) to be
asserted when you open it, whereas ttyS0 will if the CLOCAL flag is clear
(if CLOCAL is set, it won't).  Since you can do everything with ttyS0 that
you can with cua0, the latter is now deprecated.

> I went back to using ttyS0.  After prodding around in the pppd code I found
out
> that pppd hangs in 'main.c' at the point where it attempts to open the ttyS0
> device.  Specifically, main.c contains the following:

Well, your device must not be asserting the DCD line.  If it is just not
connected, I suggest you use the `local' option to pppd.

> and things go wrong on the 'open' function.  John Adams suggested that I
> replace the last two lines with:
> 
>         if ((i = open(devnam, O_RDWR | O_NDELAY)) >= 0) {
>                   /* Clear the NDELAY flag now */
>                   int flags;
>                   flags = fcntl(i, F_GETFL) & ~(O_NDELAY);
>                   fcntl(i, F_SETFL, flags);
>                   break;
> 
> This solves the problem and enables diald to work with pppd using ttyS0.

This would be a bad idea because it would mean that you couldn't use pppd
in a mode where it will wait for DCD to be asserted from the modem, which
is useful in some situations.  Probably you just need to use the local
option.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
[EMAIL PROTECTED], http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.


-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]

Reply via email to