LCP ProtRej, where could I lookup error codes?
Robert Wachinger
I tried to setup a GPRS connection (SuSE 8.1 Linux and a Siemens S55 mobilephone,
connected via an USB cable). Seems, that I got some connection to my provider,
but then I see this communication:
...
pppd[27301]: rcvd [CHAP Success id=0x1 ""]
pppd[27301]: sent [IPCP ConfReq id=0x1 <addr 192.168.98.20>]
pppd[27301]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
pppd[27301]: rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 0f 1a 04 78 00 18 04 78]
pppd[27301]: rcvd [LCP TermReq id=0x5]
pppd[27301]: LCP terminated by peer
pppd[27301]: cbcp_lowerdown
pppd[27301]: sent [LCP TermAck id=0x5]
pppd[27301]: Connection terminated.
This looks to me, that my provider doesn't like some ConfReq, but which one?
Where could I lookup, what this LCP ProtRej wants to say to me?
Any help and hints are appreciated.
Thank you in advance, Robert
Clifford Kite
> I tried to setup a GPRS connection (SuSE 8.1 Linux and a Siemens
> S55 mobilephone, connected via an USB cable). Seems, that I got
> some connection to my provider,
> but then I see this communication:
> ...
> pppd[27301]: rcvd [CHAP Success id=0x1 ""]
> pppd[27301]: sent [IPCP ConfReq id=0x1 <addr 192.168.98.20>]
> pppd[27301]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>
> <bsd v1 15>] ^^^
> pppd[27301]: rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 0f 1a 04 78 00 18
> 04 78]
> pppd[27301]: rcvd [LCP TermReq id=0x5]
> pppd[27301]: LCP terminated by peer
> pppd[27301]: cbcp_lowerdown
> pppd[27301]: sent [LCP TermAck id=0x5]
> pppd[27301]: Connection terminated.
> This looks to me, that my provider doesn't like some ConfReq, but
> which one? Where could I lookup, what this LCP ProtRej wants to
> say to me?
It is simply the peer rejecting CCP, Compression Control Protocol.
That's not why you didn't get a viable PPP link. The answer might
be in the "..." section. But PPP negotation for a GPRS connection
can be funky and you may need an answer from someone intimate with
PPP/GPRS to identify the problem. That wouldn't be me.
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
James Carlson
> I tried to setup a GPRS connection (SuSE 8.1 Linux and a Siemens S55 mobilephone,
> connected via an USB cable).
GPRS (as Clifford Kite noted) is funky.
> pppd[27301]: rcvd [CHAP Success id=0x1 ""]
> pppd[27301]: sent [IPCP ConfReq id=0x1 <addr 192.168.98.20>]
This is almost certainly the problem. You're suggesting an IP address
for yourself to the peer, and GPRS systems are quite oddly finicky
about such things. (Standards-compliant systems would merely
Configure-Nak this with the right value and drive on ...)
Try adding "noipdefault" to your configuration. That should cure the
above problem.
> pppd[27301]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
> pppd[27301]: rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 0f 1a 04 78 00 18 04 78]
That's completely harmless, and a normal part of negotiation. If it
bothers you, add "noccp" to the configuration.
> This looks to me, that my provider doesn't like some ConfReq, but which one?
> Where could I lookup, what this LCP ProtRej wants to say to me?
Protocol numbers are here:
http://www.iana.org/assignments/ppp-numbers
--
James Carlson, Solaris Networking <james.d...@sun.com>
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
Alan J. McFarlane
> Robert Wachinger <nos...@robert-wachinger.de> wrote:
[...]
>> pppd[27301]: sent [CCP ConfReq id=0x1 <deflate 15>
>> <deflate(old#) 15> <bsd v1 15>] ^^^
>> pppd[27301]: rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 0f 1a 04 78 00
>> 18 04 78]
>> This looks to me, that my provider doesn't like some ConfReq, but
>> which one? Where could I lookup, what this LCP ProtRej wants to
>> say to me?
>
> It is simply the peer rejecting CCP, Compression Control Protocol.
>
undecoded? Couldn't it, at the very least, decode the Protocol Number so
that it would be apparent to the user what line was being rejected without
having to manually finding the Protocol Numbers of all the previous lines.
Thus in this case printing "CCP" in the ProtRej line (for 80fd).
--
Alan J. McFarlane
http://homepage.ntlworld.com/alanjmcf/
Please follow-up in the newsgroup for the benefit of all.
James Carlson
> Is there a reason why pppd's logging prints the ProtRej frame wholely
> undecoded?
No good reason. It probably should do that ...
> Couldn't it, at the very least, decode the Protocol Number so
> that it would be apparent to the user what line was being rejected without
> having to manually finding the Protocol Numbers of all the previous lines.
> Thus in this case printing "CCP" in the ProtRej line (for 80fd).
Sure. Of course, pppd can't know *all* possible protocol numbers
(some are proprietary), so decoding will always be incomplete.
Alan J. McFarlane
> "Alan J. McFarlane" <alan...@yahoo.com.INVALID> writes:
>> Is there a reason why pppd's logging prints the ProtRej frame wholely
>> undecoded?
>
> No good reason. It probably should do that ...
>
>> Couldn't it, at the very least, decode the Protocol Number so
>> that it would be apparent to the user what line was being rejected
>> without having to manually finding the Protocol Numbers of all the
>> previous lines. Thus in this case printing "CCP" in the ProtRej line
>> (for 80fd).
>
> Sure. Of course, pppd can't know *all* possible protocol numbers
> (some are proprietary), so decoding will always be incomplete.
>
I was only really considered the logging the receipt of a ProtRej. In that
case the local side would know the Protocol Number because it produced the
frame being rejected. I suppose these two operations may not share Protocol
Number decoding code though...
Now, on thinking about the logging when sending a ProtRej. Won't it be the
case that either the Protocol Number is known and then both the CfgReq (etc)
and the ProtRej line can be decoded. Or not and then both lines will be
undecoded. There shouldn't be a case where one line is decodable and one
not. I think...
James Carlson
> I was only really considered the logging the receipt of a ProtRej. In that
> case the local side would know the Protocol Number because it produced the
> frame being rejected. I suppose these two operations may not share Protocol
> Number decoding code though...
They can. Actually, what I was worried about there is compression
failure and dealing with misbehaving peers -- it's not unusual to
receive rejects for things that you never really sent. (!)
> Now, on thinking about the logging when sending a ProtRej. Won't it be the
> case that either the Protocol Number is known and then both the CfgReq (etc)
> and the ProtRej line can be decoded. Or not and then both lines will be
> undecoded. There shouldn't be a case where one line is decodable and one
> not. I think...
Yes, I agree that the existing message can be spruced up quite a bit,
and the misleading nature of it (it looks like a "failure" to folks
who haven't read all of the RFCs) could be improved. I'll look at it ...