Date: Sat, 24 Mar 2001 00:10:26 +0000 From: Brian Somers <brian@Awfulhak.org> To: Joerg Wunsch <joerg@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, brian@Awfulhak.org Subject: Re: cvs commit: src/sys/net if_spppsubr.c Message-ID: <200103240010.f2O0AQ717066@hak.lan.Awfulhak.org> In-Reply-To: Message from Joerg Wunsch <joerg@FreeBSD.org> of "Fri, 23 Mar 2001 11:51:13 PST." <200103231951.f2NJpDA18258@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <kreft@zeus.ai-lab.fh-furtwangen.de>
>
> Revision Changes Path
> 1.65 +15 -1 src/sys/net/if_spppsubr.c
--
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 cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103240010.f2O0AQ717066>