LCP rejecting unknown option (solaris 9) - PPP

This is a discussion on LCP rejecting unknown option (solaris 9) - PPP ; Hi, I haven't played with ppp for a while and am a bit rusty on why I'm having trouble. The machine is (temporarily) on a LAN but will not be once it is deployed in the field. Thank you for ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: LCP rejecting unknown option (solaris 9)

  1. LCP rejecting unknown option (solaris 9)

    Hi,
    I haven't played with ppp for a while and am a bit rusty on why I'm
    having trouble. The machine is (temporarily) on a LAN but will not be
    once it is deployed in the field.
    Thank you for exposing what I hope is a simple omission....
    - Judy


    uname -a
    SunOS shel 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Blade-100


    Mar 2 17:00:00 shel pppd[20910]: [ID 860527 daemon.notice] pppd 2.4.0b1
    (Sun Microsystems, Inc., Mar 13 20
    03 00:33:58) started by nrts, uid 2000
    Mar 2 17:00:00 shel pppd[20910]: [ID 702911 daemon.debug] serial speed
    set to 38400 bps
    Mar 2 17:00:01 shel pppd[20910]: [ID 702911 daemon.debug] connect
    option: '/usr/bin/chat -v -f /etc/ppp/ch
    at-ucsd-isp' started (pid 20911)
    Mar 2 17:00:28 shel pppd[20910]: [ID 702911 daemon.info] Serial
    connection established.
    Mar 2 17:00:28 shel pppd[20910]: [ID 702911 daemon.debug] serial speed
    set to 38400 bps
    Mar 2 17:00:28 shel pppd[20910]: [ID 702911 daemon.info] Using
    interface sppp0
    Mar 2 17:00:28 shel pppd[20910]: [ID 702911 daemon.notice] Connect:
    sppp0 <--> /dev/cua/a
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug]
    /etc/ppp/pap-secrets is apparently empty
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug]
    /etc/ppp/chap-secrets is apparently empty
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0x1f gic 0x1d9449eb> ]
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0x1 < 00 04 00 00> p 0xa0000> [MAC:00:c0:7b:5e:9b:47]> ]
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] LCP:
    rejecting unknown option 0
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] LCP:
    rejecting unknown option 23
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] sent [LCP
    Ident id=0x20 magic=0x0 "ppp-2.4.0b1 (
    Sun Microsystems, Inc., Mar 13 2003 00:33:57)"]
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] sent [LCP
    ConfRej id=0x1 < 00 04 00 00> 00> ]
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    ConfAck id=0x1f gic 0x1d9449eb> ]
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    CodeRej id=0x2 0c 20 00 42 00 00 00 00
    70 70 70 2d 32 2e 34 2e 30 62 31 20 28 53 75 6e 20 4d 69 63 72 6f 73
    79 ...]
    Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.warning] LCP: Rcvd
    Code-Reject for Identification id 32
    Mar 2 17:00:32 shel pppd[20910]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0x1f gic 0x1d9449eb> ]
    Mar 2 17:00:32 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    ConfAck id=0x1f gic 0x1d9449eb> ]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0x3 < 00 04 00 00> p 0xa0000> [MAC:00:c0:7b:5e:9b:47]> ]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] LCP:
    rejecting unknown option 0
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] LCP:
    rejecting unknown option 23
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] LCP: Peer has
    rejected Identification; not sendi
    ng another
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] sent [LCP
    ConfRej id=0x3 < 00 04 00 00> 00> ]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0x4 mp> ]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] sent [LCP
    ConfAck id=0x4 mp> ]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] LCP: Peer has
    rejected Identification; not sendi
    ng another
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] sent [IPCP
    ConfReq id=0x7 ess VJ 0f 01>]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] sent [CCP
    ConfReq id=0x25 old#) 15> ]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [IPCP
    ConfReq id=0x1 ddr 137.110.0.74>]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] sent [IPCP
    ConfAck id=0x1 ddr 137.110.0.74>]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [CCP
    ConfReq id=0x1 3>]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] sent [CCP
    ConfRej id=0x1 3>]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [IPCP
    ConfAck id=0x7 ess VJ 0f 01>]
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.notice] local IP
    address 10.9.0.1
    Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.notice] remote IP
    address 137.110.0.74
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [CCP
    ConfRej id=0x25 old#) 15> ]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] sent [CCP
    ConfReq id=0x26]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [CCP
    ConfRej id=0x26]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] sent [CCP
    ConfReq id=0x27]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [CCP
    TermReq id=0x2]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] sent [CCP
    TermAck id=0x2]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [IPCP
    TermReq id=0x2]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.info] IPCP
    terminated by peer
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] sent [IPCP
    TermAck id=0x2]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [CBCP
    code=0x5 id=0x1]
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.warning] Unsupported
    protocol 0xc029 received
    Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] sent [LCP
    ProtRej id=0x23 c0 29 05 01 00 04]
    Mar 2 17:00:34 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [LCP
    TermReq id=0x5]
    Mar 2 17:00:34 shel pppd[20915]: [ID 702911 daemon.info] LCP terminated
    by peer
    Mar 2 17:00:34 shel pppd[20915]: [ID 702911 daemon.debug] sent [LCP
    TermAck id=0x5]
    Mar 2 17:00:35 shel pppd[20915]: [ID 702911 daemon.notice] Modem hangup
    Mar 2 17:00:35 shel pppd[20915]: [ID 702911 daemon.notice] Connection
    terminated.
    Mar 2 17:00:35 shel pppd[20915]: [ID 702911 daemon.info] Connect time
    0.1 minutes.
    Mar 2 17:00:35 shel pppd[20915]: [ID 702911 daemon.info] Sent 406 bytes
    (13 packets), received 613 bytes (
    14 packets).
    Mar 2 17:00:36 shel pppd[20915]: [ID 834084 daemon.info] Exit.


    nrts@shel 58> cat /etc/ppp/options
    lock
    crtscts
    noauth
    noproxyarp
    idle 60
    debug 4

    nrts@shel 59> cat peers/ucsd-isp
    /dev/cua/a
    38400
    updetach
    connect "/usr/bin/chat -v -f /etc/ppp/chat-ucsd-isp"
    asyncmap a0000
    defaultroute

    nrts@shel 60> cat chat-ucsd-isp
    #
    ABORT BUSY
    ABORT 'NO CARRIER'
    "" "AT&F1"
    TIMEOUT 60
    OK "atdt85358273\#"
    "name:" "mylogin"
    "word:" "\qmypassword"
    "annex:" "ppp"




  2. Re: LCP rejecting unknown option (solaris 9)

    Judy Illeman Gaukel writes:
    > Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    > ConfReq id=0x1 < 00 04 00 00> > p 0xa0000> > [MAC:00:c0:7b:5e:9b:47]> ]
    > Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] LCP:
    > rejecting unknown option 0
    > Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] LCP:
    > rejecting unknown option 23


    That system is a bit weird. It looks like an old Ascend box to me,
    though the scripts below suggest that it's an Annex. (How can that
    be?)

    > Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] sent [LCP
    > ConfRej id=0x1 < 00 04 00 00> > 00> ]


    We correctly tell it that we don't want those options.

    > Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    > ConfReq id=0x3 < 00 04 00 00> > p 0xa0000> > [MAC:00:c0:7b:5e:9b:47]> ]


    That's broken. The peer is not respecting our LCP Configure-Reject
    message. We told it not to use those options, and it's still trying
    anyway.

    The peer seems rather insistent that we should be using the flavor of
    BACP that it uses. We don't implement that protocol at all, and we're
    trying to tell the peer that.

    Note also that the peer is trying to convince us to do Multilink PPP
    via the MRRU option and isn't taking our hints about that, either.

    > Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    > ConfReq id=0x4 > mp> ]


    Finally! He's given up on the unwanted options.

    > Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.notice] local IP
    > address 10.9.0.1
    > Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.notice] remote IP
    > address 137.110.0.74


    That part looks like success to me.

    > Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [CCP
    > ConfRej id=0x26]


    That's hilarious. Protesting the empty set?

    > Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [CCP
    > TermReq id=0x2]
    > Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] sent [CCP
    > TermAck id=0x2]


    We agree to disagree about CCP.

    > Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [IPCP
    > TermReq id=0x2]


    The peer gets upset and shuts down IP. There is no indication why it
    might have done this, but I'll bet that it has bugs with its handling
    of CCP failure.

    > Mar 2 17:00:34 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [LCP
    > TermReq id=0x5]


    Peer tells us to shut down.

    I'd suggest adding "noccp" to the options so that the peer gets LCP
    Protocol-Reject instead of seeing a failure to agree on compression
    method.

    Other than that, this is a bug in the peer's side. There's not much
    you can do about it from your side.

    --
    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: LCP rejecting unknown option (solaris 9)

    Thanks, James.
    It is kind of an old box (the sunblade 100) - not sure what vintage, as
    we tend to recycle ones we replace out in the field...

    Noccp didn't get me any further along:

    at the University Netops group, do I say "your PPP has problems with
    CCP"? -- is that where the problem is?>
    Thanks again...
    - Judy

    Mar 2 21:18:00 shel pppd[5890]: [ID 860527 daemon.notice] pppd 2.4.0b1
    (Sun Microsystems, Inc., Mar 13 2003 00:33:58) started by nrts, uid 2000
    Mar 2 21:18:00 shel pppd[5890]: [ID 702911 daemon.debug] serial speed
    set to 38400 bps
    Mar 2 21:18:01 shel pppd[5890]: [ID 702911 daemon.debug] connect
    option: '/usr/bin/chat -v -f /etc/ppp/chat-ucsd-isp' started (pid 5891)
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.info] Serial
    connection established.
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug] serial speed
    set to 38400 bps
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.info] Using interface
    sppp0
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.notice] Connect:
    sppp0 <--> /dev/cua/a
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug]
    /etc/ppp/pap-secrets is apparently empty
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug]
    /etc/ppp/chap-secrets is apparently empty
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0x5e ]
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0x1 < 00 04 00 00>
    ]
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug] LCP: rejecting
    unknown option 0
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug] sent [LCP
    Ident id=0x5f magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Mar 13
    2003 00:33:57)"]
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug] sent [LCP
    ConfRej id=0x1 < 00 04 00 00> ]
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [LCP
    ConfAck id=0x5e ]
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [LCP
    CodeRej id=0x2 0c 5f 00 42 00 00 00 00 70 70 70 2d 32 2e 34 2e 30 62 31
    20 28 53 75 6e 20 4d 69 63 72 6f 73 79 ...]
    Mar 2 21:18:29 shel pppd[5890]: [ID 702911 daemon.warning] LCP: Rcvd
    Code-Reject for Identification id 95
    Mar 2 21:18:32 shel pppd[5890]: [ID 702911 daemon.debug] sent [LCP
    ConfReq id=0x5e ]
    Mar 2 21:18:32 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [LCP
    ConfAck id=0x5e ]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0x3 < 00 04 00 00>
    ]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] LCP: rejecting
    unknown option 0
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] LCP: Peer has
    rejected Identification; not sending another
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] sent [LCP
    ConfRej id=0x3 < 00 04 00 00> ]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [LCP
    ConfReq id=0x4 [MAC:00:c0:7b:7d:96:ab]>]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] sent [LCP
    ConfAck id=0x4 [MAC:00:c0:7b:7d:96:ab]>]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] LCP: Peer has
    rejected Identification; not sending another
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] sent [IPCP
    ConfReq id=0xdf ]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [IPCP
    ConfReq id=0x1 ]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] sent [IPCP
    ConfAck id=0x1 ]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [CCP
    ConfReq id=0x1 ]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.warning] Unsupported
    protocol 0x80fd received
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] sent [LCP
    ProtRej id=0x62 80 fd 01 01 00 0a 11 06 00 01 01 03]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.debug] rcvd [IPCP
    ConfAck id=0xdf ]
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.notice] local IP
    address 10.9.0.1
    Mar 2 21:18:33 shel pppd[5890]: [ID 702911 daemon.notice] remote IP
    address 137.110.0.66
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.debug] rcvd [CCP
    TermReq id=0x2]
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.warning] Unsupported
    protocol 0x80fd received
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.debug] sent [LCP
    ProtRej id=0x63 80 fd 05 02 00 04]
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.debug] rcvd [IPCP
    TermReq id=0x2]
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.info] IPCP terminated
    by peer
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.debug] sent [IPCP
    TermAck id=0x2]
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.debug] rcvd [CBCP
    code=0x5 id=0x1]
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.warning] Unsupported
    protocol 0xc029 received
    Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.debug] sent [LCP
    ProtRej id=0x64 c0 29 05 01 00 04]
    Mar 2 21:18:34 shel pppd[5896]: [ID 702911 daemon.debug] rcvd [LCP
    TermReq id=0x5]
    Mar 2 21:18:34 shel pppd[5896]: [ID 702911 daemon.info] LCP terminated
    by peer
    Mar 2 21:18:34 shel pppd[5896]: [ID 702911 daemon.debug] sent [LCP
    TermAck id=0x5]
    Mar 2 21:18:36 shel pppd[5896]: [ID 702911 daemon.notice] Modem hangup
    Mar 2 21:18:36 shel pppd[5896]: [ID 702911 daemon.notice] Connection
    terminated.
    Mar 2 21:18:36 shel pppd[5896]: [ID 702911 daemon.info] Connect time
    0.1 minutes.
    Mar 2 21:18:36 shel pppd[5896]: [ID 702911 daemon.info] Sent 400 bytes
    (10 packets), received 586 bytes (12 packets).
    Mar 2 21:18:37 shel pppd[5896]: [ID 834084 daemon.info] Exit.



    James Carlson wrote:
    > Judy Illeman Gaukel writes:
    >
    >>Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    >>ConfReq id=0x1 < 00 04 00 00> >>p 0xa0000> >>[MAC:00:c0:7b:5e:9b:47]> ]
    >>Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] LCP:
    >>rejecting unknown option 0
    >>Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] LCP:
    >>rejecting unknown option 23

    >
    >
    > That system is a bit weird. It looks like an old Ascend box to me,
    > though the scripts below suggest that it's an Annex. (How can that
    > be?)
    >
    >
    >>Mar 2 17:00:29 shel pppd[20910]: [ID 702911 daemon.debug] sent [LCP
    >>ConfRej id=0x1 < 00 04 00 00> >>00> ]

    >
    >
    > We correctly tell it that we don't want those options.
    >
    >
    >>Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    >>ConfReq id=0x3 < 00 04 00 00> >>p 0xa0000> >>[MAC:00:c0:7b:5e:9b:47]> ]

    >
    >
    > That's broken. The peer is not respecting our LCP Configure-Reject
    > message. We told it not to use those options, and it's still trying
    > anyway.
    >
    > The peer seems rather insistent that we should be using the flavor of
    > BACP that it uses. We don't implement that protocol at all, and we're
    > trying to tell the peer that.
    >
    > Note also that the peer is trying to convince us to do Multilink PPP
    > via the MRRU option and isn't taking our hints about that, either.
    >
    >
    >>Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.debug] rcvd [LCP
    >>ConfReq id=0x4 >>mp> ]

    >
    >
    > Finally! He's given up on the unwanted options.
    >
    >
    >>Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.notice] local IP
    >>address 10.9.0.1
    >>Mar 2 17:00:33 shel pppd[20910]: [ID 702911 daemon.notice] remote IP
    >>address 137.110.0.74

    >
    >
    > That part looks like success to me.
    >
    >
    >>Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [CCP
    >>ConfRej id=0x26]

    >
    >
    > That's hilarious. Protesting the empty set?
    >
    >
    >>Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [CCP
    >>TermReq id=0x2]
    >>Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] sent [CCP
    >>TermAck id=0x2]

    >
    >
    > We agree to disagree about CCP.
    >
    >
    >>Mar 2 17:00:33 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [IPCP
    >>TermReq id=0x2]

    >
    >
    > The peer gets upset and shuts down IP. There is no indication why it
    > might have done this, but I'll bet that it has bugs with its handling
    > of CCP failure.
    >
    >
    >>Mar 2 17:00:34 shel pppd[20915]: [ID 702911 daemon.debug] rcvd [LCP
    >>TermReq id=0x5]

    >
    >
    > Peer tells us to shut down.
    >
    > I'd suggest adding "noccp" to the options so that the peer gets LCP
    > Protocol-Reject instead of seeing a failure to agree on compression
    > method.
    >
    > Other than that, this is a bug in the peer's side. There's not much
    > you can do about it from your side.
    >


  4. Re: LCP rejecting unknown option (solaris 9)

    Judy Illeman Gaukel writes:
    > It is kind of an old box (the sunblade 100) - not sure what vintage,
    > as we tend to recycle ones we replace out in the field...


    I don't think that should make a difference.

    > Noccp didn't get me any further along:


    It was a bit of a long shot. Here's another perhaps better one to try
    -- use "noipdefault." I notice that you're telling your peer that
    your address is 10.9.0.1, and it seems to agree. That's perfectly
    legal in terms of PPP negotiation, but it's sort of unusual.

    (Perhaps the peer agrees to the address, and then later does some sort
    of 'security' check and decides that you shouldn't have that address,
    and shuts the link down. It's a possibility.)

    > > PPP at the University Netops group, do I say "your PPP has problems
    > with CCP"? -- is that where the problem is?>


    I would show that person the debug log file, as it tells the whole
    story. The key part to point out is this:

    > Mar 2 21:18:33 shel pppd[5896]: [ID 702911 daemon.debug] rcvd [IPCP
    > TermReq id=0x2]


    The peer is shutting down IPCP, and isn't really providing any obvious
    reason why it should shut it down. The only device here that would
    know why it chose to do that would be the peer device, so if that
    PPP-speaking person exists, he'd have to look at the debug logs for
    the system to which you're connecting.

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

  5. Re: LCP rejecting unknown option (solaris 9)

    James Carlson wrote:
    > Judy Illeman Gaukel writes:
    >


    > It was a bit of a long shot. Here's another perhaps better one to try
    > -- use "noipdefault." I notice that you're telling your peer that
    > your address is 10.9.0.1, and it seems to agree. That's perfectly
    > legal in terms of PPP negotiation, but it's sort of unusual.
    >
    > (Perhaps the peer agrees to the address, and then later does some sort
    > of 'security' check and decides that you shouldn't have that address,
    > and shuts the link down. It's a possibility.)
    >
    >

    Hi James,

    Well, there you go. I guess the peer does indeed have some security
    issue, since it works fine when I put noipdefault in place.
    Thank you (once again!) for your speedy help. (woo hoo!)
    - Judy

+ Reply to Thread