Protocol-Rej not received

Discussion:

(too old to reply)

k***@gmail.com

2006-11-04 05:15:49 UTC

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 <auth pap>]
sent [LCP ConfAck id=0x1]
rcvd [LCP ConfAck id=0x1 <auth pap>]
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 <auth pap>]
sent [LCP ConfAck id=0x1]
rcvd [LCP ConfAck id=0x1 <auth pap>]
sent [LCP EchoReq id=0x0 magic=0x0]
rcvd [PAP AuthReq id=0x1 user="root" password=<hidden>]
sent [PAP AuthAck id=0x1 "Login ok"]
PAP peer authentication succeeded for root
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
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 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [LCP EchoReq id=0x1 magic=0x0]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
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

2006-11-04 18:34:51 UTC

Permalink

Post by k***@gmail.com
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.

Post by k***@gmail.com
I am using Fedora Core 3.
======
Using interface ppp0
Connect: ppp0 <--> /dev/pts/6
rcvd [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1 <auth pap>]
sent [LCP ConfAck id=0x1]
rcvd [LCP ConfAck id=0x1 <auth pap>]
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.
=====
Using interface ppp0
Connect: ppp0 <--> /dev/pts/6
rcvd [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1 <auth pap>]
sent [LCP ConfAck id=0x1]
rcvd [LCP ConfAck id=0x1 <auth pap>]
sent [LCP EchoReq id=0x0 magic=0x0]
rcvd [PAP AuthReq id=0x1 user="root" password=<hidden>]
sent [PAP AuthAck id=0x1 "Login ok"]
PAP peer authentication succeeded for root
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
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 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [LCP EchoReq id=0x1 magic=0x0]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
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. */

k***@gmail.com

2006-11-05 08:31:04 UTC

Permalink

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

Post by Clifford Kite

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

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

Clifford Kite

2006-11-05 18:40:25 UTC

Permalink

Post by k***@gmail.com
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.

...

Post by k***@gmail.com

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

Clifford Kite

2006-11-06 15:31:27 UTC

Permalink

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

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

k***@gmail.com

2006-11-07 16:02:23 UTC

Permalink

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

Post by Clifford Kite

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

Clifford Kite

2006-11-07 19:56:11 UTC

Permalink

This post might be inappropriate. Click to display it.

James Carlson

2006-11-07 21:01:32 UTC

Permalink

Post by Clifford Kite
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.com>
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