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

This is a discussion on HELP: pppd won't answer/authenticate my dial-in - Unix ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

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

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

    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


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

    mark.bergman@thales-is.com writes:
    > defaultroute


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

    > netmask 255.255.0.0


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

    > silent


    You probably don't want that.

    > kdebug 7


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

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


    ..rhosts isn't related to dial-in.

    > 4) syslog for local2.debug, when pppd starts up:
    > 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.

    > 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.

    > 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.

    > 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).

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

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

    mark.bergman@thales-is.com writes:

    >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


    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. \



    >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.


    >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


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



    >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


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



    >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



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

    Unruh writes:
    > >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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

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


    James Carlson wrote:
    > mark.bergman@thales-is.com writes:
    > > 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


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


    James Carlson wrote:
    > mark.bergman@thales-is.com writes:
    > > 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


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


    James Carlson wrote:
    > 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


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

    mark.bergman@thales-is.com writes:
    > James Carlson wrote:
    > > 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.

    > 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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

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


    James Carlson wrote:
    > mark.bergman@thales-is.com writes:
    > > 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
    ]
    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
    ]
    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
    ....
    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
    ]
    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
    ....
    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
    ]
    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
    ]
    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:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:37:37 nwscada1 vmunix: ppp_async0: sent output frame of 58
    bytes
    Jan 26 11:37:37 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    ....
    Jan 26 11:38:01 nwscada1 vmunix: ppp_async0: sent output frame of 58
    bytes
    Jan 26 11:38:01 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    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:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:39:07 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:39:07 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:39:10 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:39:10 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:39:13 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:39:13 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:39:16 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:39:16 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    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:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:39:22 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:39:22 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:39:25 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:39:25 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:39:28 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:39:28 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:39:31 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:39:31 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    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:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    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:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    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:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    ....
    Jan 26 11:40:10 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    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:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:40:30 nwscada1 vmunix: ppp_async0: sent output frame of 59
    bytes
    Jan 26 11:40:54 nwscada1 vmunix: ppp_async:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    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:
    7e7ddf7d23c0217d217d217d207d3c7d217d247d21287d227d 26207d>
    Jan 26 11:41:16 nwscada1 vmunix: ppp_async0: sent output frame of 62
    bytes
    ....


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


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

    mark.bergman@thales-is.com writes:
    > 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.

    > Jan 26 11:37:34 nwscada1 pppd[2962]: sent [LCP ConfReq id=0x1
    > ]


    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?

    > 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.

    > 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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

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


    James Carlson wrote:
    > mark.bergman@thales-is.com writes:
    > > 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).

    Just on another of your points:

    > > Jan 26 11:37:34 nwscada1 pppd[2962]: sent [LCP ConfReq id=0x1
    > > ]

    >
    > 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


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

    mark.bergman@thales-is.com writes:
    > So just to confirm, the speed parameter I pass to pppd must exactly
    > match the speed that the modems are talking at?


    Yes.

    > (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.)

    > 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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

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

    mark.bergman@thales-is.com writes:


    >James Carlson wrote:
    >> 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.





    >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



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

    mark.bergman@thales-is.com writes:


    >James Carlson wrote:
    >> mark.bergman@thales-is.com writes:
    >> > 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.



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


    James Carlson wrote:
    > 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


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

    mark.bergman@thales-is.com wrote:

    > James Carlson wrote:
    >> 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).

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    /* Speak softly and carry a +6 two-handed sword. */

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

    Begin <1138298261.007434.120630@g49g2000cwa.googlegroups. com>
    On 2006-01-26, mark.bergman@thales-is.com wrote:
    > (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.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

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


    James Carlson wrote:
    > mark.bergman@thales-is.com writes:
    > > 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


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

    mark.bergman@thales-is.com writes:
    > So, questions at the moment:
    > 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.

    > 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.

    > 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.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

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


    > 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


+ Reply to Thread
Page 1 of 2 1 2 LastLast