need to interpret LCPs, then set pppd options - PPP

This is a discussion on need to interpret LCPs, then set pppd options - PPP ; Hi, Can someone interpret the LCP dialog and tell me what the deal is with not getting a local and a remote IP from the negotiation? tj@spudbox5:~> grep -v ^# /etc/ppp/options | grep -v ^$ debug noauth crtscts lock modem ...

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

Thread: need to interpret LCPs, then set pppd options

  1. need to interpret LCPs, then set pppd options

    Hi,
    Can someone interpret the LCP dialog and tell me what the deal is with not
    getting a local and a remote IP from the negotiation?


    tj@spudbox5:~> grep -v ^# /etc/ppp/options | grep -v ^$

    debug
    noauth
    crtscts
    lock
    modem
    asyncmap 0
    nodetach
    lcp-echo-interval 30
    lcp-echo-failure 4
    lcp-max-configure 60
    lcp-restart 2
    idle 600
    noipx



    # pppd /dev/modem 57600 defaultroute novj noipdefault ipcp-accept-local

    Perms of /dev/modem are ok, no 'mesg n' neccesary.
    using channel 5
    Using interface ppp0
    Connect: ppp0 <--> /dev/modem
    sent [LCP ConfReq id=0x1
    ]
    sent [LCP ConfReq id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    sent [LCP ConfReq id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    rcvd [LCP ConfReq id=0x2 0x9df3ca0d> ]
    sent [LCP ConfRej id=0x2 ]
    rcvd [LCP ConfReq id=0x3
    ]
    sent [LCP ConfAck id=0x3
    ]
    sent [LCP EchoReq id=0x0 magic=0x63daea33]
    cbcp_lowerup
    want: 2
    sent [IPCP ConfReq id=0x1 ]
    sent [CCP ConfReq id=0x1 ]
    rcvd [LCP EchoRep id=0x0 magic=0x9df3ca0d]
    rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
    rcvd [IPCP ConfReq id=0x5 ]
    sent [IPCP ConfAck id=0x5 ]
    sent [IPCP ConfReq id=0x1 ]
    rcvd [IPCP ConfRej id=0x1 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0x6 ]
    sent [IPCP ConfAck id=0x6 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0x7 ]
    sent [IPCP ConfAck id=0x7 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0x8 ]
    sent [IPCP ConfAck id=0x8 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0x9 ]
    sent [IPCP ConfAck id=0x9 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0xa ]
    sent [IPCP ConfAck id=0xa ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0xb ]
    sent [IPCP ConfAck id=0xb ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0xc ]
    sent [IPCP ConfAck id=0xc ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0xd ]
    sent [IPCP ConfAck id=0xd ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [IPCP ConfReq id=0xe ]
    sent [IPCP ConfAck id=0xe ]
    sent [LCP EchoReq id=0x1 magic=0x63daea33]
    rcvd [LCP EchoRep id=0x1 magic=0x9df3ca0d]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    rcvd [LCP TermReq id=0xf]
    LCP terminated by peer
    cbcp_lowerdown
    sent [LCP TermAck id=0xf]
    Connection terminated.


  2. Re: need to interpret LCPs, then set pppd options

    tj writes:

    ]Hi,
    ]Can someone interpret the LCP dialog and tell me what the deal is with not
    ]getting a local and a remote IP from the negotiation?

    It means you have a stupid isp with a broken ppp implimentation. Your
    first choice should be to find yourself a competent ISP. However, you
    could also try putting
    10.0.0.1:
    into the options. The remote side is refusing to assign you an IP
    address, which any competent ISP should do. But since he does not,
    assign yourself one as above. If the far side accepts this should not
    harm anything and things might even work.
    However in case the far side suddenly comes to its senses when you try
    to assign yourself an IP and decides to become macho and demand to
    assign you an IP, also put
    ipcp-accept-local
    as an option.




    ]sent [IPCP ConfReq id=0x1 ]
    You ask him to assign you an IP address.

    ]rcvd [IPCP ConfRej id=0x1 ]
    He rejects that.

    ]sent [IPCP ConfReq id=0x2 ]

    You request both local and remote addresses

    ]rcvd [IPCP ConfRej id=0x2 ]

    He rejects with a changed remote. This is totally nuts, and the ppp on
    the far side is broken.

    ]Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 89
    ]rcvd [IPCP ConfReq id=0x6 ]

    He requests and address for himself, which is fine.

    ]sent [IPCP ConfAck id=0x6 ]

    You accept.

    ]sent [IPCP ConfReq id=0x2 ]
    Here we go again.
    .....
    ]rcvd [LCP TermReq id=0xf]

    The far side finally quits. About time someone did. The negotiations
    were long long since dead.

    ]LCP terminated by peer
    ]cbcp_lowerdown
    ]sent [LCP TermAck id=0xf]
    ]Connection terminated.


  3. Re: need to interpret LCPs, then set pppd options

    Bill Unruh wrote:

    > ... you could also try putting
    > 10.0.0.1:
    > into the options. The remote side is refusing to assign you an IP
    > address, which any competent ISP should do. But since he does not,
    > assign yourself one as above. If the far side accepts this should not
    > harm anything and things might even work.
    > However in case the far side suddenly comes to its senses when you try
    > to assign yourself an IP and decides to become macho and demand to
    > assign you an IP, also put
    > ipcp-accept-local
    > as an option.
    >


    ok... did as requested... still no love. I added "192.168.50.100:" to the
    options file. Then I ran it twice as shown below...the second log includes
    the "ipcp-accept-remote" option.

    The connection works under Windows, here is the configuration that I get:
    DNS1: 68.28.240.242
    DNS2: 68.28.230.242
    IP: 68.26.239.200
    SUBMASK: 255.0.0.0
    DEF GW: 68.26.239.205
    DHCP SERVER: 255.255.255.255 (?!)

    btw: looks like the ISP is requesting CHAP, and I am refusing it. Is this a
    problem upstream that I should solve first?





    # pppd /dev/modem 57600 defaultroute

    Perms of /dev/modem are ok, no 'mesg n' neccesary.
    using channel 3
    Using interface ppp0
    Connect: ppp0 <--> /dev/modem
    sent [LCP ConfReq id=0x1
    ]
    sent [LCP ConfReq id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    sent [LCP ConfReq id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    rcvd [LCP ConfReq id=0x2 0x21260b33> ]
    sent [LCP ConfRej id=0x2 ]
    rcvd [LCP ConfReq id=0x3
    ]
    sent [LCP ConfAck id=0x3
    ]
    sent [LCP EchoReq id=0x0 magic=0xfabbb676]
    cbcp_lowerup
    want: 2
    sent [IPCP ConfReq id=0x1 ]
    sent [CCP ConfReq id=0x1 ]
    rcvd [IPCP ConfReq id=0x4 ]
    sent [IPCP ConfAck id=0x4 ]
    rcvd [LCP EchoRep id=0x0 magic=0x21260b33]
    rcvd [IPCP ConfNak id=0x1 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [LCP ProtRej id=0x5 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
    rcvd [IPCP ConfNak id=0x2 ]
    sent [IPCP ConfReq id=0x3 ]
    rcvd [IPCP ConfNak id=0x3 ]
    sent [IPCP ConfReq id=0x4 ]
    rcvd [IPCP ConfNak id=0x4 ]
    sent [IPCP ConfReq id=0x5 ]
    rcvd [IPCP ConfNak id=0x5 ]
    sent [IPCP ConfReq id=0x6 ]
    rcvd [IPCP ConfRej id=0x6 ]
    Received bad configure-nak/rej: 03 06 00 00 00 00
    rcvd [LCP TermReq id=0x6]
    LCP terminated by peer
    cbcp_lowerdown
    sent [LCP TermAck id=0x6]
    Connection terminated.





    # pppd /dev/modem 57600 defaultroute ipcp-accept-local
    Perms of /dev/modem are ok, no 'mesg n' neccesary.
    using channel 4
    Using interface ppp0
    Connect: ppp0 <--> /dev/modem
    sent [LCP ConfReq id=0x1
    ]
    sent [LCP ConfReq id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    sent [LCP ConfReq id=0x1
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    rcvd [LCP ConfReq id=0x2 0xcca1e010> ]
    sent [LCP ConfRej id=0x2 ]
    rcvd [LCP ConfReq id=0x3
    ]
    sent [LCP ConfAck id=0x3
    ]
    sent [LCP EchoReq id=0x0 magic=0x28b97477]
    cbcp_lowerup
    want: 2
    sent [IPCP ConfReq id=0x1 ]
    sent [CCP ConfReq id=0x1 ]
    rcvd [IPCP ConfReq id=0x4 ]
    sent [IPCP ConfAck id=0x4 ]
    rcvd [LCP EchoRep id=0x0 magic=0xcca1e010]
    rcvd [IPCP ConfNak id=0x1 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [LCP ProtRej id=0x5 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
    rcvd [IPCP ConfNak id=0x2 ]
    sent [IPCP ConfReq id=0x3 ]
    rcvd [IPCP ConfNak id=0x3 ]
    sent [IPCP ConfReq id=0x4 ]
    rcvd [IPCP ConfNak id=0x4 ]
    sent [IPCP ConfReq id=0x5 ]
    rcvd [IPCP ConfNak id=0x5 ]
    sent [IPCP ConfReq id=0x6 ]
    rcvd [IPCP ConfRej id=0x6 ]
    Received bad configure-nak/rej: 03 06 00 00 00 00
    rcvd [LCP TermReq id=0x6]
    LCP terminated by peer
    cbcp_lowerdown
    sent [LCP TermAck id=0x6]
    Connection terminated.


  4. Re: need to interpret LCPs, then set pppd options

    tj writes:

    ]Bill Unruh wrote:
    ]
    ]> ... you could also try putting
    ]> 10.0.0.1:
    ]> into the options. The remote side is refusing to assign you an IP
    ]> address, which any competent ISP should do. But since he does not,
    ]> assign yourself one as above. If the far side accepts this should not
    ]> harm anything and things might even work.
    ]> However in case the far side suddenly comes to its senses when you try
    ]> to assign yourself an IP and decides to become macho and demand to
    ]> assign you an IP, also put
    ]> ipcp-accept-local
    ]> as an option.
    ]>

    ]ok... did as requested... still no love. I added "192.168.50.100:" to the
    ]options file. Then I ran it twice as shown below...the second log includes
    ]the "ipcp-accept-remote" option.

    Really Really get a new ISP. Yours is completely and utterly
    incompetent. What or who is it? Please let the world know so that he can
    be avoided in the future.


    ]The connection works under Windows, here is the configuration that I get:
    ]DNS1: 68.28.240.242
    ]DNS2: 68.28.230.242

    So put them into /etc/resolv.conf as
    nameserver 68.28.240.242
    nameserver 68.28.230.242
    ]IP: 68.26.239.200

    OK, why don't you try this
    68.26.239.200:
    as an option.

    Also put in
    noccp
    since you and the far end share no compression.


    ]btw: looks like the ISP is requesting CHAP, and I am refusing it. Is this a
    ]problem upstream that I should solve first?

    No, but why don't you just put /etc/ppp/chap-secrets file ( same as the
    /etc/ppp/pap-secrets file).

    ]sent [IPCP ConfReq id=0x1 ]
    OK, you ask for this address.

    ]rcvd [IPCP ConfNak id=0x1 ]

    And this is completely and totally stupid and broken. The ISP on the far
    side really really is incompetent. Please tell us what that far end is.
    The far end should be telling you what he wants you to request for an ip
    address, and 0.0.0.0 is NOT a valid request for him to NAK at you.


    ]sent [IPCP ConfReq id=0x6 ]
    ]rcvd [IPCP ConfRej id=0x6 ]

    He is an idiot.

    ]Received bad configure-nak/rej: 03 06 00 00 00 00

    Yes, that is saying it mildly.
    There really is nothing you can do. That far end is seriously and
    utterly broken.

    You could try again with a proper chap-secrets file just in case the far
    end was driven insane by your rejection.



  5. Re: need to interpret LCPs, then set pppd options

    tj wrote:
    > Hi,
    > Can someone interpret the LCP dialog and tell me what the deal is with not
    > getting a local and a remote IP from the negotiation?


    Yes.

    > tj@spudbox5:~> grep -v ^# /etc/ppp/options | grep -v ^$


    > debug
    > noauth
    > crtscts
    > lock
    > modem
    > asyncmap 0
    > nodetach
    > lcp-echo-interval 30
    > lcp-echo-failure 4
    > lcp-max-configure 60
    > lcp-restart 2
    > idle 600
    > noipx


    > # pppd /dev/modem 57600 defaultroute novj noipdefault ipcp-accept-local


    > Perms of /dev/modem are ok, no 'mesg n' neccesary.


    The message above is not in any standard version of pppd. The Linux
    distributor has modified it.

    > using channel 5
    > Using interface ppp0
    > Connect: ppp0 <--> /dev/modem
    > sent [LCP ConfReq id=0x1
    > ]


    No where does the pppd option "mru 1492" appear. Why then does pppd
    request it? A matter of curiosity only, it's not causing the link
    negotiation failure.

    > sent [LCP ConfReq id=0x1
    > ]
    > rcvd [LCP ConfAck id=0x1
    > ]
    > sent [LCP ConfReq id=0x1
    > ]
    > rcvd [LCP ConfAck id=0x1
    > ]
    > rcvd [LCP ConfAck id=0x1
    > ]
    > rcvd [LCP ConfReq id=0x2 > 0x9df3ca0d> ]
    > sent [LCP ConfRej id=0x2 ]


    In the line above pppd rejects a request for CHAP authentication.
    This almost always means that the negotiations will fail, since the
    peer (remote host) wants to authenticate you.

    > rcvd [LCP ConfReq id=0x3
    > ]
    > sent [LCP ConfAck id=0x3
    > ]


    At this point the LCP negotiations are "open" and the peer should
    have gracefully terminated the PPP link negotiations. Instead it
    continues, even entering into (useless) IPCP negotiations with pppd.
    ....

    > rcvd [LCP TermReq id=0xf]
    > LCP terminated by peer
    > cbcp_lowerdown
    > sent [LCP TermAck id=0xf]
    > Connection terminated.


    The peer finally terminates the link negotiations here.

    I'd suggest you add the pppd option " user your_isp_username " and a
    line such as

    your_isp_username * your_isp_password

    to /etc/ppp/chap-secrets. Read man pppd for more details.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Bluffing in a poker game can win big; bluffing in a newsgroup
    only attracts sharks. */

  6. Re: need to interpret LCPs, then set pppd options

    tj writes:
    > Can someone interpret the LCP dialog and tell me what the deal is with not
    > getting a local and a remote IP from the negotiation?


    Sure. Your authentication information is misconfigured. (Another
    respondent stated that the ISP was broken; that doesn't appear to be
    the case. The ISP is silly because it should have just hung up the
    telephone when you refused to identify yourself, but it didn't.)

    > Perms of /dev/modem are ok, no 'mesg n' neccesary.


    Uh, oh. That's not a normal pppd message. It looks like you're using
    a hacked version (possibly from some Linux vendor). I don't know that
    it matters for this case, but you might want to consider downloading
    from samba.org and using that instead.

    > rcvd [LCP ConfReq id=0x2 > 0x9df3ca0d> ]


    The peer asks you to authenticate yourself using standard CHAP.

    > sent [LCP ConfRej id=0x2 ]


    You flat-out refuse to identify yourself at all. All bets are off at
    this point.

    Fix your authentication information. You should have an option like
    this in your pppd configuration:

    user myname

    and this in your /etc/ppp/chap-secrets:

    myname * "my pass phrase" *

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

  7. Re: need to interpret LCPs, then set pppd options

    Clifford Kite writes:
    > > sent [LCP ConfReq id=0x1
    > > ]

    >
    > No where does the pppd option "mru 1492" appear. Why then does pppd
    > request it? A matter of curiosity only, it's not causing the link
    > negotiation failure.


    Good catch. It might mean that this copy of pppd has been modified
    for use with PPPoE, though why such a thing would be done when a real
    serial port (/dev/modem) is in use is beyond me ...

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

  8. Re: need to interpret LCPs, then set pppd options

    James Carlson writes:

    ]tj writes:
    ]> Can someone interpret the LCP dialog and tell me what the deal is with not
    ]> getting a local and a remote IP from the negotiation?

    ]Sure. Your authentication information is misconfigured. (Another
    ]respondent stated that the ISP was broken; that doesn't appear to be
    ]the case. The ISP is silly because it should have just hung up the
    ]telephone when you refused to identify yourself, but it didn't.)

    That could make sense. I say the isp is broken because it accepts
    the refusal to authenticate and then emits nonesense.
    The ISP is perfectly within its right to accept a refusal to
    authenticate. It is not within its rights to then act insane.


    ]> Perms of /dev/modem are ok, no 'mesg n' neccesary.

    ]Uh, oh. That's not a normal pppd message. It looks like you're using

    Agreed, but there is no evidence that it is pppd's fault that the ISP
    acts in such a strange manner. Surely ConfNak with an address of 0.0.0.0
    makes no sense.


    ]a hacked version (possibly from some Linux vendor). I don't know that
    ]it matters for this case, but you might want to consider downloading
    ]from samba.org and using that instead.

    ]> rcvd [LCP ConfReq id=0x2 ]> 0x9df3ca0d> ]

    ]The peer asks you to authenticate yourself using standard CHAP.

    ]> sent [LCP ConfRej id=0x2 ]

    ]You flat-out refuse to identify yourself at all. All bets are off at
    ]this point.

    No. The peer is perfectly entitled to accept your refusal to
    authenticate yourself. There is absolutely nothing that says that the
    peer MUST terminate if you refuse to authenticate yourself.

    Now I suspect that you are right that this refusal drove the peer
    insane, but the insanity is the peer's, not the pppd's.




  9. Re: need to interpret LCPs, then set pppd options

    Clifford Kite writes:

    ]> sent [LCP ConfRej id=0x2 ]

    ]In the line above pppd rejects a request for CHAP authentication.
    ]This almost always means that the negotiations will fail, since the
    ]peer (remote host) wants to authenticate you.

    That may be a statement of practice, but the peer is perfectly entitled
    to accept your refusal to authenticate yourself, and continue
    negotiating AFAIK. Nothing says that the peer must insist on
    authentication even if it intially asks for it. Most peers will, but it
    needn't.


    ]> rcvd [LCP ConfReq id=0x3
    ]> ]
    ]> sent [LCP ConfAck id=0x3
    ]> ]

    ]At this point the LCP negotiations are "open" and the peer should
    ]have gracefully terminated the PPP link negotiations. Instead it
    ]continues, even entering into (useless) IPCP negotiations with pppd.
    ]...

    Why are they useless. You still seem to believe that the peer must
    demand authentication. Why?


    ]> rcvd [LCP TermReq id=0xf]
    ]> LCP terminated by peer
    ]> cbcp_lowerdown
    ]> sent [LCP TermAck id=0xf]
    ]> Connection terminated.

    ]The peer finally terminates the link negotiations here.

    ]I'd suggest you add the pppd option " user your_isp_username " and a
    ]line such as

    ]your_isp_username * your_isp_password

    ]to /etc/ppp/chap-secrets. Read man pppd for more details.

    Agreed. But I have no faith that this is the end of his problems. A peer
    this near the edge of insanity is liable to pushed over the edge by some
    thing else as well.


  10. Re: need to interpret LCPs, then set pppd options

    Bill Unruh wrote:
    > Clifford Kite writes:
    > ]> sent [LCP ConfRej id=0x2 ]


    > ]In the line above pppd rejects a request for CHAP authentication.
    > ]This almost always means that the negotiations will fail, since the
    > ]peer (remote host) wants to authenticate you.


    > That may be a statement of practice, but the peer is perfectly entitled
    > to accept your refusal to authenticate yourself, and continue
    > negotiating AFAIK. Nothing says that the peer must insist on
    > authentication even if it intially asks for it. Most peers will, but it
    > needn't.


    I didn't say it must insist on authentication, only that it wanted to
    authenticate him - which it clearly did. The "almost always" allows for
    other PPP implementation alternatives - as insensible as they might be.

    > ]> rcvd [LCP ConfReq id=0x3
    > ]> ]
    > ]> sent [LCP ConfAck id=0x3
    > ]> ]


    > ]At this point the LCP negotiations are "open" and the peer should
    > ]have gracefully terminated the PPP link negotiations. Instead it
    > ]continues, even entering into (useless) IPCP negotiations with pppd.
    > ]...


    > Why are they useless. You still seem to believe that the peer must
    > demand authentication. Why?


    They are useless because they serve no purpose and only delay termination
    of the link. Since the peer requested CHAP authentication it's reasonable
    to assume that it expected to authenticate him in some way. If it did,
    once pppd rejected all authentication anything other than terminating
    the link when LCP reached the open state would be broken behavior - in
    my opinion. Yes, the peer could have negotiated IPCP and even provided
    a viable PPP link after authentication was rejected, but I wouldn't have
    bet a penny on that happening, even given 100 billion to one odds.

    The question "Why?" appears to be based on the false assumption that I
    previously believed the peer must demand authentication. Any answer to
    the question would be meaningless in that case.

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

  11. Re: need to interpret LCPs, then set pppd options



    ]Bill Unruh wrote:
    ]> Clifford Kite writes:
    ]> ]> sent [LCP ConfRej id=0x2 ]

    ]> ]In the line above pppd rejects a request for CHAP authentication.
    ]> ]This almost always means that the negotiations will fail, since the
    ]> ]peer (remote host) wants to authenticate you.

    ]> That may be a statement of practice, but the peer is perfectly entitled
    ]> to accept your refusal to authenticate yourself, and continue
    ]> negotiating AFAIK. Nothing says that the peer must insist on
    ]> authentication even if it intially asks for it. Most peers will, but it
    ]> needn't.

    ]I didn't say it must insist on authentication, only that it wanted to
    ]authenticate him - which it clearly did. The "almost always" allows for
    ]other PPP implementation alternatives - as insensible as they might be.

    I could imagine an internal ppp implimentation (ie not open to the
    public) in which two types of ppp hookup were allowed, one with and one
    without authentication-- with the two giving different levels of
    access-- say to an informational local web site only in the non-authentication
    mode, and to full access with the other. And the ppp negotiation could
    then proceed exactly as seen-- ask for authentication, if refused,
    connect but only allow restricted access.
    I could even imagine this on a public ppp implimentation, where on the
    first hook up you do not have any password, and you are given ppp access
    only to hook up to a registration web site. Neither of these are
    insensible-- perhaps better handled in some other way, but not stupid.


    ]> ]> rcvd [LCP ConfReq id=0x3
    ]> ]> ]
    ]> ]> sent [LCP ConfAck id=0x3
    ]> ]> ]

    ]> ]At this point the LCP negotiations are "open" and the peer should
    ]> ]have gracefully terminated the PPP link negotiations. Instead it
    ]> ]continues, even entering into (useless) IPCP negotiations with pppd.
    ]> ]...

    ]> Why are they useless. You still seem to believe that the peer must
    ]> demand authentication. Why?

    ]They are useless because they serve no purpose and only delay termination
    ]of the link. Since the peer requested CHAP authentication it's reasonable
    ]to assume that it expected to authenticate him in some way. If it did,

    I agree that it is reasonable to assume this. However, with the evidence
    that the negotiations continue, even after the rejection, that
    assumption must become weaker.

    ]once pppd rejected all authentication anything other than terminating
    ]the link when LCP reached the open state would be broken behavior - in
    ]my opinion. Yes, the peer could have negotiated IPCP and even provided

    I certainly agree that it is broken. What I was questioning was the assertion
    that because it had asked for authentication it must terminate after the
    authentication was refused, that this refusal to terminate immediately
    itself indicted broken behaviour.
    Its response with a ConfRej with an IP of 0.0.0.0 I believe does by itself indicate
    broken behaviour.

    ]a viable PPP link after authentication was rejected, but I wouldn't have
    ]bet a penny on that happening, even given 100 billion to one odds.


    We do not know what or who was at
    the other end of that ppp link-- either it was a public ISP (in which
    case I would have expected his badly broken ppp implimentation would
    have caused many many complaints from his customers already) or it was
    some private machine the poster wanted to make a connection with (in
    which case your odds, I suspect, would have dropped) or even some ppp
    implimentation that the writer had done himself which he was testing.

    However we both agree that the implimentation at the far end was badly
    broken. Exactly how we perhaps disagree on. Even under your hypothesis
    that it was broken by not immediately terminating after the refusal to
    authenticate, it was also broken in its subsequent handling of the ICPC
    negotiations. (Or is there some situation in which a ConfRej of an IP of
    0.0.0.0 would make sense?)



  12. Re: need to interpret LCPs, then set pppd options

    Bill Unruh wrote:


    > ]Bill Unruh wrote:
    > ]> Clifford Kite writes:
    > ]> ]> sent [LCP ConfRej id=0x2 ]


    > ]> ]In the line above pppd rejects a request for CHAP authentication.
    > ]> ]This almost always means that the negotiations will fail, since the
    > ]> ]peer (remote host) wants to authenticate you.


    > ]> That may be a statement of practice, but the peer is perfectly entitled
    > ]> to accept your refusal to authenticate yourself, and continue
    > ]> negotiating AFAIK. Nothing says that the peer must insist on
    > ]> authentication even if it intially asks for it. Most peers will, but it
    > ]> needn't.


    > ]I didn't say it must insist on authentication, only that it wanted to
    > ]authenticate him - which it clearly did. The "almost always" allows for
    > ]other PPP implementation alternatives - as insensible as they might be.


    > I could imagine an internal ppp implimentation (ie not open to the
    > public) in which two types of ppp hookup were allowed, one with and one
    > without authentication-- with the two giving different levels of
    > access-- say to an informational local web site only in the non-authentication
    > mode, and to full access with the other. And the ppp negotiation could
    > then proceed exactly as seen-- ask for authentication, if refused,
    > connect but only allow restricted access.
    > I could even imagine this on a public ppp implimentation, where on the
    > first hook up you do not have any password, and you are given ppp access
    > only to hook up to a registration web site. Neither of these are
    > insensible-- perhaps better handled in some other way, but not stupid.


    I can imagine continuing this discussion based on the statement above,
    and also by replying to your final question, but it doesn't appear to
    me to productive to do so. It's too close to a debate, and I don't like
    usenet debates on subjects that don't seem to me to be of significant
    value to others.

    Hope you had a merry Christmas and may you have a happy new year!

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* "PPPoE has many advantages for DSL service providers, and
    practically none for DSL consumers."
    - David F. Skoll */

  13. Re: need to interpret LCPs, then set pppd options

    Clifford Kite wrote:

    > I'd suggest you add the pppd option " user your_isp_username " and a
    > line such as
    >
    > your_isp_username * your_isp_password
    >
    > to /etc/ppp/chap-secrets. Read man pppd for more details.
    >



    Yes, that makes perfect sense. Here's what I have done:

    chap-secrets:
    happyuser01 * [passphrase] *


    Results seem strange to me though... have a look please!
    Since it still didn't negotiate a local IP address I tried to incorporate
    the name "PDSN" into the chap-secrets file (assuming upstream
    authentication failure as before), but the only successful chap is the one
    that you suggested (above). Also, adding "ipcp-accept-local" has no effect
    on the response. What does the remote response "^@" indicate?

    TIA
    TJ


    # pppd /dev/modem 57600 defaultroute user happyuser01
    Perms of /dev/modem are ok, no 'mesg n' neccesary.
    using channel 3
    Using interface ppp0
    Connect: ppp0 <--> /dev/modem
    sent [LCP ConfReq id=0x1 ]
    sent [LCP ConfReq id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    sent [LCP ConfReq id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfReq id=0x2 0xf94ddeb2> ]
    sent [LCP ConfAck id=0x2 0xf94ddeb2> ]
    sent [LCP EchoReq id=0x0 magic=0x303305fd]
    cbcp_lowerup
    want: 2
    rcvd [CHAP Challenge id=0x3 , name =
    "PDSN"]
    sent [CHAP Response id=0x3 <657db3a85da2daad19b8e503be6f0439>, name =
    "happyuser01"]
    rcvd [LCP EchoRep id=0x0 magic=0xf94ddeb2]
    rcvd [CHAP Success id=0x3 "\000"]
    Remote message: ^@
    sent [IPCP ConfReq id=0x1 ]
    sent [CCP ConfReq id=0x1 ]
    rcvd [IPCP ConfReq id=0x4 ]
    sent [IPCP ConfAck id=0x4 ]
    rcvd [IPCP ConfNak id=0x1 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [LCP ProtRej id=0x5 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
    rcvd [IPCP ConfNak id=0x2 ]
    sent [IPCP ConfReq id=0x3 ]
    rcvd [IPCP ConfNak id=0x3 ]
    sent [IPCP ConfReq id=0x4 ]
    rcvd [IPCP ConfNak id=0x4 ]
    sent [IPCP ConfReq id=0x5 ]
    rcvd [IPCP ConfNak id=0x5 ]
    sent [IPCP ConfReq id=0x6 ]
    rcvd [IPCP ConfRej id=0x6 ]
    Received bad configure-nak/rej: 03 06 00 00 00 00
    rcvd [LCP TermReq id=0x6]
    LCP terminated by peer
    cbcp_lowerdown
    sent [LCP TermAck id=0x6]
    Connection terminated.


  14. Re: need to interpret LCPs, then set pppd options

    tj writes:

    ]Clifford Kite wrote:

    ]> I'd suggest you add the pppd option " user your_isp_username " and a
    ]> line such as
    ]>
    ]> your_isp_username * your_isp_password
    ]>
    ]> to /etc/ppp/chap-secrets. Read man pppd for more details.
    ]>


    ]Yes, that makes perfect sense. Here's what I have done:

    ]chap-secrets:
    ]happyuser01 * [passphrase] *


    ]Results seem strange to me though... have a look please!

    Your chap file resulted in a successful authentication.
    No more concerns there. This is not your problem. An insane remote ISP
    IS your problem.

    Tell us more about the ISP. Who or what is it you ae trying to log onto?
    Tehre is nothng else we can do without more information.


    ]Since it still didn't negotiate a local IP address I tried to incorporate
    ]the name "PDSN" into the chap-secrets file (assuming upstream

    ]that you suggested (above). Also, adding "ipcp-accept-local" has no effect
    ]on the response. What does the remote response "^@" indicate?

    a stray null character.


    ]sent [LCP ConfAck id=0x2 ]0xf94ddeb2> ]
    You accept chap authentication

    ]rcvd [CHAP Challenge id=0x3 , name =
    ]"PDSN"]
    They send a challenge

    ]sent [CHAP Response id=0x3 <657db3a85da2daad19b8e503be6f0439>, name =
    ]"happyuser01"]
    You send a response

    ]rcvd [CHAP Success id=0x3 "\000"]

    They are happy. DO not worry any more about authentication.

    ]Remote message: ^@

    That is just the \000 of the above line. That is the message they sent
    with the chap success message.

    ]sent [IPCP ConfReq id=0x1 ]
    ]sent [CCP ConfReq id=0x1 ]
    ]rcvd [IPCP ConfReq id=0x4 ]
    ]sent [IPCP ConfAck id=0x4 ]

    You negotiate an address for them.

    ]rcvd [IPCP ConfNak id=0x1 ]

    Again they go insane, and suggest that you request and ip address from
    them. What they should do is to do a ConfNAk with the IP they want you
    to have.

    ]sent [IPCP ConfReq id=0x2 ]
    ]rcvd [LCP ProtRej id=0x5 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
    ]rcvd [IPCP ConfNak id=0x2 ]
    ]sent [IPCP ConfReq id=0x3 ]
    ]rcvd [IPCP ConfNak id=0x3 ]

    At which point this stupid dance continues.

    Try removing the
    10.0.2.1:
    line from your /etc/ppp/options file.
    Your isp really is rather insane. Whether you want to continue to deal
    with an insane ISP is up to you. I would advise leaving him to wallow in
    his own insanity, but your options may be more limited.
    In that case try my suggestion above.



  15. Re: need to interpret LCPs, then set pppd options

    Bill Unruh wrote:

    > Try removing the
    > 10.0.2.1:
    > line from your /etc/ppp/options file.
    > Your isp really is rather insane. Whether you want to continue to deal
    > with an insane ISP is up to you. I would advise leaving him to wallow in
    > his own insanity, but your options may be more limited.


    The service provider is Sprint. I have a cell-phone pcmcia card (Novatel
    Merlin C-201) that has a Windoze black-box "connection manager" - and yes it
    still works. Using linux, I had been able to connect sucessfully up until
    about two months ago; Sprint apparently has changed their ppp negotiation
    procedure. I had the same ppp/options file then as today, and did not have
    to specify any username options (nor did I need a chap-secrets entry). I
    should also note: Sprint has refused my request to supply any information
    pertaining to this issue.

    I dont have "10.0.2.1:" in my options file. My guess is that a SuSE script
    is re-using its last known IP (it was for the NIC, but I assure you that
    ifconfig shows only a loopback now). Whatever the reason, I tried the
    following options with no success:

    noipdefault
    (appears to request 0.0.0.0:0.0.0.0, and is refused 10 times)
    192.168.50.100:
    (or SuSE's 10.0.2.1 - is refused 5 times as shown previously)
    ipcp-accept-local
    (has no effect when used with either of the above options)

    However... when using the "noipdefault" option, I get a new warning at the
    end of the negotiation that I do not otherwise get:

    IPCP: timeout sending Config-Requests
    cbcp_lowerdown
    sent [LCP TermReq id=0x2 "No network protocols running"]

    Here's the config so far...


    # pppd /dev/modem 57600 defaultroute noipdefault user happyuser01

    chap-secrets:
    happyuser01 * [passphrase] *

    > tj@spudbox5:~> grep -v ^# /etc/ppp/options | grep -v ^$


    > debug
    > noauth
    > crtscts
    > lock
    > modem
    > asyncmap 0
    > nodetach
    > lcp-echo-interval 30
    > lcp-echo-failure 4
    > lcp-max-configure 60
    > lcp-restart 2
    > idle 600
    > noipx
    > ip-accept-local


    # pppd /dev/modem 57600 defaultroute user happyuser01
    Perms of /dev/modem are ok, no 'mesg n' neccesary.
    using channel 10
    Using interface ppp0
    Connect: ppp0 <--> /dev/modem
    sent [LCP ConfReq id=0x1 ]
    sent [LCP ConfReq id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    sent [LCP ConfReq id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfReq id=0x2 0x42f1304d> ]
    sent [LCP ConfAck id=0x2 0x42f1304d> ]
    sent [LCP EchoReq id=0x0 magic=0x82a27c8d]
    cbcp_lowerup
    want: 2
    rcvd [CHAP Challenge id=0x3 , name =
    "PDSN"]
    sent [CHAP Response id=0x3 <3fdcad1783da87dd82c9aa7252d88ff3>, name =
    "happyuser01"]
    rcvd [LCP EchoRep id=0x0 magic=0x42f1304d]
    rcvd [CHAP Success id=0x3 "\000"]
    Remote message: ^@
    sent [IPCP ConfReq id=0x1 ]
    sent [CCP ConfReq id=0x1 ]
    rcvd [IPCP ConfReq id=0x4 ]
    sent [IPCP ConfAck id=0x4 ]
    rcvd [IPCP ConfRej id=0x1 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [LCP ProtRej id=0x5 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfReq id=0x6 ]
    sent [IPCP ConfAck id=0x6 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    rcvd [IPCP ConfReq id=0x7 ]
    sent [IPCP ConfAck id=0x7 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    rcvd [IPCP ConfReq id=0x8 ]
    sent [IPCP ConfAck id=0x8 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    rcvd [IPCP ConfReq id=0x9 ]
    sent [IPCP ConfAck id=0x9 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    rcvd [IPCP ConfReq id=0xa ]
    sent [IPCP ConfAck id=0xa ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    rcvd [IPCP ConfReq id=0xb ]
    sent [IPCP ConfAck id=0xb ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    rcvd [IPCP ConfReq id=0xc ]
    sent [IPCP ConfAck id=0xc ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    rcvd [IPCP ConfReq id=0xd ]
    sent [IPCP ConfAck id=0xd ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    rcvd [IPCP ConfReq id=0xe ]
    sent [IPCP ConfAck id=0xe ]
    sent [LCP EchoReq id=0x1 magic=0x82a27c8d]
    rcvd [LCP EchoRep id=0x1 magic=0x42f1304d]
    IPCP: timeout sending Config-Requests
    cbcp_lowerdown
    sent [LCP TermReq id=0x2 "No network protocols running"]
    rcvd [LCP TermAck id=0x2]
    Connection terminated.


  16. Re: need to interpret LCPs, then set pppd options

    tj writes:

    ]Bill Unruh wrote:

    ]> Try removing the
    ]> 10.0.2.1:
    ]> line from your /etc/ppp/options file.
    ]> Your isp really is rather insane. Whether you want to continue to deal
    ]> with an insane ISP is up to you. I would advise leaving him to wallow in
    ]> his own insanity, but your options may be more limited.

    ]The service provider is Sprint. I have a cell-phone pcmcia card (Novatel
    ]Merlin C-201) that has a Windoze black-box "connection manager" - and yes it

    Ah, one of those cell phone versions of ppp. It seems that thousands of
    incompetents have been making a living by creating new implimentations
    of ppp for various cell phone companies.

    ]still works. Using linux, I had been able to connect sucessfully up until
    ]about two months ago; Sprint apparently has changed their ppp negotiation
    ]procedure. I had the same ppp/options file then as today, and did not have
    ]to specify any username options (nor did I need a chap-secrets entry). I
    ]should also note: Sprint has refused my request to supply any information
    ]pertaining to this issue.

    They probably know nothing.


    ]I dont have "10.0.2.1:" in my options file. My guess is that a SuSE script
    ]is re-using its last known IP (it was for the NIC, but I assure you that
    ]ifconfig shows only a loopback now). Whatever the reason, I tried the

    OK, if do not use no-ip-defaults it will use the IP address of the
    ethernet card, if one is up.

    ]following options with no success:

    One option your really really should use is
    noccp



    ] noipdefault
    ] (appears to request 0.0.0.0:0.0.0.0, and is refused 10 times)

    That is what it should do (request 0.0.0.0:0.0.0.0)

    ] 192.168.50.100:
    ] (or SuSE's 10.0.2.1 - is refused 5 times as shown previously)
    ] ipcp-accept-local
    ] (has no effect when used with either of the above options)

    ]However... when using the "noipdefault" option, I get a new warning at the
    ]end of the negotiation that I do not otherwise get:

    ] IPCP: timeout sending Config-Requests
    ] cbcp_lowerdown
    ] sent [LCP TermReq id=0x2 "No network protocols running"]

    ]Here's the config so far...


    ]# pppd /dev/modem 57600 defaultroute noipdefault user happyuser01

    ]chap-secrets:
    ]happyuser01 * [passphrase] *

    ]> tj@spudbox5:~> grep -v ^# /etc/ppp/options | grep -v ^$

    ]> debug
    ]> noauth
    ]> crtscts
    ]> lock
    ]> modem
    ]> asyncmap 0
    ]> nodetach


    ]> lcp-echo-interval 30
    ]> lcp-echo-failure 4
    ]> lcp-max-configure 60
    ]> lcp-restart 2

    Get rid of all these lcp- options for now.

    ]> idle 600
    ]> noipx

    get rid of noipx for now

    ]> ip-accept-local

    add
    noccp

    After this I am completely out of ideas. Teh remote ppp is broken. But
    how to make it think it is not I have no idea.



    ]# pppd /dev/modem 57600 defaultroute user happyuser01
    ]Perms of /dev/modem are ok, no 'mesg n' neccesary.
    ]using channel 10
    ]Using interface ppp0
    ]Connect: ppp0 <--> /dev/modem
    ]sent [LCP ConfReq id=0x1 ]
    ]sent [LCP ConfReq id=0x1 ]
    ]rcvd [LCP ConfAck id=0x1 ]
    ]rcvd [LCP ConfAck id=0x1 ]
    ]sent [LCP ConfReq id=0x1 ]
    ]rcvd [LCP ConfAck id=0x1 ]
    ]rcvd [LCP ConfReq id=0x2 ]0x42f1304d> ]
    ]sent [LCP ConfAck id=0x2 ]0x42f1304d> ]
    ]sent [LCP EchoReq id=0x0 magic=0x82a27c8d]
    ]cbcp_lowerup
    ]want: 2
    ]rcvd [CHAP Challenge id=0x3 , name =
    ]"PDSN"]
    ]sent [CHAP Response id=0x3 <3fdcad1783da87dd82c9aa7252d88ff3>, name =
    ]"happyuser01"]
    ]rcvd [LCP EchoRep id=0x0 magic=0x42f1304d]
    ]rcvd [CHAP Success id=0x3 "\000"]
    ]Remote message: ^@
    ]sent [IPCP ConfReq id=0x1 ]
    ]sent [CCP ConfReq id=0x1 ]
    ]rcvd [IPCP ConfReq id=0x4 ]
    ]sent [IPCP ConfAck id=0x4 ]
    ]rcvd [IPCP ConfRej id=0x1 ]

    I do not believe that this response makes any sense whatsoever.
    When you sign on with Windows, what IP address do you end up with? Try
    using that IP address in your options file.



    ]sent [IPCP ConfReq id=0x2 ]

    Well, one might argue that pppd should send in 0.0.0.0 68.28.37.134 and
    not 0.0.0.0 0.0.0.0. I have never seen this form of address request for
    pppd befor and thus this looks like it might well be an altered version.
    You might want to get a real pppd from ftp.samba.org (pppd 2.4.1) and
    try using that instead. Not that I have much hope but who knows.


    ]sent [LCP TermReq id=0x2 "No network protocols running"]
    This means that you, not the other side request termination.

    ]rcvd [LCP TermAck id=0x2]
    ]Connection terminated.


  17. Re: need to interpret LCPs, then set pppd options

    Clifford Kite writes:

    ]tj wrote:

    ]> rcvd [IPCP ConfRej id=0x1 ]

    ]This is really peculiar. In the last log you posted the peer actually
    ]suggested that pppd use 0.0.0.0 in an IPCP Nak. Here the peer rejects
    ]it, implying that it doesn't have any IP address to give pppd.

    ]One other thing that might be significant is that pppd requested
    ] but the peer request was .
    ]The second form is for VJ header compression but without connection
    ]ID compression, and it's always a good idea to imitate the peer when
    ]an unknown problem exists. To do that, add the pppd option novjccomp.


    ]> rcvd [IPCP ConfRej id=0x2 ]
    ]> Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86

    ]Inexplicable. The PPP specifies that the rejected option MUST match
    ]the requested option, which was .

    This looks like it might have been supposed to be a confnak, but it
    would make no sense then either. If it has a suggestion for the local
    ip, it should send it. If not, it should accept the local machine's
    request. It does neither. This makes it seem that it wants some specific
    IP address (or address range) but it unwilling to state what it is (some
    weird security procedure?). My last suggestion is that the user look at
    what the IP address assigned to his machine under windows is, and to use
    that as the suggestion. Ie, the windows connection manager black box
    supplied by the company may have an ip address coded in and the far side
    is demanding to see that and only that address.

    It would be nice to see the trail of a Windows negotiation. I do not do
    windows at all-- is there some way of getting windows to disgorge a
    negotiation trail?



    ]Now I have to admit that Bill Unruh was on target from the beginning,
    ]the peer really is broken. But apparently it is broken in a way that
    ]is acceptable to the Microsoft "connection manager." :/

    The problem is that it is really difficult to imagine what the MS
    connection manager could do with this.


    ]I too am now out of suggestions.


  18. Re: need to interpret LCPs, then set pppd options

    Clifford Kite writes:
    > > I dont have "10.0.2.1:" in my options file. My guess is that a SuSE script
    > > is re-using its last known IP (it was for the NIC, but I assure you that
    > > ifconfig shows only a loopback now). Whatever the reason, I tried the
    > > following options with no success:

    >
    > > noipdefault

    >
    > The noipdefault option prevents pppd from defaulting to a local NIC
    > IP address.
    > ...


    Not that it really matters, but the default is the first IP address
    that is returned when 'hostname' (/usr/bin/hostname, gethostname()) is
    resolved by gethostbyname().

    > > sent [IPCP ConfReq id=0x2 ]

    >
    > This is the old, and obsolete, PPP IP addresses option. I believe it
    > would be a good idea to add the undocumented pppd option ipcp-no-addresses
    > - unless this version of pppd doesn't support that option. I don't know
    > when the option was introduced.


    No, that option isn't needed.

    When the peer rejects the "new" IPCP-Address option, pppd will
    automatically fall back to trying the old-style IPCP-Addresses option.
    This is harmless, and is really just a symptom of the other bug -- the
    peer is rejecting your request for an IP address. (It may have been
    thrown into a tizzy by the original non-zero request, which
    'noipdefault' should fix. But that's a wild guess. A properly
    working peer should have just sent back IPCP Configure-Nak specifying
    the address desired, rather than expecting exactly 0.0.0.0.)

    > > rcvd [IPCP ConfRej id=0x2 ]
    > > Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86

    >
    > Inexplicable. The PPP specifies that the rejected option MUST match
    > the requested option, which was .


    Right. This peer is clearly quite broken. There are, unfortunately,
    a fair number of feeble implementations of PPP out there, most
    apparently designed by folks who decided to reinvent the wheel and
    ended up with something that's a bit less than round.

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

  19. Re: need to interpret LCPs, then set pppd options

    Bill Unruh wrote:

    > It would be nice to see the trail of a Windows negotiation. I do
    > not do windows at all-- is there some way of getting windows to
    > disgorge a negotiation trail?


    Whether you can get a negotiation trail I can't say, but it would be
    nice to have one. There are commands "route print" and "ipconfig"
    both of which can be executed from an XP command line prompt to show
    routing and interface configurations. I don't know if they exist
    for any other Windows OS. The outputs seem strange as compared to
    the *nix commands route and ifconfig, e.g., from "route print" :

    Active Routes:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 216.40.234.58 216.40.234.58 1
    127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
    207.44.129.90 255.255.255.255 216.40.234.58 216.40.234.58 1
    216.40.234.58 255.255.255.255 127.0.0.1 127.0.0.1 50
    216.40.234.255 255.255.255.255 216.40.234.58 216.40.234.58 50
    224.0.0.0 240.0.0.0 216.40.234.58 216.40.234.58 1
    255.255.255.255 255.255.255.255 216.40.234.58 2 1
    Default Gateway: 216.40.234.58

    I happen to know that 207.44.129.90 is the remote (ISP connection host)
    and 216.40.234.58 the local IP address. The local IP address is also
    called a gateway in the ipconfig output and the remote IP address is
    not shown. It's difficult for me to parse the outputs in a way that
    makes sense.

    I'm not sure how useful this would be, but there's a chance it could
    yield a clue. Note that for cellular networking PPP may just be a
    convenient way to obtain certain parameters and PPP itself may not be
    used as the link layer protocol. Recall that tj essentially said he
    didn't do PPP authentication until recently.

    I've learned a little about cellular networking in the past couple
    of days and it appears there is a card in the cell phone, called
    a Subscriber Identity Module (SIM) - or a variation thereon, that
    provides user identification for the cell phone connection. The new
    CHAP authentication could well to a Radius server that only provides
    IP addresses.

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

  20. Re: need to interpret LCPs, then set pppd options

    In article ,
    Bill Unruh wrote:
    >Clifford Kite writes:
    >]tj wrote:
    >]> rcvd [IPCP ConfRej id=0x2 ]
    >]> Received bad configure-nak/rej: 01 0a 00 00 00 00 44 1c 25 86
    >
    >]Inexplicable. The PPP specifies that the rejected option MUST match
    >]the requested option, which was .
    >
    >This looks like it might have been supposed to be a confnak, but it
    >would make no sense then either.


    That's what I thought when I saw that. As if the peer meant to do a
    Configure-Nak, not a Configure-Reject. Obviously, a peer isn't supposed
    to change anything in option(s) it's rejecting.

    >It would be nice to see the trail of a Windows negotiation. I do not do
    >windows at all-- is there some way of getting windows to disgorge a
    >negotiation trail?


    Well, the demo version of PacketView Pro will allow you to capture the
    first 32 packets of the negotiations - that might be enough? TJ can
    download the demo from ftp://ftp.klos.com/pub/demo/PacketViewProInstall.exe
    (if he's watching). PacketView Pro works on Windows 2000 and XP.

    Patrick
    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==================== What goes around, comes around... =====================

+ Reply to Thread
Page 1 of 2 1 2 LastLast