Add a fix for the case where the dialout fails. In this case the isp

interface was left in an active, but not connected, state, which resulted
in data being sent to it and the transmit queue filling up. This happened
because the driver never informed sppp that it shoulkd clean up the
connection. This fix informs sppp that it should clean things up.

The fix was actually developed and tested under -stable, so a short MFC
period seems appropriate, say 2 days.

Contributed by: Ari Suutari <ari.suutari@syncrontech.com>

1 files changed, 13 insertions, 0 deletions

diff --git a/sys/i4b/driver/i4b_isppp.c b/sys/i4b/driver/i4b_isppp.c
index a3f32a7d2871..60679afa0ff5 100644
--- a/sys/i4b/driver/i4b_isppp.c
+++ b/sys/i4b/driver/i4b_isppp.c
@@ -521,6 +521,7 @@ static void
 i4bisppp_dialresponse(int unit, int status, cause_t cause)
 {
 	struct i4bisppp_softc *sc = &i4bisppp_softc[unit];
+	struct sppp *sp = &sc->sc_if_un.scu_sp;
 
 	NDBGL4(L4_ISPDBG, "isp%d: status=%d, cause=%d", unit, status, cause);
 
@@ -535,6 +536,18 @@ i4bisppp_dialresponse(int unit, int status, cause_t cause)
 			while((m = sppp_dequeue(&sc->sc_if)) != NULL)
 				m_freem(m);
 		}
+
+		sc->sc_cdp = (call_desc_t *)0;	
+		/* do thhis here because pp_down calls i4bisppp_tlf */
+		sc->sc_state = ST_IDLE;
+
+		/* Ahh. ppp does't like to get a down event when
+		 * dialing fails. So first tell that we are up
+		 * (doesn't hurt us since sc_state != ST_CONNECTED)
+		 * and then go down.
+		 */
+		sp->pp_up(sp);
+		sp->pp_down(sp);
 	}
 }