From owner-cvs-all Fri Mar 23 16: 7:48 2001 Delivered-To: cvs-all@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id A32A137B71A; Fri, 23 Mar 2001 16:07:39 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f2O07gT01162; Sat, 24 Mar 2001 00:07:42 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f2O0AQ717066; Sat, 24 Mar 2001 00:10:26 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200103240010.f2O0AQ717066@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Joerg Wunsch Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, brian@Awfulhak.org Subject: Re: cvs commit: src/sys/net if_spppsubr.c In-Reply-To: Message from Joerg Wunsch of "Fri, 23 Mar 2001 11:51:13 PST." <200103231951.f2NJpDA18258@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 Mar 2001 00:10:26 +0000 From: Brian Somers Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > joerg 2001/03/23 11:51:13 PST > > Modified files: > sys/net if_spppsubr.c > Log: > (MFC candidate, see below). > > When we get an Open event in stopped state, experience shows that this > is usually means we've somehow missed a previous Down event. This has I don't think I understand what ``missing a previous Down event'' means :-) I suspect that the problem here may be related to the unbalanced TLS calls in the state diagram in rfc1661. If for example a RCR occurs in Stopped state, a TLS isn't required according to the rfc, but this means that it's possible to bring the link (back) up without a TLS. > occasionally bitten people for the IPCP layer with ISDN, apparently a > previously aborted IPCP negotiation must have caused this. As a > bandaid, we quickly pretent a Down event by advancing to starting > state; this effectively implements the `restart' option mentioned in > RFC 1663. > > While i'm not yet fully convinced this is the best thing to do (and is > fully compliant with RFC 1661), i've seen a number of reports here on > the German mailing lists where people have been bitten by the previous > behaviour which usually causes quickly looping ISDN reconnects (thus > loss of money...), and where just this patch fixes the problem. FWIW, ppp(8) (purposefully) violates the rfc here and does a TLS when it gets an RCR in Stopped or Closed state. As a result, the restart option isn't necessary (I believe the restart option is a hack to cope with the missing TLS -- doing a Down from Stopped gets it back). FWIW(2), ppp(8) also ``hacks'' it's way into Stopped when it's ``openmode'' value has been set to anything but the default of active. This is so that it can react correctly to the peer starting things. I believe other implementations do this too, so perhaps the problem you're seeing is as a result of the peer going into Stopped when it shouldn't and missing it's TLS because of an rfc-compliant implementation. It's possible it'll get confused after that and end up pushing our side into Stopped... although I'm not too convinced about this... > For this, i'd even like to see it MFC'd if possible. I prefer the extra TLS idea :-) > Submitted by: Helmut Kreft > > Revision Changes Path > 1.65 +15 -1 src/sys/net/if_spppsubr.c -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message