Date: Tue, 17 Oct 2000 16:16:00 +0400 From: "Michael Kuzmin" <kuzmin@laser.ru> To: <freebsd-net@FreeBSD.org> Subject: Re: Dying multi-link PPP Message-ID: <008501c03834$48711800$3f0657c2@w9g8j7> References: <200009211926.e8LJQws65571@hak.lan.Awfulhak.org>
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... ... > > > > > > 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. I just performed special experiments arranged according to your proposals: all redial delays increased to 5 sec, and all compression switched off (both link and bundle levels). Unfortunately that did not help, below is a general picture of dying MP, as seen by "last" command at answering side (atd): ata cuaa1 RELIABLE EC=(LA mo 16 oct 18:49 - 19:19 (00:30) ata cuaa1 RELIABLE EC=(LA mo 16 oct 18:20 - 18:48 (00:28) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:48 - 18:19 (00:30) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:40 - 17:47 (00:06) dialout cuaa2 mo 16 oct 17:36 - 19:01 (01:25) dialout cuaa2 mo 16 oct 17:35 - 17:36 (00:00) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:33 - 17:40 (00:06) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:29 - 17:29 (00:00) ata cuaa2 4800:15/V34/V42B mo 16 oct 17:29 - 17:29 (00:00) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:28 - 17:28 (00:00) ata cuaa2 4800:15/V34/V42B mo 16 oct 17:27 - 17:28 (00:00) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:27 - 17:27 (00:00) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:26 - 17:26 (00:00) ata cuaa2 4800:16/V34/V42B mo 16 oct 17:25 - 17:25 (00:00) ata cuaa2 4800:16/V34/V42B mo 16 oct 17:18 - 17:19 (00:00) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:15 - 17:16 (00:00) ata cuaa2 4800:15/V34/V42B mo 16 oct 17:15 - 17:16 (00:00) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:14 - 17:15 (00:00) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:13 - 17:14 (00:00) ata cuaa2 4800:17/V34/V42B mo 16 oct 17:10 - 17:10 (00:00) ata cuaa2 4800:15/V34/V42B mo 16 oct 17:05 - 17:08 (00:02) ata cuaa1 RELIABLE EC=(LA mo 16 oct 17:03 - 17:11 (00:08) ata cuaa2 4800:15/V34/V42B mo 16 oct 16:32 - 17:02 (00:30) ata cuaa1 RELIABLE EC=(LA mo 16 oct 16:28 - 16:59 (00:31) ata cuaa2 4800:15/V34/V42B mo 16 oct 16:27 - 16:30 (00:02) ata cuaa1 RELIABLE EC=(LA mo 16 oct 16:27 - 16:27 (00:00) mike ttyp1 aqua.laser.ru mo 16 oct 16:15 - 18:49 (02:34) It is quite typical for us: immediately after restart (16:27) there was a period of normal two-link operation (apparently up to 17:08 here), followed by... > the usual final (dead) state of the channel -- an infinite series of short > connects each with LCP RecvTerminateReq in 15 sec after successful > authorization and lcp -> open (a quote from my first message). We terminated it by hand at 17:29 and started two independent single-link ppp sessions over the same modems and the same ppp.config (but different label loaded: ppp cu1 instead of ppp mp) - our working arrangenet for the last month. Switching off MP immediately solved all the problems, as usual. Complete configs and logs (50k compressed) are redy to be sent out to everybody who may agree to review them. With many thanks for your help, Sincerely yours, Michael Kuzmin, LASERnet 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?008501c03834$48711800$3f0657c2>