HELP: pppd won't answer/authenticate my dial-in

[m***@thales-is.com]

I am using a Windows NT box to connect to a Digital UNIX 4.0E box over
PPP via modem.
I have the modems talking, and when I dial over PPP from the PC, the
call is answered on the UNIX box, but PPP doesn't seem to authenicate
it, and the call is terminated.
(We did have this working on some other kit ages ago, and I'm trying to
set it up on another box).

Details:
1) pppd is in /etc/inittab:
pppdaemon:23:respawn:/usr/sbin/pppd -detach +pap login tty00 57600

2) /etc/ppp/options
crtscts
defaultroute
netmask 255.255.0.0
silent
ipcp-accept-remote
modem
debug
proxyarp
kdebug 7

3) .rhosts for user on UNIX allows any dial-in (i.e. "+ +") [will
tighten this up later]

4) syslog for local2.debug, when pppd starts up:
pppd started by root, uid 0
Using interface ppp0
Connect: ppp0 <--> /dev/tty01

Then when I try to connect in and fail, I get:
Slave died: EOF on tty
Modem hangup
Exit

5) syslog for kern.debug shows some stuff that I can't make sense of,
but I can post if someone could use it

6) At the PC end, it indicates that it is waiting for authentication of
the username/password

7) I have tried removing the "login" from the pppd line in
/etc/inittab, and creating a pap-secrets file with * * "" in, but that
is no better

Thanks in advance
Mark
mark . bergman @ thales - is . com

[James Carlson]

Post by m***@thales-is.com
defaultroute

That doesn't necessarily make sense for a dial-in link. It means the
guy calling you provides _your_ link to the Internet.

Post by m***@thales-is.com
netmask 255.255.0.0

That doesn't actually do anything for point-to-point links.

Post by m***@thales-is.com
silent

You probably don't want that.

Post by m***@thales-is.com
kdebug 7

Kdebug isn't terribly useful unless you're hacking the kernel modules.

Post by m***@thales-is.com
3) .rhosts for user on UNIX allows any dial-in (i.e. "+ +") [will
tighten this up later]

.rhosts isn't related to dial-in.

Post by m***@thales-is.com
pppd started by root, uid 0
Using interface ppp0
Connect: ppp0 <--> /dev/tty01

You might want to try to get a stack dump on the process at that
point. I'll bet it's stuck in open(2) because the tty isn't (for some
reason) configured to handle carrier detect correctly.

Post by m***@thales-is.com
5) syslog for kern.debug shows some stuff that I can't make sense of,
but I can post if someone could use it

Please do. Nothing you've posted gives clear answers for what's going
wrong here, except that PPP isn't running at all.

Post by m***@thales-is.com
6) At the PC end, it indicates that it is waiting for authentication of
the username/password

That's just a generic message. Windoze will report that message even
if the other end of the link is connected to a doorknob.

Post by m***@thales-is.com
7) I have tried removing the "login" from the pppd line in
/etc/inittab, and creating a pap-secrets file with * * "" in, but that
is no better

You're not even exchanging LCP. The low-level modem connection is
_NOT_ working. That appears to be the root problem here, and the rest
of it is of no importance (yet).

[m***@thales-is.com]

Post by James Carlson

Post by m***@thales-is.com
5) syslog for kern.debug shows some stuff that I can't make sense of,
but I can post if someone could use it

Please do. Nothing you've posted gives clear answers for what's going
wrong here, except that PPP isn't running at all.

OK:
Jan 25 17:04:27 nwscada1 vmunix: ppp_if0: init
Jan 25 17:04:27 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 25 17:04:27 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 25 17:04:28 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 25 17:04:28 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 25 17:04:28 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 25 17:04:28 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 25 17:05:56 nwscada1 vmunix: ppp_if0: closed
Jan 25 17:05:56 nwscada1 vmunix: ppp_async0: closing
Jan 25 17:06:01 nwscada1 vmunix: ppp_if0: init
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 25 17:06:14 nwscada1 vmunix: ppp_if0: closed
Jan 25 17:06:14 nwscada1 vmunix: ppp_async0: closing

(the above is for two dial-in attempts).

Thanks for help so far.
(Oh, and to "Unruh" who also replied, I do also have a syslog for
daemon)

Mark
mark . bergman @ thales - is . com

[m***@thales-is.com]

Post by James Carlson

Post by m***@thales-is.com
5) syslog for kern.debug shows some stuff that I can't make sense of,
but I can post if someone could use it

Please do. Nothing you've posted gives clear answers for what's going
wrong here, except that PPP isn't running at all.

OK:
Jan 25 17:04:27 nwscada1 vmunix: ppp_if0: init
Jan 25 17:04:27 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 25 17:04:27 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 25 17:04:28 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 25 17:04:28 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 25 17:04:28 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 25 17:04:28 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 25 17:05:56 nwscada1 vmunix: ppp_if0: closed
Jan 25 17:05:56 nwscada1 vmunix: ppp_async0: closing
Jan 25 17:06:01 nwscada1 vmunix: ppp_if0: init
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 25 17:06:01 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 25 17:06:14 nwscada1 vmunix: ppp_if0: closed
Jan 25 17:06:14 nwscada1 vmunix: ppp_async0: closing

(the above is for two dial-in attempts).

Thanks for help so far.
(Oh, and to "Unruh" who also replied, I do also have a syslog for
daemon)

Mark
mark . bergman @ thales - is . com

[m***@thales-is.com]

Post by James Carlson
You're not even exchanging LCP. The low-level modem connection is
_NOT_ working.

I tried running a Hyperterminal from the PC, and dialling manually with
ATDT.
When the modems connect, I get: CONNECT 1200/ARQ/LAPM/V42BIS (then
nothing)

I also tried putting a getty on the UNIX machine (after disabling pppd
in inittab),.and using Hyperterminal as before, I got: CONNECT
2400/ARQ/LAPM/V42BIS and a login prompt which allowed me to login to
the UNIX machine.

I have tried playing a little with modem settings, when I retried I got
the same without the "V42BIS".

{oh, and sorry for the doubled reply post - I blame Google!)

Mark
mark . bergman @ thales - is . com

[James Carlson]

Post by m***@thales-is.com

Post by James Carlson
You're not even exchanging LCP. The low-level modem connection is
_NOT_ working.

I tried running a Hyperterminal from the PC, and dialling manually with
ATDT.
When the modems connect, I get: CONNECT 1200/ARQ/LAPM/V42BIS (then
nothing)

The "then nothing" part is exactly the problem.

Post by m***@thales-is.com
I also tried putting a getty on the UNIX machine (after disabling pppd
in inittab),.and using Hyperterminal as before, I got: CONNECT
2400/ARQ/LAPM/V42BIS and a login prompt which allowed me to login to
the UNIX machine.

Interesting. I wonder what special thing getty is doing on this
system?

You may want to use mgetty instead of running pppd directly on the
tty.

[m***@thales-is.com]

Post by James Carlson

Post by m***@thales-is.com
I also tried putting a getty on the UNIX machine (after disabling pppd
in inittab),.and using Hyperterminal as before, I got: CONNECT
2400/ARQ/LAPM/V42BIS and a login prompt which allowed me to login to
the UNIX machine.

You may want to use mgetty instead of running pppd directly on the
tty.

A colleague who worked on this initially (a few years ago) said he had
problems with the getty method which is why he went to running ppd
directly on the tty! He did have different modems though, so maybe
that was it. I will probably try the mgetty method anyway.

You mentioned in an earlier post that "silent" option is probably not
what is required.
I tried removing it from /etc/ppp/options, and I still cannot connect.
The ppp log shows packets being sent - I show it below, together with
the kern.log (sorry for the length; I have edited it a bit!).
My PC did give a different error in its Event Log - "The data link was
terminated by the remote machine" rather than "Remote PPP peer is not
responding" as previously.

ppp-log:
an 26 11:37:34 nwscada1 pppd[2962]: pppd started by root, uid 0
Jan 26 11:37:34 nwscada1 pppd[2962]: Using interface ppp0
Jan 26 11:37:34 nwscada1 pppd[2962]: Connect: ppp0 <--> /dev/tty01
Jan 26 11:37:34 nwscada1 pppd[2962]: sent [LCP ConfReq id=0x1 <mru 296>
<asyncmap 0x200a0000> <auth upap> <magic 0xb34d30f4> <pcomp> <accomp>]
Jan 26 11:37:34 nwscada1 pppd[2962]: fsm_sdata(LCP): Sent code 1, id 1.
Jan 26 11:37:34 nwscada1 pppd[2962]: Timeout 1200082c0:140007ec0 in 3
seconds.
Jan 26 11:37:34 nwscada1 pppd[2962]: LCP: sending Configure-Request, id
1
Jan 26 11:37:37 nwscada1 pppd[2962]: sent [LCP ConfReq id=0x1 <mru 296>
<asyncmap 0x200a0000> <auth upap> <magic 0xb34d30f4> <pcomp> <accomp>]
Jan 26 11:37:37 nwscada1 pppd[2962]: fsm_sdata(LCP): Sent code 1, id 1.
Jan 26 11:37:37 nwscada1 pppd[2962]: Timeout 1200082c0:140007ec0 in 3
seconds.
Jan 26 11:37:37 nwscada1 pppd[2962]: LCP: sending Configure-Request, id
1
...<repeats>
Jan 26 11:38:01 nwscada1 pppd[2962]: Timeout 1200082c0:140007ec0 in 3
seconds.
Jan 26 11:38:01 nwscada1 pppd[2962]: LCP: sending Configure-Request, id
1
Jan 26 11:38:04 nwscada1 pppd[2962]: LCP: timeout sending
Config-Requests
Jan 26 11:38:04 nwscada1 pppd[2962]: Connection terminated.
Jan 26 11:38:19 nwscada1 pppd[2962]: Exit.
Jan 26 11:38:19 nwscada1 pppd[458]: pppd started by root, uid 0
Jan 26 11:38:19 nwscada1 pppd[458]: Using interface ppp0
Jan 26 11:38:19 nwscada1 pppd[458]: Connect: ppp0 <--> /dev/tty01
Jan 26 11:38:19 nwscada1 pppd[458]: sent [LCP ConfReq id=0x1 <mru 296>
<asyncmap 0x200a0000> <auth upap> <magic 0xc2f8c26f> <pcomp> <accomp>]
Jan 26 11:38:19 nwscada1 pppd[458]: fsm_sdata(LCP): Sent code 1, id 1.
Jan 26 11:38:19 nwscada1 pppd[458]: Timeout 1200082c0:140007ec0 in 3
seconds.
Jan 26 11:38:19 nwscada1 pppd[458]: LCP: sending Configure-Request, id
1
...<repeats>
Jan 26 11:39:31 nwscada1 pppd[2198]: fsm_sdata(LCP): Sent code 1, id 1.
Jan 26 11:39:31 nwscada1 pppd[2198]: Timeout 1200082c0:140007ec0 in 3
seconds.
Jan 26 11:39:31 nwscada1 pppd[2198]: LCP: sending Configure-Request, id
1
Jan 26 11:39:34 nwscada1 pppd[2198]: LCP: timeout sending
Config-Requests
Jan 26 11:39:34 nwscada1 pppd[2198]: Connection terminated.
Jan 26 11:39:34 nwscada1 pppd[2198]: Exit.
Jan 26 11:39:34 nwscada1 pppd[3219]: slave died: EOF on pipe.
Jan 26 11:39:34 nwscada1 pppd[3127]: pppd started by root, uid 0
Jan 26 11:39:34 nwscada1 pppd[3127]: Using interface ppp0
Jan 26 11:39:34 nwscada1 pppd[3127]: Connect: ppp0 <--> /dev/tty01
Jan 26 11:39:34 nwscada1 pppd[3127]: sent [LCP ConfReq id=0x1 <mru 296>
<asyncmap 0x200a0000> <auth upap> <magic 0xac9c3025> <pcomp> <accomp>]
Jan 26 11:39:34 nwscada1 pppd[3127]: fsm_sdata(LCP): Sent code 1, id 1.
Jan 26 11:39:34 nwscada1 pppd[3127]: Timeout 1200082c0:140007ec0 in 3
seconds.
Jan 26 11:39:34 nwscada1 pppd[3127]: LCP: sending Configure-Request, id
1
Jan 26 11:39:37 nwscada1 pppd[3127]: sent [LCP ConfReq id=0x1 <mru 296>
<asyncmap 0x200a0000> <auth upap> <magic 0xac9c3025> <pcomp> <accomp>]
Jan 26 11:39:37 nwscada1 pppd[3127]: fsm_sdata(LCP): Sent code 1, id 1.
Jan 26 11:39:37 nwscada1 pppd[3127]: Timeout 1200082c0:140007ec0 in 3
seconds.
Jan 26 11:39:37 nwscada1 pppd[3127]: LCP: sending Configure-Request, id
1
Jan 26 11:39:37 nwscada1 pppd[3167]: slave died: EOF on tty.
Jan 26 11:39:37 nwscada1 pppd[3127]: Modem hangup
Jan 26 11:39:37 nwscada1 pppd[3127]: Untimeout 1200082c0:140007ec0.
Jan 26 11:39:37 nwscada1 pppd[3127]: Exit.
Jan 26 11:39:42 nwscada1 pppd[2085]: pppd started by root, uid 0

kern.log:
Jan 26 11:37:28 nwscada1 vmunix: ppp_if0: closed
Jan 26 11:37:28 nwscada1 vmunix: ppp_async0: closing
Jan 26 11:37:34 nwscada1 vmunix: ppp_if0: init
Jan 26 11:37:34 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 26 11:37:34 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 26 11:37:34 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 26 11:37:34 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 26 11:37:34 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 26 11:37:34 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 26 11:37:34 nwscada1 vmunix: ppp_async0: sent output frame of 58
bytes
Jan 26 11:37:34 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:37:37 nwscada1 vmunix: ppp_async0: sent output frame of 58
bytes
Jan 26 11:37:37 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
...<repeats>
Jan 26 11:38:01 nwscada1 vmunix: ppp_async0: sent output frame of 58
bytes
Jan 26 11:38:01 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:38:04 nwscada1 vmunix: ppp_if0: closed
Jan 26 11:38:04 nwscada1 vmunix: ppp_async0: closing
Jan 26 11:38:19 nwscada1 vmunix: ppp_if0: init
Jan 26 11:39:04 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 26 11:39:04 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 26 11:39:04 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 26 11:39:04 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 26 11:39:04 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 26 11:39:04 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 26 11:39:04 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:04 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:07 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:07 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:10 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:10 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:13 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:13 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:16 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:16 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:18 nwscada1 vmunix: ppp_async: missed ALLSTATIONS (0xff),
got 0xf3
Jan 26 11:39:18 nwscada1 vmunix: ppp_if: input error inc to 12
Jan 26 11:39:19 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:19 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:22 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:22 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:25 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:25 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:28 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:28 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:31 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:39:31 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:34 nwscada1 vmunix: ppp_if0: closed
Jan 26 11:39:34 nwscada1 vmunix: ppp_async0: closing
Jan 26 11:39:34 nwscada1 vmunix: ppp_if0: init
Jan 26 11:39:34 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 26 11:39:34 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 26 11:39:34 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 26 11:39:34 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 26 11:39:34 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 26 11:39:34 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 26 11:39:34 nwscada1 vmunix: ppp_async0: sent output frame of 58
bytes
Jan 26 11:39:34 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:34 nwscada1 vmunix: ppp_async: missed ALLSTATIONS (0xff),
got 0xf2
Jan 26 11:39:34 nwscada1 vmunix: ppp_if: input error inc to 13
Jan 26 11:39:37 nwscada1 vmunix: ppp_async0: sent output frame of 58
bytes
Jan 26 11:39:37 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:39:37 nwscada1 vmunix: ppp_if0: closed
Jan 26 11:39:37 nwscada1 vmunix: ppp_async0: closing
Jan 26 11:39:42 nwscada1 vmunix: ppp_if0: init
Jan 26 11:39:42 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 26 11:39:42 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 26 11:39:42 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 26 11:39:42 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 26 11:39:42 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 26 11:39:42 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 26 11:39:42 nwscada1 vmunix: ppp_async0: sent output frame of 58
bytes
Jan 26 11:39:42 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
...
Jan 26 11:40:10 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:40:12 nwscada1 vmunix: ppp_if0: closed
Jan 26 11:40:12 nwscada1 vmunix: ppp_async0: closing
Jan 26 11:40:27 nwscada1 vmunix: ppp_if0: init
Jan 26 11:40:27 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 26 11:40:27 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 26 11:40:28 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 26 11:40:28 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 26 11:40:28 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 26 11:40:28 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 26 11:40:28 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:40:28 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:40:30 nwscada1 vmunix: ppp_async0: sent output frame of 59
bytes
Jan 26 11:40:54 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:40:57 nwscada1 vmunix: ppp_if0: closed
Jan 26 11:40:57 nwscada1 vmunix: ppp_async0: closing
Jan 26 11:41:13 nwscada1 vmunix: ppp_if0: init
Jan 26 11:41:13 nwscada1 vmunix: ppp_async: SIFASYNCMAP
ffffffffffffffff
Jan 26 11:41:13 nwscada1 vmunix: ppp_async: SIFCOMPPROT 0
Jan 26 11:41:13 nwscada1 vmunix: ppp_async: SIFCOMPAC 0
Jan 26 11:41:13 nwscada1 vmunix: ppp_async: SIFRASYNCMAP 0
Jan 26 11:41:13 nwscada1 vmunix: ppp_async: SIFCOMPPROT 2
Jan 26 11:41:13 nwscada1 vmunix: ppp_async: SIFCOMPAC 2
Jan 26 11:41:13 nwscada1 vmunix: ppp_async0: sent output frame of 62
bytes
Jan 26 11:41:13 nwscada1 vmunix: ppp_async:
7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d26207d>
Jan 26 11:41:16 nwscada1 vmunix: ppp_async0: sent output frame of 62
bytes
...


Thanks again
Mark
mark . bergman @ thales - is . com

[James Carlson]

Post by m***@thales-is.com
what is required.
I tried removing it from /etc/ppp/options, and I still cannot connect.
The ppp log shows packets being sent - I show it below, together with
the kern.log (sorry for the length; I have edited it a bit!).

Ah ha! Now we're getting somewhere. This is much better.

Post by m***@thales-is.com
Jan 26 11:37:34 nwscada1 pppd[2962]: sent [LCP ConfReq id=0x1 <mru 296>
<asyncmap 0x200a0000> <auth upap> <magic 0xb34d30f4> <pcomp> <accomp>]

I don't remember seeing that in the configuration. Where are those
MRU and ACCM values being set? And are you sure they're what you
want?

Post by m***@thales-is.com
Jan 26 11:37:34 nwscada1 pppd[2962]: fsm_sdata(LCP): Sent code 1, id 1.

Warning: this is a hacked version of pppd (perhaps compiled with
"-DDEBUG;" I'm not sure what else is wrong). The standard version
does not print that message.

Post by m***@thales-is.com
Jan 26 11:39:18 nwscada1 vmunix: ppp_async: missed ALLSTATIONS (0xff),
got 0xf3

This indicates that the data coming back to you is garbled.

The most likely explanation for that is that the local modem is not
locked at the DTE data rate that you specified (57600, I think). In
other words, the modem and the computer are set to different baud
rates, and you need to fix that if you want to continue.

[m***@thales-is.com]

Post by James Carlson

Post by m***@thales-is.com
Jan 26 11:39:18 nwscada1 vmunix: ppp_async: missed ALLSTATIONS (0xff),
got 0xf3

This indicates that the data coming back to you is garbled.
The most likely explanation for that is that the local modem is not
locked at the DTE data rate that you specified (57600, I think).

Right, that appears to be it!
When I used Hyperterminal at the PC to dial manually, I saw that the
modems were connecting at 1200 (I think I saw 2400 once previously).
I then ran pppd at 1200, and Hey Presto, the ppp connection completes,
lots of debug etc. (though of course the link is very slow!)

So just to confirm, the speed parameter I pass to pppd must exactly
match the speed that the modems are talking at?

(I now need to look at why the modems are connecting so slowly! They
are US Robotics 57.6K modems, but probably rather old! We are running
them through two internal phone connections at our company exchange.
We may try and find some other modems).

Post by James Carlson

Post by m***@thales-is.com
Jan 26 11:37:34 nwscada1 pppd[2962]: sent [LCP ConfReq id=0x1 <mru 296>
<asyncmap 0x200a0000> <auth upap> <magic 0xb34d30f4> <pcomp> <accomp>]

I don't remember seeing that in the configuration. Where are those
MRU and ACCM values being set? And are you sure they're what you
want?

They were higher up in the options file, separated by a lot of comment
lines.
They're the defaults that came with Digital Unix as far as I know.
(Do you have any suggestions?)

Thanks again for the help
Mark
mark . bergman @ thales - is . com

[James Carlson]

Post by m***@thales-is.com
So just to confirm, the speed parameter I pass to pppd must exactly
match the speed that the modems are talking at?

Yes.

Post by m***@thales-is.com
(I now need to look at why the modems are connecting so slowly! They
are US Robotics 57.6K modems, but probably rather old! We are running
them through two internal phone connections at our company exchange.
We may try and find some other modems).

There are at least two ways to deal with the problem.

1. Set up the modem so that it has a locked DTE rate. Most modems
have this sort of feature. Get the "AT" command set reference
for your modem and look for it.

2. Use the pppd "init" option to specify a chat script that sets up
the rate as desired. ("chat '' AT OK '\c'" should probably be
enough.)

Post by m***@thales-is.com
They were higher up in the options file, separated by a lot of comment
lines.
They're the defaults that came with Digital Unix as far as I know.
(Do you have any suggestions?)

Unless you know you need them, lose them. The best configuration (for
pppd in particular, and also for most software components) is none.
By design, the defaults are intended to be good.

For these two, you'd set asyncmap if you know that the data path isn't
transparent to control characters. The value specified (200a0000)
implies that your modem eats XON (DC1; Ctrl-Q), XOFF (DC3; Ctrl-S),
and ASCII GS (Ctrl-]). That's pretty strange, and sounds more like
telnet than a modem.

[m***@thales-is.com]

Post by James Carlson
1. Set up the modem so that it has a locked DTE rate.

I had tried setting the modem speed. It has one option (&Un) for a
minimum speed and another (&Nn) for a maximum speed, but if I specify a
minimum speed higher than 1200/2400, it just rejects the incoming call
(presumably because it cannot negotiate higher)

Mark
mark . bergman @ thales - is . com

[Clifford Kite]

Post by m***@thales-is.com

Post by James Carlson
1. Set up the modem so that it has a locked DTE rate.

I had tried setting the modem speed. It has one option (&Un) for a
minimum speed and another (&Nn) for a maximum speed, but if I specify a
minimum speed higher than 1200/2400, it just rejects the incoming call
(presumably because it cannot negotiate higher)

I'd also recommend you use mgetty _and_ configure it to initialize the
USR modem with AT&F1 . That should allow modem auto-negotiation, and
the pppd speed can then likely be set to 115200 (which is the highest
a serial device using a 16550A UART can reliably tolerate - 56k * 2).

[James Carlson]

Post by m***@thales-is.com

Post by James Carlson
1. Set up the modem so that it has a locked DTE rate.

I had tried setting the modem speed. It has one option (&Un) for a
minimum speed and another (&Nn) for a maximum speed, but if I specify a
minimum speed higher than 1200/2400, it just rejects the incoming call
(presumably because it cannot negotiate higher)

You need to set the DTE rate, not the DCE rate. The commands you're
talking about set the DCE rate.

Modern modems have two "sides" -- one is the serial link, and the
other is the telephone connection. They're not really related to each
other, because the encoding protocols on the telephone side are fairly
sophisticated. What this means is that the modem does (and has to do)
data buffering and flow control.

Thus, there are two data rates involved. The one you care about here
is the one on the serial side.

[m***@thales-is.com]

Post by m***@thales-is.com
So just to confirm, the speed parameter I pass to pppd must exactly
match the speed that the modems are talking at?

Yes.

OK, I have now had some limited success!

As I mentioned, I was having problems getting the modems to connect at
high speeds.

Firstly, I put the modems between 2 PCs, using Hyperterminal on each at
57600, and dialled manually - Hey Presto I had a 57600 connection. -
this eliminated concerns about our internal telephone exchange.

Secondly, I put the receiving modem back to the Digital Unix box, and
ran "tip 57600" (with pppd not running) - modems connected at 1200.
I examined stty for the port, and its speed was 1200.
I killed the connection, and with tip still open, set the port speed
with stty to 57600.
Dial in again, and connection at 57600 - this shows that the port speed
must be set to 57600 to get the modems to connect at this speed.

Thirdly, I closed tip. Port speed went back to 1200.
I reinstated pppd (in /etc/inittab) - port speed still at 1200.
I used stty to set speed to 57600, and dialling in from the PC I
sometimes got a successful ppp connection, but many times the pppd died
and restarted (after I set the port speed), losing the speed setting,
so I was battling trying to set the speed and keep pppd running.

So, questions at the moment:
1) Should pppd be setting the port speed (in the same way that stty
does)
2) If I set the port speed with stty, should it get reset (e.g. if a
process that has the port open closes it or dies)?
3) Is there anyway to retain the port speed (this is a XP1000 box
running Digital Unix 4.0F)

(We do have this working to some equipment on another site, and I am
trying to recreate it on some support equipment. On site the receiving
modem is a Multitech (rather than a US Robotics), so I am going to try
and obtain a Multitech modem to see if that is any better.)

Mark
mark . bergman @ thales - is . com

[James Carlson]

Post by m***@thales-is.com
1) Should pppd be setting the port speed (in the same way that stty
does)

"Should?"

It does set the speed in the same way as stty does when given a speed
as one of the options. It doesn't touch the current line speed when
no speed option is set. See the pppd man page.

Post by m***@thales-is.com
2) If I set the port speed with stty, should it get reset (e.g. if a
process that has the port open closes it or dies)?

Typically, yes.

Post by m***@thales-is.com
3) Is there anyway to retain the port speed (this is a XP1000 box
running Digital Unix 4.0F)

I don't think that's the real problem, as I've stated in previous
posts.

The real problem is configuring your modem properly to lock the DTE
rate. See the reference manual for your modem.

According to several web sites I searched, USR modems usually use
"AT&B1" to lock the DTE rate. You would "tip" in at 57600 and issue
this command to lock the rate.

If your modem doesn't support that command for some reason, then you
might have to set dip switches. Very old modems were like that.

Some old consumer-grade modems can't lock the rate at all. If you
have one of those horrible beasts, then you'll need to use the pppd
"init" option, as I previously described.

[m***@thales-is.com]

Post by James Carlson
The real problem is configuring your modem properly to lock the DTE
rate. See the reference manual for your modem.
According to several web sites I searched, USR modems usually use
"AT&B1" to lock the DTE rate.

The modem does support that command but it didn't help; in fact that is
the default.

I have now obtained a Multitech modem which I am using at the receiving
UNIX end. (It is a Multitech modem that works on our site machine,
although I don't know if it is the same model of modem or not. My PC
modem now connects straight away at 57600 no problem, and stty on the
UNIX end shows 57600.
However, my PPP is now not connecting at all. Looking in the debug,
there is no exchange of LCP, i.e. no debug entries at all after the ppp
starts up.

I tried removing the "silent" ppp option, and I see the LCP Configure
Requests being sent in the debug file ("sent output frame of 58
bytes..." in kernel syslog file) and timing out.
Before (when using USR modem) I also got "missed ALLSTATIONS (0xff),
got 0xf3" which led you to the mismatched speed, but I'm not seeing
that this time - just the "sent output frame" messages.

Puzzled
Mark
mark . bergman @ thales - is . com

[James Carlson]

Post by m***@thales-is.com
I tried removing the "silent" ppp option, and I see the LCP Configure
Requests being sent in the debug file ("sent output frame of 58
bytes..." in kernel syslog file) and timing out.

That's a separate problem. I'm pretty sure this was discussed earlier
-- you almost certainly don't want to use "silent."

Post by m***@thales-is.com
Before (when using USR modem) I also got "missed ALLSTATIONS (0xff),
got 0xf3" which led you to the mismatched speed, but I'm not seeing
that this time - just the "sent output frame" messages.

At a guess, you still have modem configuration problems. It's hard to
tell at this point what those problems might be.

(Common problems include having a modem that defaults to software flow
control rather than hardware flow control, and a port set to 7 data
bits rather than 8. Those are just wild guesses, though.)

[Unruh]

Post by m***@thales-is.com

Post by m***@thales-is.com
So just to confirm, the speed parameter I pass to pppd must exactly
match the speed that the modems are talking at?

Yes.

OK, I have now had some limited success!
As I mentioned, I was having problems getting the modems to connect at
high speeds.
Firstly, I put the modems between 2 PCs, using Hyperterminal on each at
57600, and dialled manually - Hey Presto I had a 57600 connection. -
this eliminated concerns about our internal telephone exchange.
Secondly, I put the receiving modem back to the Digital Unix box, and
ran "tip 57600" (with pppd not running) - modems connected at 1200.
I examined stty for the port, and its speed was 1200.
I killed the connection, and with tip still open, set the port speed
with stty to 57600.
Dial in again, and connection at 57600 - this shows that the port speed
must be set to 57600 to get the modems to connect at this speed.
Thirdly, I closed tip. Port speed went back to 1200.
I reinstated pppd (in /etc/inittab) - port speed still at 1200.
I used stty to set speed to 57600, and dialling in from the PC I
sometimes got a successful ppp connection, but many times the pppd died
and restarted (after I set the port speed), losing the speed setting,
so I was battling trying to set the speed and keep pppd running.

It sounds to me like Digital Unix is messing with the port. Ie, each time
it is reset it also resets the speed.
Yes, you can give pppd the port speed to run at.
Just put in the number
pppd .... 57600

Post by m***@thales-is.com
1) Should pppd be setting the port speed (in the same way that stty
does)

Its default is 1200.

Post by m***@thales-is.com
2) If I set the port speed with stty, should it get reset (e.g. if a
process that has the port open closes it or dies)?

Ask the writers of Digital Unix. Noone else has access to the source code.

Post by m***@thales-is.com
3) Is there anyway to retain the port speed (this is a XP1000 box
running Digital Unix 4.0F)

tell pppd the port speed you want.

In fact with most modern modems and serial cards, a better port speed is
115200, the max speed the port can be set at. The port speed on most modems
is independent of the connection speed and because of modem compression,
should be higher than the modem to modem rate.

Post by m***@thales-is.com
(We do have this working to some equipment on another site, and I am
trying to recreate it on some support equipment. On site the receiving
modem is a Multitech (rather than a US Robotics), so I am going to try
and obtain a Multitech modem to see if that is any better.)
Mark

[jpd]

Post by m***@thales-is.com
(I now need to look at why the modems are connecting so slowly! They
are US Robotics 57.6K modems, but probably rather old! We are running
them through two internal phone connections at our company exchange.
We may try and find some other modems).

Apart from all the other suggestions, I'd like to note you say you're
using a PABX. Those are likely built for voice only, and may not provide
a suitable channel for the modem to use. I'd say to not point at your
modems before you have independent confirmation the PABX provided
channel is indeed suitable for POTS data transfer.

The rather preposterous CONNECT 1200/and/a/xmas/tree message seems to
indicate that the modems tried and failed due to bad line, not that they
are too old or otherwise incapable. Assuming that you did configure them
correctly and did not force this extremely low speed by accident or
intention. Given the right commands it is probably possible to extract
proof of either out of your USR modems.

[Unruh]

Post by m***@thales-is.com

Post by James Carlson

Post by m***@thales-is.com
I also tried putting a getty on the UNIX machine (after disabling pppd
in inittab),.and using Hyperterminal as before, I got: CONNECT
2400/ARQ/LAPM/V42BIS and a login prompt which allowed me to login to
the UNIX machine.

You may want to use mgetty instead of running pppd directly on the
tty.

A colleague who worked on this initially (a few years ago) said he had
problems with the getty method which is why he went to running ppd
directly on the tty! He did have different modems though, so maybe
that was it. I will probably try the mgetty method anyway.

He probably tried to use getty, not mgetty. mgetty ( the m stands for
modem) is designed for answering modems. It works. The writers of all of
the other gettys recommend mgetty for answering modems. They do not
recommend using their own gettys for modems.

[Unruh]

Post by m***@thales-is.com

Post by James Carlson
You're not even exchanging LCP. The low-level modem connection is
_NOT_ working.

I tried running a Hyperterminal from the PC, and dialling manually with
ATDT.
When the modems connect, I get: CONNECT 1200/ARQ/LAPM/V42BIS (then
nothing)
I also tried putting a getty on the UNIX machine (after disabling pppd
in inittab),.and using Hyperterminal as before, I got: CONNECT
2400/ARQ/LAPM/V42BIS and a login prompt which allowed me to login to
the UNIX machine.

As I said, do not use pppd to answer the phone. It is not really designed
for that. Put mgetty (NOT getty, mgetty) onto the phone line in
/etc/inittab, and set up /etc/mgetty*/login.conf with a line like

/AutoPPP/ - a_ppp /usr/sbin/pppd debug nodetach


Now when the remote machine starts up pppd, it will start up pppd as well.

Again, pppd was not designed for answering modems. As Carlson says it is
possible to do, but that is huge source of potential problems.

Post by m***@thales-is.com
I have tried playing a little with modem settings, when I retried I got
the same without the "V42BIS".
{oh, and sorry for the doubled reply post - I blame Google!)
Mark

[Unruh]

Post by m***@thales-is.com
I am using a Windows NT box to connect to a Digital UNIX 4.0E box over
PPP via modem.
I have the modems talking, and when I dial over PPP from the PC, the
call is answered on the UNIX box, but PPP doesn't seem to authenicate
it, and the call is terminated.
(We did have this working on some other kit ages ago, and I'm trying to
set it up on another box).
pppdaemon:23:respawn:/usr/sbin/pppd -detach +pap login tty00 57600

You surely want mgetty, not pppd respawning. Ie, something has to answer
the phone, tell the modem to connect, and then hand off to pppd. \

Post by m***@thales-is.com
2) /etc/ppp/options
crtscts
defaultroute
netmask 255.255.0.0
silent
ipcp-accept-remote
modem
debug
proxyarp
kdebug 7

kdebug has done nothing for a number of years. You can (I assume) remove
this.

Post by m***@thales-is.com
3) .rhosts for user on UNIX allows any dial-in (i.e. "+ +") [will
tighten this up later]
pppd started by root, uid 0
Using interface ppp0
Connect: ppp0 <--> /dev/tty01

You also want a syslog for daemon.* That is where the pppd messages come
from.

Post by m***@thales-is.com
Slave died: EOF on tty
Modem hangup
Exit
5) syslog for kern.debug shows some stuff that I can't make sense of,
but I can post if someone could use it
6) At the PC end, it indicates that it is waiting for authentication of
the username/password

pppd cannot answer modems. It cannot decode the "CONNECT etc messages from
the modem.

Post by m***@thales-is.com
7) I have tried removing the "login" from the pppd line in
/etc/inittab, and creating a pap-secrets file with * * "" in, but that
is no better
Thanks in advance
Mark

[James Carlson]

Post by Unruh

Post by m***@thales-is.com
6) At the PC end, it indicates that it is waiting for authentication of
the username/password

pppd cannot answer modems. It cannot decode the "CONNECT etc messages from
the modem.

That's not quite true. pppd will open the tty (causing DTR to go
high) and then hang at the open because DCD is low. If the modem is
correctly configured to answer automatically when DTR is asserted, it
should answer when a call comes in and (after training and asserting
DCD) cause pppd to wake up.

On dial-in, most modems don't emit the "CONNECT" goop back towards the
answerer, but if they do, pppd will happily throw it on the floor as a
packet with bad FCS.

At least based on the symptoms, the problem is that DCD isn't getting
asserted, the wire is broken, or something in the tty subsystem is not
responding to it correctly.

[m***@thales-is.com]

Post by m***@thales-is.com
call is answered on the UNIX box, but PPP doesn't seem to authenicate
it, and the call is terminated.

Well, I appear to have full success now!

I'm using a Multitech modem to receive on (which gets my modems to
connect at 57600), and when doing more experimenting with a few
telephone sockets on my company's exchange, found one combination that
allows PPP to connect every time (using default modem options!)!
(I had previously tried this pair of sockets the other way round
unsuccessfully, i.e. with PC and UNIX box swapped).

I should now really go back to the pair of USR modems, or do more
experimentation with the phone sockets (go back to the reverse
combination that failed previously, etc), but I don't want to touch my
working setup in case I can't get it back again! (I've spent far too
much time on this already!)

Thanks to all who offered assistance
Mark
mark . bergman @ thales - is . com