Protocol-Rej not received - PPP

This is a discussion on Protocol-Rej not received - PPP ; Hi, I have provided logs of two connections. With the first connection I don't receive a protocol-reject packet when I sent LCP packet with unknown protocol. As per RFC 1661 in the opened state ppp should send a protocol reject ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Protocol-Rej not received

  1. Protocol-Rej not received

    Hi,
    I have provided logs of two connections. With the first connection I
    don't receive a protocol-reject packet
    when I sent LCP packet with unknown protocol. As per RFC 1661 in the
    opened state ppp should send a protocol reject when it receives a LCP
    packet with unknown protocol. I believe that in this case the ppp is
    in opened state before sending the LCP packet with unknown protocol,
    since a Config-Ack has been both sent and received.

    Now with the second log, the ppp sends a protocol-reject packet when we
    send a LCP packet with unknown code after the authentication phase. I
    want to know why this happens and is it correct.

    I am using Fedora Core 3.

    Log 1:
    ======
    Using interface ppp0
    Connect: ppp0 <--> /dev/pts/6
    rcvd [LCP ConfReq id=0x1]
    sent [LCP ConfReq id=0x1 ]
    sent [LCP ConfAck id=0x1]
    rcvd [LCP ConfAck id=0x1 ]
    sent [LCP EchoReq id=0x0 magic=0x0]
    rcvd [proto=0x80ff] 01 01 00 04
    discarding proto 0x80ff in phase 5
    sent [LCP EchoReq id=0x1 magic=0x0]
    No response to 2 echo-requests
    Serial link appears to be disconnected.
    sent [LCP TermReq id=0x2 "Peer not responding"]
    sent [LCP TermReq id=0x3 "Peer not responding"]
    Connection terminated.

    Log 2:
    =====
    Using interface ppp0
    Connect: ppp0 <--> /dev/pts/6
    rcvd [LCP ConfReq id=0x1]
    sent [LCP ConfReq id=0x1 ]
    sent [LCP ConfAck id=0x1]
    rcvd [LCP ConfAck id=0x1 ]
    sent [LCP EchoReq id=0x0 magic=0x0]
    rcvd [PAP AuthReq id=0x1 user="root" password=]
    sent [PAP AuthAck id=0x1 "Login ok"]
    PAP peer authentication succeeded for root
    sent [IPCP ConfReq id=0x1 ]
    rcvd [proto=0x80ff] 01 01 00 04
    Unsupported protocol 0x80ff received
    sent [LCP ProtRej id=0x2 80 ff 01 01 00 04]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [LCP EchoReq id=0x1 magic=0x0]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    No response to 2 echo-requests
    Serial link appears to be disconnected.
    sent [LCP TermReq id=0x3 "Peer not responding"]
    sent [LCP TermReq id=0x4 "Peer not responding"]
    Connection terminated.

    Thanks in advance.
    Sriram K


  2. Re: Protocol-Rej not received

    ksriram29@gmail.com wrote:
    > Hi,
    > I have provided logs of two connections. With the first connection
    > I don't receive a protocol-reject packet when I sent LCP packet
    > with unknown protocol. As per RFC 1661 in the opened state ppp
    > should send a protocol reject when it receives a LCP packet with
    > unknown protocol. I believe that in this case the ppp is in opened
    > state before sending the LCP packet with unknown protocol, since
    > a Config-Ack has been both sent and received.


    > Now with the second log, the ppp sends a protocol-reject packet
    > when we send a LCP packet with unknown code after the authentication
    > phase. I want to know why this happens and is it correct.


    Because ..it happens? %^) In the first case LCP negotiation is Stopping,
    not Open (phase 5 in the log), so it is correct.

    > I am using Fedora Core 3.


    > Log 1:
    > ======
    > Using interface ppp0
    > Connect: ppp0 <--> /dev/pts/6
    > rcvd [LCP ConfReq id=0x1]
    > sent [LCP ConfReq id=0x1 ]
    > sent [LCP ConfAck id=0x1]
    > rcvd [LCP ConfAck id=0x1 ]
    > sent [LCP EchoReq id=0x0 magic=0x0]
    > rcvd [proto=0x80ff] 01 01 00 04
    > discarding proto 0x80ff in phase 5
    > sent [LCP EchoReq id=0x1 magic=0x0]
    > No response to 2 echo-requests
    > Serial link appears to be disconnected.
    > sent [LCP TermReq id=0x2 "Peer not responding"]
    > sent [LCP TermReq id=0x3 "Peer not responding"]
    > Connection terminated.


    > Log 2:
    > =====
    > Using interface ppp0
    > Connect: ppp0 <--> /dev/pts/6
    > rcvd [LCP ConfReq id=0x1]
    > sent [LCP ConfReq id=0x1 ]
    > sent [LCP ConfAck id=0x1]
    > rcvd [LCP ConfAck id=0x1 ]
    > sent [LCP EchoReq id=0x0 magic=0x0]
    > rcvd [PAP AuthReq id=0x1 user="root" password=]
    > sent [PAP AuthAck id=0x1 "Login ok"]
    > PAP peer authentication succeeded for root
    > sent [IPCP ConfReq id=0x1 ]
    > rcvd [proto=0x80ff] 01 01 00 04
    > Unsupported protocol 0x80ff received
    > sent [LCP ProtRej id=0x2 80 ff 01 01 00 04]
    > sent [IPCP ConfReq id=0x1 ]
    > sent [IPCP ConfReq id=0x1 ]
    > sent [IPCP ConfReq id=0x1 ]
    > sent [LCP EchoReq id=0x1 magic=0x0]
    > sent [IPCP ConfReq id=0x1 ]
    > sent [IPCP ConfReq id=0x1 ]
    > sent [IPCP ConfReq id=0x1 ]
    > No response to 2 echo-requests
    > Serial link appears to be disconnected.
    > sent [LCP TermReq id=0x3 "Peer not responding"]
    > sent [LCP TermReq id=0x4 "Peer not responding"]
    > Connection terminated.


    > Thanks in advance.
    > Sriram K



    --
    Clifford Kite
    /* 97.3% of all statistics are made up. */

  3. Re: Protocol-Rej not received

    Thanks Clifford for your reply. But it should be in the opened state
    when a config-req has been both sent and received, isn't it? Thats
    what the RFC 1661 says.

    -Sriram K
    Clifford Kite wrote:
    > ksriram29@gmail.com wrote:
    > > Hi,
    > > I have provided logs of two connections. With the first connection
    > > I don't receive a protocol-reject packet when I sent LCP packet
    > > with unknown protocol. As per RFC 1661 in the opened state ppp
    > > should send a protocol reject when it receives a LCP packet with
    > > unknown protocol. I believe that in this case the ppp is in opened
    > > state before sending the LCP packet with unknown protocol, since
    > > a Config-Ack has been both sent and received.

    >
    > > Now with the second log, the ppp sends a protocol-reject packet
    > > when we send a LCP packet with unknown code after the authentication
    > > phase. I want to know why this happens and is it correct.

    >
    > Because ..it happens? %^) In the first case LCP negotiation is Stopping,
    > not Open (phase 5 in the log), so it is correct.
    >
    > > I am using Fedora Core 3.

    >
    > > Log 1:
    > > ======
    > > Using interface ppp0
    > > Connect: ppp0 <--> /dev/pts/6
    > > rcvd [LCP ConfReq id=0x1]
    > > sent [LCP ConfReq id=0x1 ]
    > > sent [LCP ConfAck id=0x1]
    > > rcvd [LCP ConfAck id=0x1 ]
    > > sent [LCP EchoReq id=0x0 magic=0x0]
    > > rcvd [proto=0x80ff] 01 01 00 04
    > > discarding proto 0x80ff in phase 5
    > > sent [LCP EchoReq id=0x1 magic=0x0]
    > > No response to 2 echo-requests
    > > Serial link appears to be disconnected.
    > > sent [LCP TermReq id=0x2 "Peer not responding"]
    > > sent [LCP TermReq id=0x3 "Peer not responding"]
    > > Connection terminated.

    >
    > > Log 2:
    > > =====
    > > Using interface ppp0
    > > Connect: ppp0 <--> /dev/pts/6
    > > rcvd [LCP ConfReq id=0x1]
    > > sent [LCP ConfReq id=0x1 ]
    > > sent [LCP ConfAck id=0x1]
    > > rcvd [LCP ConfAck id=0x1 ]
    > > sent [LCP EchoReq id=0x0 magic=0x0]
    > > rcvd [PAP AuthReq id=0x1 user="root" password=]
    > > sent [PAP AuthAck id=0x1 "Login ok"]
    > > PAP peer authentication succeeded for root
    > > sent [IPCP ConfReq id=0x1 ]
    > > rcvd [proto=0x80ff] 01 01 00 04
    > > Unsupported protocol 0x80ff received
    > > sent [LCP ProtRej id=0x2 80 ff 01 01 00 04]
    > > sent [IPCP ConfReq id=0x1 ]
    > > sent [IPCP ConfReq id=0x1 ]
    > > sent [IPCP ConfReq id=0x1 ]
    > > sent [LCP EchoReq id=0x1 magic=0x0]
    > > sent [IPCP ConfReq id=0x1 ]
    > > sent [IPCP ConfReq id=0x1 ]
    > > sent [IPCP ConfReq id=0x1 ]
    > > No response to 2 echo-requests
    > > Serial link appears to be disconnected.
    > > sent [LCP TermReq id=0x3 "Peer not responding"]
    > > sent [LCP TermReq id=0x4 "Peer not responding"]
    > > Connection terminated.

    >
    > > Thanks in advance.
    > > Sriram K

    >
    >
    > --
    > Clifford Kite
    > /* 97.3% of all statistics are made up. */



  4. Re: Protocol-Rej not received

    ksriram29@gmail.com wrote:
    > Thanks Clifford for your reply. But it should be in the opened state
    > when a config-req has been both sent and received, isn't it? Thats
    > what the RFC 1661 says.


    Ouch! You're right.

    Assuming the chronological order of events is reflected message order,
    the invalid protocol is discarded between LCP Echo-Requests and so LCP
    must still be in the Opened state. The "phase 5" message is misleading
    but that's not an excuse for my carelessness. Sorry.

    ....

    >> > I am using Fedora Core 3.

    >>
    >> > Log 1:
    >> > ======
    >> > Using interface ppp0
    >> > Connect: ppp0 <--> /dev/pts/6
    >> > rcvd [LCP ConfReq id=0x1]
    >> > sent [LCP ConfReq id=0x1 ]
    >> > sent [LCP ConfAck id=0x1]
    >> > rcvd [LCP ConfAck id=0x1 ]
    >> > sent [LCP EchoReq id=0x0 magic=0x0]
    >> > rcvd [proto=0x80ff] 01 01 00 04
    >> > discarding proto 0x80ff in phase 5
    >> > sent [LCP EchoReq id=0x1 magic=0x0]


    --
    Clifford Kite
    /* For every credibility gap, there is a gullibility fill.
    -- R. Clopton */

  5. Re: Protocol-Rej not received

    Clifford Kite wrote:

    > Assuming the chronological order of events is reflected in message order,
    > the invalid protocol is discarded between LCP Echo-Requests and so LCP
    > must still be in the Opened state. The "phase 5" message is misleading
    > but that's not an excuse for my carelessness. Sorry.


    > ...


    >>> > I am using Fedora Core 3.
    >>>
    >>> > Log 1:
    >>> > ======
    >>> > Using interface ppp0
    >>> > Connect: ppp0 <--> /dev/pts/6
    >>> > rcvd [LCP ConfReq id=0x1]
    >>> > sent [LCP ConfReq id=0x1 ]
    >>> > sent [LCP ConfAck id=0x1]
    >>> > rcvd [LCP ConfAck id=0x1 ]
    >>> > sent [LCP EchoReq id=0x0 magic=0x0]
    >>> > rcvd [proto=0x80ff] 01 01 00 04
    >>> > discarding proto 0x80ff in phase 5
    >>> > sent [LCP EchoReq id=0x1 magic=0x0]


    Ah.. The code for pppd 2.4.4 in main.c contains:

    pppd/main.c: * Until we get past the authentication phase, toss all packets
    pppd/main.c: if (phase <= PHASE_AUTHENTICATE
    pppd/main.c: dbglog("discarding proto 0x%x in phase %d",
    pppd/main.c: protocol, phase);

    which is not RFC 1661 compliant - if I interpret the code correctly.

    --
    Clifford Kite
    /* Those who can't write, write manuals. */

  6. Re: Protocol-Rej not received

    I got the protocol-rej for the first case (log 1). I tried giving
    noauth as pppd option
    and got the protocol-rej. I don't understand how pppd treats the noauth
    option and
    commenting out the require-pap/require-chap lines in the options file.

    Thank you all.

    Sriram K
    Clifford Kite wrote:
    > Clifford Kite wrote:
    >
    > > Assuming the chronological order of events is reflected in message order,
    > > the invalid protocol is discarded between LCP Echo-Requests and so LCP
    > > must still be in the Opened state. The "phase 5" message is misleading
    > > but that's not an excuse for my carelessness. Sorry.

    >
    > > ...

    >
    > >>> > I am using Fedora Core 3.
    > >>>
    > >>> > Log 1:
    > >>> > ======
    > >>> > Using interface ppp0
    > >>> > Connect: ppp0 <--> /dev/pts/6
    > >>> > rcvd [LCP ConfReq id=0x1]
    > >>> > sent [LCP ConfReq id=0x1 ]
    > >>> > sent [LCP ConfAck id=0x1]
    > >>> > rcvd [LCP ConfAck id=0x1 ]
    > >>> > sent [LCP EchoReq id=0x0 magic=0x0]
    > >>> > rcvd [proto=0x80ff] 01 01 00 04
    > >>> > discarding proto 0x80ff in phase 5
    > >>> > sent [LCP EchoReq id=0x1 magic=0x0]

    >
    > Ah.. The code for pppd 2.4.4 in main.c contains:
    >
    > pppd/main.c: * Until we get past the authentication phase, toss all packets
    > pppd/main.c: if (phase <= PHASE_AUTHENTICATE
    > pppd/main.c: dbglog("discarding proto 0x%x in phase %d",
    > pppd/main.c: protocol, phase);
    >
    > which is not RFC 1661 compliant - if I interpret the code correctly.
    >
    > --
    > Clifford Kite
    > /* Those who can't write, write manuals. */



  7. Re: Protocol-Rej not received

    ksriram29@gmail.com wrote:
    > I got the protocol-rej for the first case (log 1). I tried
    > giving noauth as pppd option and got the protocol-rej. I don't
    > understand how pppd treats the noauth option and commenting out
    > the require-pap/require-chap lines in the options file.


    In the first case you were the authenticator and in the second you
    were the authenticatee. Noauth means pppd won't require the peer
    to authenticate, and commenting out any existing require-pap or
    require-chap options prevents conflict with noauth. The options
    are described in the pppd man pages.

    The maintainer of pppd apparently decided that when pppd acts as
    authenticator it was best, after the peer agrees to authenticate,
    to require the authentication take place before responding to it in
    any other way.

    --
    Clifford Kite
    /* Editing with vi is a lot better than using a huge swiss army knife.
    Use =} to wrap paragraphs in vi. Or put map ^] !}fmt -72^M in
    ~/.exrc and use ^] to wrap to 72 columns or whatever you choose. */

  8. Re: Protocol-Rej not received

    Clifford Kite writes:
    > The maintainer of pppd apparently decided that when pppd acts as
    > authenticator it was best, after the peer agrees to authenticate,
    > to require the authentication take place before responding to it in
    > any other way.


    Speaking as one of those maintainers ... ;-}

    Yes. The issue here is with interoperability. If the peer jumps the
    gun and tries to do IPCP at the same time as authentication, then
    discarding his IPCP Configure-Request messages as though we'd never
    seen them causes the right thing to happen. If we were to send
    Protocol-Reject instead, then we'd refuse to interoperate with such a
    system, because we'd destroy his IPCP state and likely cause him to
    tear down the link.

    Note that a problem like this can occur on a simple retransmit.
    Consider the case where authentication *does* take place, but we lose
    one of the packets. If the peer races on to do IPCP, we could get
    IPCP negotiation messages while we still think we're doing
    authentication. This would result in link failure.

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

+ Reply to Thread