Date: Thu, 04 Apr 2002 20:17:45 +0100 From: Brian Somers <brian@freebsd-services.com> To: Thomas Quinot <thomas@cuivre.fr.eu.org> Cc: freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Userland ppp hung in Ack-Rcvd Message-ID: <200204041917.g34JHjq7038873@hak.lan.Awfulhak.org> In-Reply-To: Message from Thomas Quinot <thomas@cuivre.fr.eu.org> of "Wed, 03 Apr 2002 09:06:58 %2B0200." <20020403090658.A65499@melusine.cuivre.fr.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I observed a peculiar situation today on an ADSL link using pptpclient
> and the userland ppp daemon: the LCP negociation hunk in state
> Ack-Rcvd for almost 3 hours (until I killed it) without any progress,
> but without timing out, either.
>
> Here is an excerpt from the log:
>
> Apr 3 05:25:02 melusine ppp[53064]: tun0: LCP: deflink: State change Initial --> Closed
> Apr 3 05:25:02 melusine ppp[53064]: tun0: LCP: deflink: State change Closed --> Stopped
> Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: LayerStart
> Apr 3 05:25:03 melusine ppp[53064]: tun0: Warning: deflink: Reducing configured MRU from 1500 to 1480
> Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped
> Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: ACFCOMP[2]
> Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2]
> Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000
> Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: MRU[4] 1480
> Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe
> Apr 3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: State change
> Stopped --> Req-Sent
> Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent
> Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: ACFCOMP[2]
> Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2]
> Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000
> Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: MRU[4] 1480
> Apr 3 05:25:06 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe
> Apr 3 05:25:09 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent
> Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: ACFCOMP[2]
> Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: PROTOCOMP[2]
> Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: ACCMAP[6] 0x00000000
> Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: MRU[4] 1480
> Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: MAGICNUM[6] 0x91e371fe
> Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: deflink: RecvConfigAck(1) state = Req-Sent
> Apr 3 05:25:10 melusine ppp[53064]: tun0: LCP: deflink: State change Req-Sent --> Ack-Rcvd
> Apr 3 08:11:27 melusine ppp[53064]: tun0: Phase: Signal 15, terminate.
>
> In other sessions that I have a trace of, I never enter Ack-Recvd,
> but instead:
>
> Apr 3 08:12:07 melusine ppp[61776]: tun0: LCP: deflink: RecvConfigReq(224) state = Req-Sent
>
> This box is running 4.5-STABLE kernel and world cvsuppsed 10 days or so
> ago. Any idea why it did not time out?
>
> Thomas.
It looks like the peer responded to our req, but never sent a req of
it's own. In this scenario, ppp should enter Ack-Rcvd from Req-Sent
due to the RCA event and initialise it's restart counter. Examining
the code implies that it's doing this (FsmRecvConfigAck() in fsm.c).
Therefore something else must have jammed things up. If you have a
diagnostic socket configured, it's worth using pppctl to connect to
it and see if that wakes up ppp - or at least if ``show timer''
indicates that the timers are running (run ``show timer'' a few times
and note the timeouts decrementing).
If it doesn't wake things up or you can't connect, killing ppp with a
-11 and examining the core dump is the only option.... but you'll
need symbols in the binary. I add CFLAGS=-g and STRIP= to the
Makefile to achieve this.
> --
> Thomas.Quinot@Cuivre.FR.EU.ORG
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204041917.g34JHjq7038873>