pap-secrets and firewall - PPP

This is a discussion on pap-secrets and firewall - PPP ; If a server (dial-in) is behind a firewall, how does that affect pap-secrets? I had a program that called a server that was not behind a firewall and did not need authenticaion; and i was able to dial up from ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: pap-secrets and firewall

  1. pap-secrets and firewall

    If a server (dial-in) is behind a firewall, how does that affect
    pap-secrets?
    I had a program that called a server that was not behind a firewall
    and did not need authenticaion; and i was able to dial up from my
    program to the server with no problem. Then the server was moved
    behind a firewall and since then i have had problems running the
    program, even when i try it manually i still have problems with
    authentication, i am sure i am doing something incorrectly but want to
    make sure the firewall issue is not an issue in the first place.
    After the dial-up was moved behind the firewall, i started receiving
    errors about authentication so i added pap-secrets to both the server
    and the client, but i still get errors about authentication.
    Basically the message is "Login incorrect" and "Failed to authenticate
    ourselves to peer." I am not posting the log messages at this time
    because i just would like to know what is the effect of a server being
    located behind a firewall, and since i am trying both manually and via
    the program, i don't want to confuse the issu. Hope this is clear
    enough.

  2. Re: pap-secrets and firewall

    jtcoelho@mail.pt (joao coelho) writes:
    > If a server (dial-in) is behind a firewall, how does that affect
    > pap-secrets?


    It doesn't.

    It might affect the way IP addresses are assigned, and these can be
    assigned by a number of different means (including options files and
    *-secrets files).

    > I had a program that called a server that was not behind a firewall
    > and did not need authenticaion; and i was able to dial up from my
    > program to the server with no problem. Then the server was moved
    > behind a firewall and since then i have had problems running the
    > program, even when i try it manually i still have problems with
    > authentication, i am sure i am doing something incorrectly but want to
    > make sure the firewall issue is not an issue in the first place.


    You're possibly running into the fact that pppd will demand
    authentication by default if the system has a default route. Use
    "noauth" if that's not what you want.

    > After the dial-up was moved behind the firewall, i started receiving
    > errors about authentication so i added pap-secrets to both the server
    > and the client, but i still get errors about authentication.
    > Basically the message is "Login incorrect" and "Failed to authenticate
    > ourselves to peer."


    That sounds like a bad user name or password -- that has nothing to do
    with any firewall.

    > I am not posting the log messages at this time
    > because i just would like to know what is the effect of a server being
    > located behind a firewall, and since i am trying both manually and via
    > the program, i don't want to confuse the issu. Hope this is clear
    > enough.


    It certainly confuses the issue if nobody is able to see the
    messages. Next time, please include details in your posting.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: pap-secrets and firewall

    Here is the output i am getting from the dial-up side (client) nothing
    from the dial-in. It looks like i am in some kind of loop. I am
    using the /usr/bin/pppd shell for the ppp user.
    Feb 17 07:03:53 cacdf1 pppd[704]: [ID 860527 daemon.notice] pppd
    2.4.0b1 (Sun Microsystems, Inc., Nov 4 2002 02:10:28) started by
    root, uid 0
    Feb 17 07:03:53 cacdf1 pppd[704]: [ID 702911 daemon.debug] serial
    speed set to 38400 bps
    Feb 17 07:03:54 cacdf1 pppd[704]: [ID 702911 daemon.debug] connect
    option: 'chat -v "" "AT&F1" OK ATDT8889999 CONNECT \c ogin: login
    assword: password SAY "enterying password
    Feb 17 07:03:54 cacdf1 " "" "exec pppd" \c' started (pid 705)
    Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] send
    (AT&F1^M)
    Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] expect (OK)
    Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] AT&F1^M^M
    Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] OK
    Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] send
    (ATDT888999^M)
    Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] expect
    (CONNECT)
    Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] ^M
    Feb 17 07:04:02 cacdf1 chat[706]: [ID 702911 local2.info]
    ATDT888999^M^M
    Feb 17 07:04:02 cacdf1 chat[706]: [ID 702911 local2.info] RINGING^M
    Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] ^M
    Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] CONNECT
    Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] send (c^M)
    Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] expect
    (ogin
    Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info]
    33600/ARQ/V34/LAPM/V42BIS^M
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] ^M^M
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] login:
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] send
    (login^M)
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] expect
    (assword
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] c^M
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] Password:
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] send
    (password^M)
    Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] send (exec
    pppd^M)
    Feb 17 07:04:17 cacdf1 chat[706]: [ID 702911 local2.info] expect (c)
    Feb 17 07:04:17 cacdf1 chat[706]: [ID 702911 local2.info] c
    Feb 17 07:04:17 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    Feb 17 07:04:17 cacdf1 pppd[704]: [ID 702911 daemon.info] Serial
    connection established.
    Feb 17 07:04:17 cacdf1 pppd[704]: [ID 702911 daemon.debug] serial
    speed set to 38400 bps
    Feb 17 07:04:17 cacdf1 pppd[704]: [ID 702911 daemon.info] Using
    interface sppp0
    Feb 17 07:04:17 cacdf1 pppd[704]: [ID 702911 daemon.notice] Connect:
    sppp0 <--> /dev/cua/b
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug]
    /etc/ppp/chap-secrets is apparently empty
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0xe3
    ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0xe3
    ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfNak id=0xe3 ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    ConfNak id=0xe3 ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0xe4
    ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0xe4
    ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfNak id=0xe4 ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    ConfNak id=0xe4 ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0xe5
    ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0xe5
    ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfNak id=0xe5 ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    ConfNak id=0xe5 ]
    Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0xe6
    ]
    Feb 17 07:04:19 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0xe6
    ]
    Feb 17 07:04:19 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfNak id=0xe6 ]
    Feb 17 07:04:21 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0xe6
    ]
    Feb 17 07:04:45 cacdf1 last message repeated 8 times
    Feb 17 07:04:48 cacdf1 pppd[704]: [ID 702911 daemon.warning] LCP:
    timeout sending Config-Requests
    Feb 17 07:04:48 cacdf1 pppd[704]: [ID 702911 daemon.notice] Connection
    terminated.
    Feb 17 07:04:50 cacdf1 pppd[704]: [ID 834084 daemon.info] Exit.

    Here is the code i use to set up the options and the chat script in my
    code, then i just call system...
    sprintf(options,"%s %s%s%s %s %s %s ","38400 debug updetach asyncmap
    0x40000 noipdefault noauth noccp
    ",IpAddresses[nodeval-1].ppp_local_ip,":",IpAddresses[nodeval-1].ppp_remote_ip,"user",account,"connect");



    sprintf(chatstr,"%s%s %s %s %s %s %s %s %s","'chat -v \"\" \"AT&F1\"
    OK ATDT",phone," CONNECT \\c ","ogin:",account," assword:
    ",passwd,"SAY \"enterying password\n\" "," \"\" \"exec pppd\" \\c'
    ");


    sprintf(buffer,"%s %s %s %s 2>&1","pppd ",port, options,chatstr);
    printf("%s\n",buffer);
    if (system(buffer) != 0)

  4. Re: pap-secrets and firewall

    joao coelho wrote:
    > Here is the output i am getting from the dial-up side (client) nothing
    > from the dial-in. It looks like i am in some kind of loop. I am
    > using the /usr/bin/pppd shell for the ppp user.
    > Feb 17 07:03:53 cacdf1 pppd[704]: [ID 860527 daemon.notice] pppd
    > 2.4.0b1 (Sun Microsystems, Inc., Nov 4 2002 02:10:28) started by
    > root, uid 0
    > Feb 17 07:03:53 cacdf1 pppd[704]: [ID 702911 daemon.debug] serial
    > speed set to 38400 bps
    > Feb 17 07:03:54 cacdf1 pppd[704]: [ID 702911 daemon.debug] connect
    > option: 'chat -v "" "AT&F1" OK ATDT8889999 CONNECT \c ogin: login
    > assword: password SAY "enterying password
    > Feb 17 07:03:54 cacdf1 " "" "exec pppd" \c' started (pid 705)
    > Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] send
    > (AT&F1^M)
    > Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] expect (OK)
    > Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] AT&F1^M^M
    > Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] OK
    > Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    > Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] send
    > (ATDT888999^M)
    > Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] expect
    > (CONNECT)
    > Feb 17 07:03:54 cacdf1 chat[706]: [ID 702911 local2.info] ^M
    > Feb 17 07:04:02 cacdf1 chat[706]: [ID 702911 local2.info]
    > ATDT888999^M^M
    > Feb 17 07:04:02 cacdf1 chat[706]: [ID 702911 local2.info] RINGING^M
    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] ^M
    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] CONNECT
    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] send (c^M)


    You likely need to have 3 escapes, \\\c, in the argument of the function
    for this send.

    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] expect
    > (ogin
    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info]
    > 33600/ARQ/V34/LAPM/V42BIS^M
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] ^M^M
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] login:
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] send
    > (login^M)
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] expect
    > (assword
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] c^M


    Using \c (or \\\c in this case) as an expect is not valid. See man
    chat. I rather doubt that you need to expect anything at this point,
    just remove the last \\c.

    You probably didn't get logged in and the "loop" is caused by a prompt
    echoing what you send.
    ....

    > Here is the code i use to set up the options and the chat script in my
    > code, then i just call system...
    > sprintf(options,"%s %s%s%s %s %s %s ","38400 debug updetach asyncmap
    > 0x40000 noipdefault noauth noccp
    > ",IpAddresses[nodeval-1].ppp_local_ip,":",IpAddresses[nodeval-1].ppp_remote_ip,"user",account,"connect");


    > sprintf(chatstr,"%s%s %s %s %s %s %s %s %s","'chat -v \"\" \"AT&F1\"
    > OK ATDT",phone," CONNECT \\c ","ogin:",account," assword:
    > ",passwd,"SAY \"enterying password\n\" "," \"\" \"exec pppd\" \\c'
    > ");


    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Those who can't write, write manuals. */

  5. Re: pap-secrets and firewall

    jtcoelho@mail.pt (joao coelho) writes:
    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] CONNECT
    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    > Feb 17 07:04:15 cacdf1 chat[706]: [ID 702911 local2.info] send (c^M)


    Oops. Minor problem (see below).

    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] send (exec
    > pppd^M)
    > Feb 17 07:04:17 cacdf1 chat[706]: [ID 702911 local2.info] expect (c)
    > Feb 17 07:04:17 cacdf1 chat[706]: [ID 702911 local2.info] c
    > Feb 17 07:04:17 cacdf1 chat[706]: [ID 702911 local2.info] -- got it


    Another oops.

    > Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    > ConfReq id=0xe3
    > ]
    > Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    > ConfReq id=0xe3
    > ]


    You're talking to yourself. The peer is not running PPP because the
    chat script is failing.

    > Here is the code i use to set up the options and the chat script in my
    > code, then i just call system...
    > sprintf(options,"%s %s%s%s %s %s %s ","38400 debug updetach asyncmap
    > 0x40000 noipdefault noauth noccp
    > ",IpAddresses[nodeval-1].ppp_local_ip,":",IpAddresses[nodeval-1].ppp_remote_ip,"user",account,"connect");


    OK.

    > sprintf(chatstr,"%s%s %s %s %s %s %s %s %s","'chat -v \"\" \"AT&F1\"
    > OK ATDT",phone," CONNECT \\c ","ogin:",account," assword:
    > ",passwd,"SAY \"enterying password\n\" "," \"\" \"exec pppd\" \\c'
    > ");


    That looks garbled to me. Here are the problems I see:

    - The 'exec pppd' string isn't waiting for anything before
    being sent (the preceding string is just ""), so it spews
    out to the peer before a shell prompt is ever seen. I think
    I remarked on this problem in a previous posting.

    - The "\c" bits are malformed. I think you want something
    like '\\c' instead, so that '\c' is passed to the shell.

    - The final "\\c" makes no sense. Why would this script wait
    for \c from the peer? \c makes sense only in the 'send'
    portion of the expect-send pairing, not in the 'expect'
    part. See the chat man page for details.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  6. Re: pap-secrets and firewall

    jtcoelho@mail.pt (joao coelho) writes:

    ]Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    ]ConfReq id=0xe3
    ]]
    ]Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    ]ConfReq id=0xe3
    ]]

    Note that the magic is the same. You are talking to yourself. the far
    end is simply reflecting back what you sent. This is very typical
    behaviour if you log in when you are not supposed to log in.

    See
    www.theory.physics.ubc.ca/ppp-linux.html for a step by step instructions
    for figuring out and debugging what your isp wants.


  7. Re: pap-secrets and firewall

    Clifford Kite wrote:
    > James Carlson wrote:


    >>> sprintf(chatstr,"%s%s %s %s %s %s %s %s %s","'chat -v \"\" \"AT&F1\"
    >>> OK ATDT",phone," CONNECT \\c ","ogin:",account," assword:
    >>> ",passwd,"SAY \"enterying password\n\" "," \"\" \"exec pppd\" \\c'
    >>> ");


    >> That looks garbled to me. Here are the problems I see:


    >> - The 'exec pppd' string isn't waiting for anything before
    >> being sent (the preceding string is just ""), so it spews
    >> out to the peer before a shell prompt is ever seen. I think
    >> I remarked on this problem in a previous posting.


    > Sure it did:


    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] Password:
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] -- got it
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] send
    > (password^M)
    > Feb 17 07:04:16 cacdf1 chat[706]: [ID 702911 local2.info] send (exec
    > pppd^M)


    Oops, my bad! You're right, it has send the password, but doesn't wait
    for the prompt before sending "exec pppd." Somehow I managed (mangled?)
    to read that as not sending a password.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

  8. Re: pap-secrets and firewall

    I want to thank all of you who have tried to help. I have finally
    resorted to just using the scripts i had and do a system call to the
    script with the parameters i need. The scripts work, i just wanted to
    avoid having scripts all over when i could just put it all in one long
    - albeit confusing - string in my program. However, i am still very
    much interested in figuring it out how i can send the whole thing in a
    string and do the call from a program instead of scripts. It might
    come handy later anyway. again thanks you all.
    unruh@string.physics.ubc.ca (Bill Unruh) wrote in message news:...
    > jtcoelho@mail.pt (joao coelho) writes:
    >
    > ]Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    > ]ConfReq id=0xe3
    > ]]
    > ]Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    > ]ConfReq id=0xe3
    > ]]
    >
    > Note that the magic is the same. You are talking to yourself. the far
    > end is simply reflecting back what you sent. This is very typical
    > behaviour if you log in when you are not supposed to log in.
    >
    > See
    > www.theory.physics.ubc.ca/ppp-linux.html for a step by step instructions
    > for figuring out and debugging what your isp wants.


  9. Re: pap-secrets and firewall

    > > sprintf(chatstr,"%s%s %s %s %s %s %s %s %s","'chat -v \"\" \"AT&F1\"
    > > OK ATDT",phone," CONNECT \\c ","ogin:",account," assword:
    > > ",passwd,"SAY \"enterying password\n\" "," \"\" \"exec pppd\" \\c'
    > > ");

    >
    > That looks garbled to me. Here are the problems I see:
    >
    > - The 'exec pppd' string isn't waiting for anything before
    > being sent (the preceding string is just ""), so it spews
    > out to the peer before a shell prompt is ever seen. I think
    > I remarked on this problem in a previous posting.


    Yes you did, but since the shell is /usr/bin/pppd, what kind of prompt
    should i wait for then ? I tried ~ and that seems not work, although
    i could have it malformed.

    > - The "\c" bits are malformed. I think you want something
    > like '\\c' instead, so that '\c' is passed to the shell.

    I thought i had it formatted that way. with \\c.
    > - The final "\\c" makes no sense. Why would this script wait
    > for \c from the peer? \c makes sense only in the 'send'
    > portion of the expect-send pairing, not in the 'expect'
    > part. See the chat man page for details.

    You are right, i saw this in an example but it had a tilda for the
    expect part. Is it necessary, or should i just chuck it after the exec
    pppd ? In other words, no tilda and no \c line for expect and send. ?
    Again thanks to you all. I read somewhere in the Andrew Sun's book
    that long strings like this become confusing. Man was he right.

  10. Re: pap-secrets and firewall

    jtcoelho@mail.pt (joao coelho) writes:
    > > That looks garbled to me. Here are the problems I see:
    > >
    > > - The 'exec pppd' string isn't waiting for anything before
    > > being sent (the preceding string is just ""), so it spews
    > > out to the peer before a shell prompt is ever seen. I think
    > > I remarked on this problem in a previous posting.

    >
    > Yes you did, but since the shell is /usr/bin/pppd, what kind of prompt
    > should i wait for then ? I tried ~ and that seems not work, although
    > i could have it malformed.


    If the shell is actually /usr/bin/pppd, then there's no point in
    sending "exec pppd" -- pppd doesn't accept plain old text commands.
    The script should just look something like this:

    "" AT&F1 OK ATDT555-1212 ogin: user word: pass

    The chat script should end once the peer is known to be running PPP.

    > > - The final "\\c" makes no sense. Why would this script wait
    > > for \c from the peer? \c makes sense only in the 'send'
    > > portion of the expect-send pairing, not in the 'expect'
    > > part. See the chat man page for details.

    > You are right, i saw this in an example but it had a tilda for the
    > expect part. Is it necessary, or should i just chuck it after the exec
    > pppd ? In other words, no tilda and no \c line for expect and send. ?
    > Again thanks to you all. I read somewhere in the Andrew Sun's book
    > that long strings like this become confusing. Man was he right.


    You shouldn't have to wait for ~ from the peer to proceed.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  11. Re: pap-secrets and firewall

    jtcoelho@mail.pt (joao coelho) writes:

    ]> > sprintf(chatstr,"%s%s %s %s %s %s %s %s %s","'chat -v \"\" \"AT&F1\"
    ]> > OK ATDT",phone," CONNECT \\c ","ogin:",account," assword:
    ]> > ",passwd,"SAY \"enterying password\n\" "," \"\" \"exec pppd\" \\c'
    ]> > ");
    ]>
    ]> That looks garbled to me. Here are the problems I see:
    ]>
    ]> - The 'exec pppd' string isn't waiting for anything before
    ]> being sent (the preceding string is just ""), so it spews
    ]> out to the peer before a shell prompt is ever seen. I think
    ]> I remarked on this problem in a previous posting.

    ]Yes you did, but since the shell is /usr/bin/pppd, what kind of prompt
    ]should i wait for then ? I tried ~ and that seems not work, although
    ]i could have it malformed.

    ]> - The "\c" bits are malformed. I think you want something
    ]> like '\\c' instead, so that '\c' is passed to the shell.
    ]I thought i had it formatted that way. with \\c.
    ]> - The final "\\c" makes no sense. Why would this script wait
    ]> for \c from the peer? \c makes sense only in the 'send'
    ]> portion of the expect-send pairing, not in the 'expect'
    ]> part. See the chat man page for details.
    ]You are right, i saw this in an example but it had a tilda for the
    ]expect part. Is it necessary, or should i just chuck it after the exec
    ]pppd ? In other words, no tilda and no \c line for expect and send. ?
    ]Again thanks to you all. I read somewhere in the Andrew Sun's book
    ]that long strings like this become confusing. Man was he right

    Yes, format them into a file with
    expect send
    on each line.

    But \c means Do not send a carriage return. That hardly makes any sense
    anywhere but at the very end of the negotiation. It is not something
    that is sent, it is something that is NOT sent.

    YOu might want to look at www.theory.physics.ubc.ca/ppp-linux.html for
    debugging help.



  12. Re: pap-secrets and firewall

    To all of you who have put your ideas and effort in helping out. I
    finally got to get my chat script to work within a c program within
    one string. James you were right. The \c was malformed. Thanks you
    all.
    unruh@string.physics.ubc.ca (Bill Unruh) wrote in message news:...
    > jtcoelho@mail.pt (joao coelho) writes:
    >
    > ]Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] sent [LCP
    > ]ConfReq id=0xe3
    > ]]
    > ]Feb 17 07:04:18 cacdf1 pppd[704]: [ID 702911 daemon.debug] rcvd [LCP
    > ]ConfReq id=0xe3
    > ]]
    >
    > Note that the magic is the same. You are talking to yourself. the far
    > end is simply reflecting back what you sent. This is very typical
    > behaviour if you log in when you are not supposed to log in.
    >
    > See
    > www.theory.physics.ubc.ca/ppp-linux.html for a step by step instructions
    > for figuring out and debugging what your isp wants.


+ Reply to Thread