Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Sep 2000 20:26:58 +0100
From:      Brian Somers <brian@Awfulhak.org>
To:        "Michael Kuzmin" <kuzmin@laser.ru>
Cc:        "Brian Somers" <brian@Awfulhak.org>, freebsd-net@FreeBSD.org, brian@Awfulhak.org
Subject:   Re: Dying multi-link PPP 
Message-ID:  <200009211926.e8LJQws65571@hak.lan.Awfulhak.org>
In-Reply-To: Message from "Michael Kuzmin" <kuzmin@laser.ru>  of "Thu, 21 Sep 2000 13:16:08 %2B0400." <009801c023ae$078c70e0$1e0657c2@w9g8j7> 

next in thread | previous in thread | raw e-mail | index | archive | help
> >> Our configuration is fairly standard, user-ppp with two modems and MP
> >> enabled at both sides of the channel (see ppp.conf below), the only
> >> pecularity is frequent redials due to telco (30 min call limit).  It always
> >> works OK after reload and initial connects, but subsequent modem redials
> >> amont to accumulation of problems and performance degradation with
> >> unavoidable death in several hours.
> >>
> >> The usual final (dead) state of the channel is an infinite series of short
> >> connects each with LCP RecvTerminateReq in 15 sec after successful
> >> authorization and lcp -> open.  The origin of this dead state could be
> >> tentitavely traced to simultaneous redial of both modem links, at that
> >> moment old ppp master at answering side exits and all new ppp processes
> >> born after that seems to unable to continue...
> > [.....]
> >
> > I think the first thing to find out is why the SendTerminateReq is
> > being sent.  If you enable debug, lcp, ipcp & tcp/ip logs on that end
> > (the server?), hopefully we'll see why it thinks it's a good idea to
> > give up.
> >
> > You could also try
> >
> >   disable pred1 deflate
> >   deny pred1 deflate
> >
> > in your mpd profile - I believe there may be a problem with compression
> > at the moment.
> 
> Thank you for this idea - I'll try it a bit later.
> Meanwhile, it should be noted that we really _have_ many CCP-related errors
> in logs, e.g. sequenses like that
> 
> 15:56:30 atd ppp[336]: tun0: CCP: mp: RecvResetReq(11) state = Opened
> 15:56:30 atd ppp[336]: tun0: CCP: Deflate: Output channel reset
> 15:56:30 atd ppp[336]: tun0: CCP: mp: SendResetAck(11) state = Opened
> 
> repeated tens or hundreds time in a line (or even for half an hour - our max
> lifetime of the link)
> 
> And I can also post some logs that I already have archived  - these logs seems 
> to be relevant.
> Here is what is going on around when SendTerminateReq is being sent 
> (all logging you requested exept debug were on, configs are just
> that I posted last time):
[.....]

The only response that the peer makes after authentication in 
the log you sent is:

> 19:52:16 atd ppp[915]: tun0: LCP: deflink: RecvTerminateAck(2) state = Closing

It completely ignores all CCP and IPCP requests, and ppp ends up 
getting fed up and closing the link.

I think you'll need to enclose a log of the entire conversation.

> Sincerely yours,
> Michael Kuzmun,
> LASERnet

-- 
Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
      <http://www.Awfulhak.org>;                   <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !




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?200009211926.e8LJQws65571>