(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
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.

For this, i'd even like to see it MFC'd if possible.

Submitted by:	Helmut Kreft <kreft@zeus.ai-lab.fh-furtwangen.de>

1 files changed, 14 insertions, 0 deletions

diff --git a/sys/net/if_spppsubr.c b/sys/net/if_spppsubr.c
index f65ec6d..2e59072 100644
--- a/sys/net/if_spppsubr.c
+++ b/sys/net/if_spppsubr.c
@@ -1671,6 +1671,20 @@ sppp_open_event(const struct cp *cp, struct sppp *sp)
 		sppp_cp_change_state(cp, sp, STATE_REQ_SENT);
 		break;
 	case STATE_STOPPED:
+		/*
+		 * Try escaping stopped state.  This seems to bite
+		 * people occasionally, in particular for IPCP,
+		 * presumably following previous IPCP negotiation
+		 * aborts.  Somehow, we must have missed a Down event
+		 * which would have caused a transition into starting
+		 * state, so as a bandaid we force the Down event now.
+		 * This effectively implements (something like the)
+		 * `restart' option mentioned in the state transition
+		 * table of RFC 1661.
+		 */
+		sppp_cp_change_state(cp, sp, STATE_STARTING);
+		(cp->tls)(sp);
+		break;
 	case STATE_STOPPING:
 	case STATE_REQ_SENT:
 	case STATE_ACK_RCVD: