Loopback when using PAP auth - PPP

This is a discussion on Loopback when using PAP auth - PPP ; Hi guys, This is me... again . I was success connecting two machines, using a RAS machine for getting modems, so I am using the socket option to connect to the RAS and get a modem. There is no problem ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Loopback when using PAP auth

  1. Loopback when using PAP auth

    Hi guys,

    This is me... again .

    I was success connecting two machines, using a RAS machine for getting
    modems, so I am using the socket option to connect to the RAS and get a
    modem. There is no problem if I use noauth option in server and client
    sides, but problems come when I try to use PAP auth.

    Client must authenticate using PAP, so I have used this options in
    server side: auth, require-pap. Client doesn't need server to auth
    itself, so it is connecting using noauth option:

    # server:
    /usr/bin/pppd pppd debug notty 192.168.0.6:192.168.07 -detach escape
    ff asyncmap 00002400

    (/etc/ppp/options: lock nodefaultroute noproxyarp auth require-pap)

    # client:
    pppd socket cisco2:5014 -detach lock crtscts mtu 296 mru 296 connect
    'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options' debug user EMI_TID_00
    escape ff asyncmap 00002400 noauth

    When client tries to connect, a "Serial line is looped back" is
    received:

    # pppd socket cisco2:5014 -detach lock crtscts mtu 296 mru 296 connect
    'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options' debug user EMI_TID_00
    escape ff asyncmap 00002400 noauth
    Using /dev/pts/10; master fd 6, slave fd 7
    pty speed set to 9600 bps
    starting charshunt for socket option
    connect option: 'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options'
    started (pid 1908)
    Serial connection established.
    Using interface sppp0
    Connect: sppp0 <--> /dev/pts/10
    /etc/ppp/chap-secrets is apparently empty
    sent [LCP ConfReq id=0x12 0x48ebf316> ]
    sent [LCP ConfReq id=0x12 0x48ebf316> ]
    rcvd [LCP ConfReq id=0x12 0x48ebf316> ]
    sent [LCP ConfNak id=0x12 ]
    rcvd [LCP ConfNak id=0x12 ]
    sent [LCP ConfReq id=0x13 0x1dcdd5d0> ]
    rcvd [LCP ConfReq id=0x13 0x1dcdd5d0> ]
    sent [LCP ConfNak id=0x13 ]
    rcvd [LCP ConfNak id=0x13 ]
    sent [LCP ConfReq id=0x14 0x73d4f93a> ]
    rcvd [LCP ConfReq id=0x14 0x73d4f93a> ]
    sent [LCP ConfNak id=0x14 ]
    rcvd [LCP ConfNak id=0x14 ]
    sent [LCP ConfReq id=0x15 0x3fd5565d> ]
    rcvd [LCP ConfReq id=0x15 0x3fd5565d> ]
    sent [LCP ConfNak id=0x15 ]
    rcvd [LCP ConfNak id=0x15 ]
    sent [LCP ConfReq id=0x16 0xd9ea0b2c> ]
    rcvd [LCP ConfReq id=0x16 0xd9ea0b2c> ]
    sent [LCP ConfNak id=0x16 ]
    rcvd [LCP ConfNak id=0x16 ]
    sent [LCP ConfReq id=0x17 0xac0d2571> ]
    rcvd [LCP ConfReq id=0x17 0xac0d2571> ]
    sent [LCP ConfNak id=0x17 ]
    rcvd [LCP ConfNak id=0x17 ]
    sent [LCP ConfReq id=0x18 0xa112d86c> ]
    rcvd [LCP ConfReq id=0x18 0xa112d86c> ]
    sent [LCP ConfNak id=0x18 ]
    rcvd [LCP ConfNak id=0x18 ]
    sent [LCP ConfReq id=0x19 0x4976dbfe> ]
    rcvd [LCP ConfReq id=0x19 0x4976dbfe> ]
    sent [LCP ConfNak id=0x19 ]
    rcvd [LCP ConfNak id=0x19 ]
    sent [LCP ConfReq id=0x1a 0xdedc0559> ]
    rcvd [LCP ConfReq id=0x1a 0xdedc0559> ]
    sent [LCP ConfNak id=0x1a ]
    rcvd [LCP ConfNak id=0x1a ]
    sent [LCP ConfReq id=0x1b 0x4dc4fc90> ]
    rcvd [LCP ConfReq id=0x1b 0x4dc4fc90> ]
    sent [LCP ConfNak id=0x1b ]
    rcvd [LCP ConfNak id=0x1b ]
    Serial line is looped back.
    sent [LCP TermReq id=0x1c "Loopback detected"]
    rcvd [LCP TermReq id=0x1c "Loopback detected"]
    sent [LCP TermAck id=0x1c]
    rcvd [LCP TermAck id=0x1c]
    Connection terminated.
    Waiting for 1 child processes...
    pid 1907: pppd (charshunt)
    select
    Child process pppd (charshunt) finished (pid 1907), status = 1

    It seems that server side cannot talk ppp whit the client, or maybe it
    is specting something and it is echoing all the messages it receives.
    But when I use a 'noauth' in server side, all works fine. What can be
    the problem?

    # server pap-secrets file:
    server CLIENT client_pass *

    # client pap-secrets file:
    CLIENT * client_pass *

    Any help?
    Thanks a lot!,

    Mariano.


  2. Re: Loopback when using PAP auth

    "KiKo" writes:
    > Client must authenticate using PAP, so I have used this options in
    > server side: auth, require-pap. Client doesn't need server to auth
    > itself, so it is connecting using noauth option:


    Good so far.

    > # client:
    > pppd socket cisco2:5014 -detach lock crtscts mtu 296 mru 296 connect
    > 'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options' debug user EMI_TID_00
    > escape ff asyncmap 00002400 noauth


    Ouch. That's one tiny MTU. Good luck with that.

    > When client tries to connect, a "Serial line is looped back" is
    > received:


    That has nothing to do with PAP. It means that you're talking to
    yourself. This is yet another communications problem, and not a
    problem in PPP.

    > sent [LCP ConfReq id=0x12 > 0x48ebf316> ]
    > rcvd [LCP ConfReq id=0x12 > 0x48ebf316> ]


    That's the error right there. Note that the Magic Number option is
    the same sent as received. This means that you're not talking to
    anybody else. You're getting your own packets sent back to you.

    Either the local modem is in some sort of local-loopback mode, or the
    serial connection is misconfigured, or there's a problem at the far
    end.

    This can be caused by a variety of communications failures, but none
    of them really involve PPP itself.

    --
    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: Loopback when using PAP auth

    KiKo wrote:
    > Hi guys,


    > This is me... again .


    > I was success connecting two machines, using a RAS machine for getting
    > modems, so I am using the socket option to connect to the RAS and get a
    > modem. There is no problem if I use noauth option in server and client
    > sides, but problems come when I try to use PAP auth.


    > Client must authenticate using PAP, so I have used this options in
    > server side: auth, require-pap. Client doesn't need server to auth
    > itself, so it is connecting using noauth option:


    > # server:
    > /usr/bin/pppd pppd debug notty 192.168.0.6:192.168.07 -detach escape
    > ff asyncmap 00002400


    > (/etc/ppp/options: lock nodefaultroute noproxyarp auth require-pap)


    > # client:
    > pppd socket cisco2:5014 -detach lock crtscts mtu 296 mru 296 connect
    > 'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options' debug user EMI_TID_00
    > escape ff asyncmap 00002400 noauth


    > When client tries to connect, a "Serial line is looped back" is
    > received:


    The client "socket" and server "notty" options suggest PPP is run over a
    PTY master/slave pair via a conduit such as telnet, ssh, rsh, or similar.
    If so then the client "crtscts" option is not appropriate and could very
    well be causing the loopback problem.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"

  4. Re: Loopback when using PAP auth

    James Carlson writes:
    >"KiKo" writes:
    >>
    >> sent [LCP ConfReq id=0x12 >> 0x48ebf316> ]
    >> rcvd [LCP ConfReq id=0x12 >> 0x48ebf316> ]

    >
    >That's the error right there. Note that the Magic Number option is
    >the same sent as received. This means that you're not talking to
    >anybody else. You're getting your own packets sent back to you.
    >
    >Either the local modem is in some sort of local-loopback mode, or the
    >serial connection is misconfigured, or there's a problem at the far
    >end.
    >


    Modems that haven't dialed and made a connection yet are very often
    in a "sort of local-loopback" mode. It's called "command mode" where
    commands are echoed back to the sender for display on the screen.

    -Greg
    --
    Do NOT reply via e-mail.
    Reply in the newsgroup.

  5. Re: Loopback when using PAP auth

    But it s a little strange, because if I don't use auth options, ppp
    works fine.

    For example:

    # server side
    /usr/bin/pppd pppd debug notty 192.168.0.6:192.168.07 -detach escape
    ff asyncmap 00002400

    (noauth option in /etc/ppp/options)

    #client side
    pppd socket cisco2:5014 -detach lock connect 'chat -v -f
    /IBERCOM/usr/mgg327/ppp/chat-options' escape ff asyncmap 00002400 debug
    noauth

    It works. So... what is the different between using noauth and
    auth+require-pap options? Why if I use auth+require-pap options PPP
    could not be bring up?

    :\


  6. Re: Loopback when using PAP auth

    "KiKo" writes:
    > It works. So... what is the different between using noauth and
    > auth+require-pap options?


    Nothing at this level. It's got to be either coincidence or that
    something else is changed between the two configurations.

    "Looped-back" means the low-level path is broken, not that there's
    something wrong with authentication. It means that every byte you
    transmit is just coming right back to you.

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

  7. Re: Loopback when using PAP auth

    KiKo wrote:
    > But it s a little strange, because if I don't use auth options, ppp
    > works fine.


    I think you really mean PPP works only if you use the noauth option
    and don't use auth or require-pap. Moreover, if PPP works when the
    server has that option but fails to do so when the server requires
    the client to authenticate itself then the current failure is not
    likely due to loopback.

    > For example:


    > # server side
    > /usr/bin/pppd pppd debug notty 192.168.0.6:192.168.07 -detach escape
    > ff asyncmap 00002400


    Twice now you've shown the "server" side as using 192.168.07 as it's
    IP address. I assume you really mean 192.168.0.7.

    > (noauth option in /etc/ppp/options)


    > #client side
    > pppd socket cisco2:5014 -detach lock connect 'chat -v -f
    > /IBERCOM/usr/mgg327/ppp/chat-options' escape ff asyncmap 00002400 debug
    > noauth


    > It works. So... what is the different between using noauth and
    > auth+require-pap options? Why if I use auth+require-pap options PPP
    > could not be bring up?


    One possibility is that with noauth network packets can be sent and
    received without the peer authenticating itself. If the peer is
    required to authenticate itself then authentication may be failing.

    You have the pppd debug and the chat -v options on the "client" and
    a look at the messages these generate might be helpful. Below is a
    recipe for generating a log with those messages.

    Add the line

    daemon.*;local2.* /var/log/ppp.log

    to /etc/syslog.conf, do "killall -HUP syslogd" so syslogd will
    reread that file and then try to establish a connection.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    /* The generation of random numbers is too important to be left
    to chance. */

  8. Re: Loopback when using PAP auth

    "KiKo" writes:

    >But it s a little strange, because if I don't use auth options, ppp
    >works fine.


    >For example:


    ># server side
    > /usr/bin/pppd pppd debug notty 192.168.0.6:192.168.07 -detach escape
    >ff asyncmap 00002400


    >(noauth option in /etc/ppp/options)


    >#client side
    >pppd socket cisco2:5014 -detach lock connect 'chat -v -f
    >/IBERCOM/usr/mgg327/ppp/chat-options' escape ff asyncmap 00002400 debug
    >noauth


    >It works. So... what is the different between using noauth and
    >auth+require-pap options? Why if I use auth+require-pap options PPP
    >could not be bring up?


    On which? Remember that auth means "I demand that the remote machine
    authenticate itself to me." "require-pap" means " I demand that the remote
    machine authenticate itself to me using the pap authentication" Ie, the
    machine that has those will demand that the remote machine authenticate
    itself. If this is on your client, it is highly probably that your server
    is not willing to authenticate itself to your client. Some people think
    these mean that your system is willing to authenticate itself to the remote
    end. That is wrong.


    >:\



  9. Re: Loopback when using PAP auth


    Clifford Kite ha escrito:
    >
    > > For example:

    >
    > > # server side
    > > /usr/bin/pppd pppd debug notty 192.168.0.6:192.168.07 -detach escape
    > > ff asyncmap 00002400

    >
    > Twice now you've shown the "server" side as using 192.168.07 as it's
    > IP address. I assume you really mean 192.168.0.7.


    Yep. It was a typo. I have fixed it using 192.168.0.7, but the problem
    continues.

    >
    > You have the pppd debug and the chat -v options on the "client" and
    > a look at the messages these generate might be helpful. Below is a
    > recipe for generating a log with those messages.


    Log messages:

    ---> Client Side:
    # pppd socket cisco2:5014 -detach lock connect 'chat -v -f
    /IBERCOM/usr/mgg327/ppp/chat-options' debug user EMI_TID_00 escape ff
    asyncmap 00002400
    Using /dev/pts/3; master fd 7, slave fd 8
    pty speed set to 9600 bps
    starting charshunt for socket option
    connect option: 'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options'
    started (pid 25915)
    Serial connection established.
    Using interface sppp0
    Connect: sppp0 <--> /dev/pts/3
    /etc/ppp/pap-secrets is apparently empty
    /etc/ppp/chap-secrets is apparently empty
    sent [LCP ConfReq id=0xe9
    ]
    sent [LCP ConfReq id=0xe9
    ]
    rcvd [LCP ConfReq id=0xe9
    ]
    sent [LCP ConfNak id=0xe9 ]
    rcvd [LCP ConfNak id=0xe9 ]
    sent [LCP ConfReq id=0xea
    ]
    rcvd [LCP ConfReq id=0xea
    ]
    sent [LCP ConfNak id=0xea ]
    rcvd [LCP ConfNak id=0xea ]
    sent [LCP ConfReq id=0xeb
    ]
    rcvd [LCP ConfReq id=0xeb
    ]
    sent [LCP ConfNak id=0xeb ]
    rcvd [LCP ConfNak id=0xeb ]
    sent [LCP ConfReq id=0xec
    ]
    rcvd [LCP ConfReq id=0xec
    ]
    sent [LCP ConfNak id=0xec ]
    rcvd [LCP ConfNak id=0xec ]
    sent [LCP ConfReq id=0xed
    ]
    rcvd [LCP ConfReq id=0xed
    ]
    sent [LCP ConfNak id=0xed ]
    rcvd [LCP ConfNak id=0xed ]
    sent [LCP ConfReq id=0xee
    ]
    rcvd [LCP ConfReq id=0xee
    ]
    sent [LCP ConfNak id=0xee ]
    rcvd [LCP ConfNak id=0xee ]
    sent [LCP ConfReq id=0xef
    ]
    rcvd [LCP ConfReq id=0xef
    ]
    sent [LCP ConfNak id=0xef ]
    rcvd [LCP ConfNak id=0xef ]
    sent [LCP ConfReq id=0xf0
    ]
    rcvd [LCP ConfReq id=0xf0
    ]
    sent [LCP ConfNak id=0xf0 ]
    rcvd [LCP ConfNak id=0xf0 ]
    sent [LCP ConfReq id=0xf1
    ]
    rcvd [LCP ConfReq id=0xf1
    ]
    sent [LCP ConfNak id=0xf1 ]
    rcvd [LCP ConfNak id=0xf1 ]
    sent [LCP ConfReq id=0xf2
    ]
    rcvd [LCP ConfReq id=0xf2
    ]
    sent [LCP ConfNak id=0xf2 ]
    rcvd [LCP ConfNak id=0xf2 ]
    Serial line is looped back.
    sent [LCP TermReq id=0xf3 "Loopback detected"]
    rcvd [LCP TermReq id=0xf3 "Loopback detected"]
    sent [LCP TermAck id=0xf3]
    rcvd [LCP TermAck id=0xf3]
    Connection terminated.
    Waiting for 1 child processes...
    pid 25914: pppd (charshunt)
    select
    Child process pppd (charshunt) finished (pid 25914), status = 1

    Server side has not logs when I use auth option. As I said in a later
    post, ppp can bring up the link if I use 'noauth' options, although
    problems come when I use 'auth+require-pap' options in the server side.

    These are the logs I get when I use 'noauth' option in the server side
    (maybe they can help):

    --->Server side (/usr/bin/pppd debug notty 192.168.0.6:192.168.0.7
    -detach escape ff asyncmap 00002400):
    Using /dev/pts/2; master fd 7, slave fd 8
    pty speed set to 9600 bps
    starting charshunt for notty option
    Using interface sppp0
    Connect: sppp0 <--> /dev/pts/2
    /etc/ppp/chap-secrets is apparently empty
    sent [LCP ConfReq id=0x1c
    ]
    rcvd [LCP ConfReq id=0x53
    ]
    sent [LCP ConfAck id=0x53
    ]
    rcvd [LCP ConfAck id=0x1c
    ]
    sent [LCP Ident id=0x1d magic=0x33ef2fb2 "ppp-2.4.0b1 (Sun
    Microsystems, Inc., Aug 3 2003 18:30:13)"]
    sent [IPCP ConfReq id=0xe6 ]
    sent [CCP ConfReq id=0xa7 ]
    rcvd [LCP Ident id=0x54 magic=0xe206e145 "ppp-2.4.0b1 (Sun
    Microsystems, Inc., Aug 3 2003 18:30:13)"]
    Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Aug 3 2003
    18:30:13)
    rcvd [IPCP ConfReq id=0xe1 ]
    sent [IPCP ConfNak id=0xe1 ]
    rcvd [CCP ConfReq id=0x2a ]
    sent [CCP ConfAck id=0x2a ]
    rcvd [IPCP ConfAck id=0xe6 ]
    rcvd [CCP ConfAck id=0xa7 ]
    Deflate (15) compression enabled
    rcvd [IPCP ConfReq id=0xe2 ]
    sent [IPCP ConfAck id=0xe2 ]
    local IP address 192.168.0.6
    remote IP address 192.168.0.7

    ---> Client side:

    # pppd socket cisco2:5014 -detach lock connect 'chat -v -f
    /IBERCOM/usr/mgg327/ppp/chat-options' debug user EMI_TID_00 escape ff
    asyncmap 00002400
    Using /dev/pts/3; master fd 7, slave fd 8
    pty speed set to 9600 bps
    starting charshunt for socket option
    connect option: 'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options'
    started (pid 28821)
    Serial connection established.
    Using interface sppp0
    Connect: sppp0 <--> /dev/pts/3
    /etc/ppp/pap-secrets is apparently empty
    /etc/ppp/chap-secrets is apparently empty
    sent [LCP ConfReq id=0x53
    ]
    rcvd [LCP ConfReq id=0x1c
    ]
    sent [LCP ConfAck id=0x1c
    ]
    rcvd [LCP ConfAck id=0x53
    ]
    sent [LCP Ident id=0x54 magic=0xe206e145 "ppp-2.4.0b1 (Sun
    Microsystems, Inc., Aug 3 2003 18:30:13)"]
    sent [IPCP ConfReq id=0xe1 ]
    sent [CCP ConfReq id=0x2a ]
    rcvd [LCP Ident id=0x1d magic=0x33ef2fb2 "ppp-2.4.0b1 (Sun
    Microsystems, Inc., Aug 3 2003 18:30:13)"]
    Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Aug 3 2003
    18:30:13)
    rcvd [IPCP ConfReq id=0xe6 ]
    sent [IPCP ConfAck id=0xe6 ]
    rcvd [CCP ConfReq id=0xa7 ]
    sent [CCP ConfAck id=0xa7 ]
    rcvd [IPCP ConfNak id=0xe1 ]
    sent [IPCP ConfReq id=0xe2 ]
    rcvd [CCP ConfAck id=0x2a ]
    Deflate (15) compression enabled
    rcvd [IPCP ConfAck id=0xe2 ]
    local IP address 192.168.0.7
    remote IP address 192.168.0.6

    And the link is up:

    $ ifconfig -a
    sppp0: flags=10008d1 mtu
    1500 index 40
    inet 192.168.0.7 --> 192.168.0.6 netmask ffffff00


    >
    > Add the line
    >
    > daemon.*;local2.* /var/log/ppp.log
    >
    > to /etc/syslog.conf, do "killall -HUP syslogd" so syslogd will
    > reread that file and then try to establish a connection.
    >
    > --
    > Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    > /* The generation of random numbers is too important to be left
    > to chance. */



  10. Re: Loopback when using PAP auth

    "KiKo" writes:
    > sent [LCP ConfReq id=0xe9
    > ]
    > sent [LCP ConfReq id=0xe9
    > ]
    > rcvd [LCP ConfReq id=0xe9
    > ]
    > sent [LCP ConfNak id=0xe9 ]
    > rcvd [LCP ConfNak id=0xe9 ]


    This is evidence that you're talking to yourself. This is a problem
    on the link itself. Most likely, the modem is left in command mode
    due to a failure of that chat script.

    This has nothing to do with the pppd configuration options. It has
    nothing to do with PPP. Changing the pppd configuration options won't
    (and can't) fix this problem.

    Look at the logs for the chat session. (These are in
    /etc/ppp/connect-errors if you are running pppd detached.)

    --
    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: Loopback when using PAP auth

    See messges below.


    "KiKo" writes:


    >Clifford Kite ha escrito:
    >>
    >> > For example:

    >>
    >> > # server side
    >> > /usr/bin/pppd pppd debug notty 192.168.0.6:192.168.07 -detach escape
    >> > ff asyncmap 00002400

    >>
    >> Twice now you've shown the "server" side as using 192.168.07 as it's
    >> IP address. I assume you really mean 192.168.0.7.


    >Yep. It was a typo. I have fixed it using 192.168.0.7, but the problem
    >continues.


    >>
    >> You have the pppd debug and the chat -v options on the "client" and
    >> a look at the messages these generate might be helpful. Below is a
    >> recipe for generating a log with those messages.


    >Log messages:


    No they are not what was requested.

    We have no idea what is in /IBERCOM/usr/mgg327/ppp/chat-options
    Nor can we see the chat negotiations with your modem.




    >---> Client Side:
    ># pppd socket cisco2:5014 -detach lock connect 'chat -v -f
    >/IBERCOM/usr/mgg327/ppp/chat-options' debug user EMI_TID_00 escape ff
    >asyncmap 00002400
    >Using /dev/pts/3; master fd 7, slave fd 8
    >pty speed set to 9600 bps
    >starting charshunt for socket option
    >connect option: 'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options'
    >started (pid 25915)
    >Serial connection established.
    >Using interface sppp0
    >Connect: sppp0 <--> /dev/pts/3
    >/etc/ppp/pap-secrets is apparently empty
    >/etc/ppp/chap-secrets is apparently empty
    >sent [LCP ConfReq id=0xe9
    >]
    >sent [LCP ConfReq id=0xe9
    >]


    You are talking to yourself. See the Magic number in the next received
    line and compare to the magic number in the previous line.

    Note that you did NOT do as requested, namely place
    local2.*;daemon.* /var/log/ppplog
    into /etc/sysconfig.conf
    and then do
    killall -1 syslogd
    ( assuming your system is similar to linux) Ie, we do not have the output
    of the chat logs.


    >rcvd [LCP ConfReq id=0xe9
    >]


    >Server side has not logs when I use auth option. As I said in a later
    >post, ppp can bring up the link if I use 'noauth' options, although
    >problems come when I use 'auth+require-pap' options in the server side.


    >These are the logs I get when I use 'noauth' option in the server side
    >(maybe they can help):


    >--->Server side (/usr/bin/pppd debug notty 192.168.0.6:192.168.0.7
    >-detach escape ff asyncmap 00002400):
    >Using /dev/pts/2; master fd 7, slave fd 8
    >pty speed set to 9600 bps
    >starting charshunt for notty option
    >Using interface sppp0
    >Connect: sppp0 <--> /dev/pts/2
    >/etc/ppp/chap-secrets is apparently empty
    >sent [LCP ConfReq id=0x1c
    >]


    Now you are connected. See the magic is different.
    Also you are doing something different. I see no mention of chat above. Ie,
    it is NOT just noauth that is the problem. The two connection attempts
    differ in other areas.


    >rcvd [LCP ConfReq id=0x53
    >]



    ># pppd socket cisco2:5014 -detach lock connect 'chat -v -f
    >/IBERCOM/usr/mgg327/ppp/chat-options' debug user EMI_TID_00 escape ff
    >asyncmap 00002400
    >Using /dev/pts/3; master fd 7, slave fd 8
    >pty speed set to 9600 bps
    >starting charshunt for socket option
    >connect option: 'chat -v -f /IBERCOM/usr/mgg327/ppp/chat-options'


    No idea what you have in /IBERCOM/usr/mgg327/ppp/chat-options

    >started (pid 28821)
    >Serial connection established.
    >Using interface sppp0
    >Connect: sppp0 <--> /dev/pts/3
    >/etc/ppp/pap-secrets is apparently empty
    >/etc/ppp/chap-secrets is apparently empty
    >sent [LCP ConfReq id=0x53
    >]
    >rcvd [LCP ConfReq id=0x1c
    >]
    >sent [LCP ConfAck id=0x1c
    >]
    >rcvd [LCP ConfAck id=0x53
    >]
    >sent [LCP Ident id=0x54 magic=0xe206e145 "ppp-2.4.0b1 (Sun
    >Microsystems, Inc., Aug 3 2003 18:30:13)"]
    >sent [IPCP ConfReq id=0xe1 ]
    >sent [CCP ConfReq id=0x2a ]
    >rcvd [LCP Ident id=0x1d magic=0x33ef2fb2 "ppp-2.4.0b1 (Sun
    >Microsystems, Inc., Aug 3 2003 18:30:13)"]
    >Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Aug 3 2003
    >18:30:13)
    >rcvd [IPCP ConfReq id=0xe6 ]
    >sent [IPCP ConfAck id=0xe6 ]
    >rcvd [CCP ConfReq id=0xa7 ]
    >sent [CCP ConfAck id=0xa7 ]
    >rcvd [IPCP ConfNak id=0xe1 ]
    >sent [IPCP ConfReq id=0xe2 ]
    >rcvd [CCP ConfAck id=0x2a ]
    >Deflate (15) compression enabled
    >rcvd [IPCP ConfAck id=0xe2 ]
    >local IP address 192.168.0.7
    >remote IP address 192.168.0.6


    >And the link is up:


    >$ ifconfig -a
    >sppp0: flags=10008d1 mtu
    >1500 index 40
    > inet 192.168.0.7 --> 192.168.0.6 netmask ffffff00



    >>
    >> Add the line
    >>
    >> daemon.*;local2.* /var/log/ppp.log


    And you never did this. Why not? Why do you make it hard for us to help
    you?


    >>
    >> to /etc/syslog.conf, do "killall -HUP syslogd" so syslogd will
    >> reread that file and then try to establish a connection.
    >>
    >> --
    >> Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    >> /* The generation of random numbers is too important to be left
    >> to chance. */



  12. Re: Loopback when using PAP auth

    Sorry, I forgot to add that line in the syslog.conf file ^_^U

    First of all, this is the char file I use in the client:

    $ cat chat-options
    ABORT "NO CARRIER"
    ABORT "BUSY"
    ABORT "NO DIALTONE"
    ABORT "NO ANSWER"
    TIMEOUT 2
    '' ''
    '' AT
    OK-AT-OK ATZ
    OK-ATZ-OK ATE0
    OK-ATE0-OK ''
    TIMEOUT 120
    '' ATDT913983691
    CONNECT ''


    And this is the log I received:

    Nov 29 14:59:05 hobbit pppd[285]: [ID 860527 daemon.notice] pppd
    2.4.0b1 (Sun Microsystems, Inc., Aug 3 2003 18:30:14) started by
    mgg327, uid 0
    Nov 29 14:59:05 hobbit pppd[285]: [ID 860527 daemon.notice] pppd
    2.4.0b1 (Sun Microsystems, Inc., Aug 3 2003 18:30:14) started by
    mgg327, uid 0
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] abort on (NO
    CARRIER)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] abort on
    (BUSY)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] abort on (NO
    DIALTONE)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] abort on (NO
    ANSWER)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] timeout set
    to 2 seconds
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] send (^M)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] send (AT^M)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] expect (OK)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] ^MAT^M^M
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] OK
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] -- got it
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] send (ATZ^M)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] expect (OK)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] ^M
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] ATZ^M^M
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] OK
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] -- got it
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] send (ATE0^M)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] expect (OK)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] ^M
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] ATE0^M^M
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] OK
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] -- got it
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] send (^M)
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] timeout set
    to 120 seconds
    Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] send
    (ATDT913983691^M)
    Nov 29 14:59:06 hobbit chat[289]: [ID 702911 local2.info] expect
    (CONNECT)
    Nov 29 14:59:06 hobbit chat[289]: [ID 702911 local2.info] ^M
    Nov 29 14:59:22 hobbit last message repeated 1 time
    Nov 29 14:59:22 hobbit chat[289]: [ID 702911 local2.info] CONNECT
    Nov 29 14:59:22 hobbit chat[289]: [ID 702911 local2.info] -- got it
    Nov 29 14:59:22 hobbit chat[289]: [ID 702911 local2.info] send (^M)
    Nov 29 14:59:22 hobbit pppd[285]: [ID 702911 daemon.info] Serial
    connection established.
    Nov 29 14:59:22 hobbit pppd[285]: [ID 702911 daemon.info] Using
    interface sppp0
    Nov 29 14:59:22 hobbit pppd[285]: [ID 702911 daemon.notice] Connect:
    sppp0 <--> /dev/pts/10
    Nov 29 14:59:22 hobbit pppd[285]: [ID 702911 daemon.notice] Connect:
    sppp0 <--> /dev/pts/10
    Nov 29 14:59:26 hobbit spppasyn: [ID 268290 kern.notice] sppp0: bad fcs
    (len=101)
    Nov 29 14:59:26 hobbit spppasyn: [ID 268290 kern.notice] sppp0: bad fcs
    (len=101)
    Nov 29 14:59:27 hobbit pppd[285]: [ID 702911 daemon.notice] Serial line
    is looped back.
    Nov 29 14:59:27 hobbit pppd[285]: [ID 702911 daemon.notice] Serial line
    is looped back.
    Nov 29 14:59:27 hobbit pppd[285]: [ID 702911 daemon.notice] Connection
    terminated.
    Nov 29 14:59:27 hobbit pppd[285]: [ID 702911 daemon.notice] Connection
    terminated.
    Nov 29 14:59:27 hobbit pppd[287]: [ID 702911 daemon.error] select
    Nov 29 14:59:27 hobbit pppd[287]: [ID 702911 daemon.error] select
    Nov 29 14:59:27 hobbit pppd[287]: [ID 702911 daemon.error] select
    Nov 29 14:59:27 hobbit pppd[287]: [ID 834084 daemon.info] Exit.
    Nov 29 14:59:27 hobbit pppd[285]: [ID 834084 daemon.info] Exit.

    It seems that a bad frame is received (fcs error).


  13. Re: Loopback when using PAP auth

    "KiKo" writes:
    > '' ATDT913983691
    > CONNECT ''


    Try '\c' instead there.

    > Nov 29 14:59:22 hobbit pppd[285]: [ID 702911 daemon.notice] Connect:
    > sppp0 <--> /dev/pts/10
    > Nov 29 14:59:26 hobbit spppasyn: [ID 268290 kern.notice] sppp0: bad fcs
    > (len=101)
    > Nov 29 14:59:26 hobbit spppasyn: [ID 268290 kern.notice] sppp0: bad fcs
    > (len=101)
    > Nov 29 14:59:27 hobbit pppd[285]: [ID 702911 daemon.notice] Serial line
    > is looped back.

    [...]
    > It seems that a bad frame is received (fcs error).


    Though that's true, that's not the real problem here. The real
    problem is that you're talking to yourself. The most likely cause is
    the spurious carriage return sent out after receiving the CONNECT
    message from the modem.

    On some brands of modems, and with just the right timing, that can
    cause the modem to drop back to command mode.

    In other cases, that can cause the peer to _assume_ that you don't
    speak PPP, and instead present you with a text-mode "login:" prompt.

    Either way, the symptoms are the same: you get back the same bytes you
    send (either echoed by the modem itself or by the remote peer, either
    of which "thinks" it's echoing a human's keystrokes), and that causes
    the failure.

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

  14. Re: Loopback when using PAP auth

    "KiKo" writes:

    >Sorry, I forgot to add that line in the syslog.conf file ^_^U


    OK, now that we see your chat file there are all kinds of things wrong with
    it.


    >First of all, this is the char file I use in the client:


    >$ cat chat-options
    >ABORT "NO CARRIER"
    >ABORT "BUSY"
    >ABORT "NO DIALTONE"
    >ABORT "NO ANSWER"
    >TIMEOUT 2
    >'' ''
    >'' AT


    Do NOT use ATZ. That leaves your modem in a completely unkown state, and
    often a completely crazy state. Use AT&F (or AT&F1 on a Sportster modem. --
    read your modem manual and use the one which sets up harware RTS-CTS flow
    control)

    >OK-AT-OK ATZ


    Also why which OK-AT-OK stuff?
    If your modem does not answer OK the first time it is highly highly
    unlikely to answer OK the second time.
    >OK-ATZ-OK ATE0


    Again, ATZ is wrong.

    >OK-ATE0-OK ''
    >TIMEOUT 120
    >'' ATDT913983691
    >CONNECT ''


    And this line is almost certainly the cause of your problem. You send a
    carriage return after CONNECT. That carriage return is almost always
    interpreted by teh remote end to requireing a logon-password type logon and
    then dumping you into hell.
    The corrct form is
    CONNECT '\d\c'
    which does NOT send a carriage return.





    >And this is the log I received:


    ....
    >Nov 29 14:59:05 hobbit chat[289]: [ID 702911 local2.info] send
    >(ATDT913983691^M)
    >Nov 29 14:59:06 hobbit chat[289]: [ID 702911 local2.info] expect
    >(CONNECT)
    >Nov 29 14:59:06 hobbit chat[289]: [ID 702911 local2.info] ^M
    >Nov 29 14:59:22 hobbit last message repeated 1 time
    >Nov 29 14:59:22 hobbit chat[289]: [ID 702911 local2.info] CONNECT
    >Nov 29 14:59:22 hobbit chat[289]: [ID 702911 local2.info] -- got it
    >Nov 29 14:59:22 hobbit chat[289]: [ID 702911 local2.info] send (^M)



    You see. You send a carriage return ^M. That is a nono.




  15. Re: Loopback when using PAP auth

    Unruh writes:
    > >OK-AT-OK ATZ

    >
    > Also why which OK-AT-OK stuff?
    > If your modem does not answer OK the first time it is highly highly
    > unlikely to answer OK the second time.


    You never know. If there was garbage in the modem's input buffer from
    the last call, then OK-AT-OK will help clear it out and get sync back
    without failing.

    It's potentially helpful, and I can see nothing actually harmful about
    it. (Unlike ATZ ...)

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

+ Reply to Thread