Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IPCP gets interrupted suddenly

14 views
Skip to first unread message

alessandro...@gmail.com

unread,
Sep 28, 2012, 1:27:13 PM9/28/12
to
Hi everybody,

I'm fighting against an IPCP issue which I've never seen. I'm working on
a Debian 5.0 (lenny) distribution with PPPD v.2.

After a successfully PAP autentication, my computer starts IPCP by sending option
0x01 (IP addresses) with all zeroes (I want my address and DNS addresses set by
server).
The second frame I see is the server proposal of its address which is immediately
acknoledged.
What I would expect is an acknoledge of server at my first request which never
arrives. Then PPPD hangs up the line.

Following you can find the log of the conversation:

Serial connection established.
using channel 14
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS4
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c32b350> <pcomp> <accomp>]
rcvd [LCP ConfRej id=0x1 <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x9c32b350>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xe8d43500>]
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xe8d43500>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0x9c32b350>]
sent [LCP EchoReq id=0x0 magic=0x9c32b350]
sent [PAP AuthReq id=0x1 user="pippo" password="pluto"]
rcvd [LCP EchoRep id=0x0 magic=0x16d53500]
rcvd [PAP AuthAck id=0x1 "Welcome!"]
Remote message: Welcome!
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <addr 192.168.202.1>]
sent [IPCP ConfAck id=0x1 <addr 192.168.202.1>]
Hangup (SIGHUP)
Modem hangup
Connection terminated.

Any idea ?

Best Regards

/Alessandro

Moe Trin

unread,
Sep 28, 2012, 9:16:53 PM9/28/12
to
On Fri, 28 Sep 2012, in the Usenet newsgroup comp.os.linux.networking, in
article <1e69ee9d-4a39-4f00...@googlegroups.com>,
alessandro...@gmail.com wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

I see you also posted this to comp.protocols.ppp - please don't post
the same article to multiple newsgroups.

>I'm fighting against an IPCP issue which I've never seen. I'm working
>on a Debian 5.0 (lenny) distribution with PPPD v.2.

Lenny is a bit on the old side - squeeze was released early last year.
I'm guessing that's ppp-2.4.4 or 2.4.5, but it's not really critical.

>After a successfully PAP autentication, my computer starts IPCP by
>sending option 0x01 (IP addresses) with all zeroes (I want my address
>and DNS addresses set by server).

Close enough Is this an ISP with a plain old telephone modem or is
this a digital GPRS or similar?

>The second frame I see is the server proposal of its address which is
>immediately acknoledged.
>What I would expect is an acknoledge of server at my first request
>which never arrives. Then PPPD hangs up the line.

>sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c32b350> <pcomp>
> <accomp>]
>rcvd [LCP ConfRej id=0x1 <pcomp> <accomp>]

Hmmmmm.... Any idea why the peer doesn't want header compression?

>rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xe8d43500>]
>sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xe8d43500>]
>rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0x9c32b350>]
>sent [LCP EchoReq id=0x0 magic=0x9c32b350]
>sent [PAP AuthReq id=0x1 user="pippo" password="pluto"]
>rcvd [LCP EchoRep id=0x0 magic=0x16d53500]

Any particular reason you are using LCP Echos? The reply is garbled
(magic should be 0xe8d43500 - see RFC1661 sections 5.8 and 6.4) which
could be a serial link problem.

>rcvd [PAP AuthAck id=0x1 "Welcome!"]
>Remote message: Welcome!
>PAP authentication succeeded
>sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0>
> <ms-dns3 0.0.0.0>]
>rcvd [IPCP ConfReq id=0x1 <addr 192.168.202.1>]
>sent [IPCP ConfAck id=0x1 <addr 192.168.202.1>]
>Hangup (SIGHUP)
>Modem hangup

Are the packets received in a timely manner? Or are there excessive
delays?

>Any idea ?

default-asyncmap
Disable asyncmap negotiation, forcing all control characters
to be escaped for both the transmit and the receive direc-
tion.

See if that option helps.

Old guy
0 new messages