From owner-freebsd-hackers Sun Nov 5 6:50:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by hub.freebsd.org (Postfix) with ESMTP id 1020037B4CF for ; Sun, 5 Nov 2000 06:50:34 -0800 (PST) Received: from localnet.cwnt.co.il (ras7-171.hfa.netvision.net.il [62.0.191.175]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id QAA18821 for ; Sun, 5 Nov 2000 16:50:32 +0200 (IST) Received: from 192.168.0.146 ([192.168.0.146]) by localnet.cwnt.co.il (WinRoute 3.04g) with SMTP; Sun, 5 Nov 2000 12:45:45 +0200 Message-ID: <001c01c04716$7c710c50$9200a8c0@ido> From: "Ido Barnea" To: Subject: sppp driver bug? Date: Sun, 5 Nov 2000 12:52:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C04727.3FF3C1D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C04727.3FF3C1D0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi I am trying to use the sppp driver of the 4.1FreeBSD to establish ip = connection over ppp between two pc's. It usually works, but in a small percentage of the cases one of the = interfaces gets stack in the following state: lcp is in state closed and ipcp is in state closed (I know that for sure = from debug prints I added). The real problem is that nothing seems to get the interface out of its = "problematic" state. (I tried putting it down and up, transferring it to = hdlc and back and more...) I think the following change in sppp_lcp_tld will enable the interface = to recover using ifconfig down and up. original lines: for (i =3D 0, mask =3D 1; i < IDX_COUNT; i++, mask <<=3D 1) if (sp->lcp.protos & mask && ((cps[i])->flags & CP_LCP) =3D=3D 0) { My suggested lines: for (i =3D 0; i < IDX_COUNT; i++) if (((cps[i])->flags & CP_LCP) =3D=3D 0) { The idea here is that since the ipcp is in closed state, its bit in the = lcp.protos is not set, so it never receives the down and close event (inside the if). It also does not put the bit on = when getting open event (since it is in the stopped state), so it never = receives up event in sppp_lcp_tlu. If anyone has an idea why the interface gets stack in the first place, = I'll be very glad to hear. I also want to know if my code change seems reasonable. Thanks, Ido ------=_NextPart_000_0019_01C04727.3FF3C1D0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

I am trying to use the sppp = driver of the=20 4.1FreeBSD to establish ip connection over ppp between two=20 pc's.

It usually works, but = in a small=20 percentage of the cases one of the interfaces gets stack in the = following=20 state:

lcp is in state closed and = ipcp is in=20 state closed (I know that for sure from debug prints I = added).

The real problem is that = nothing seems=20 to get the interface out of its "problematic" state. (I = tried putting it=20 down and up, transferring it to hdlc and back and more...)

I think the following change = in=20 sppp_lcp_tld will enable the interface to recover using ifconfig down = and=20 up.

original lines:

for (i =3D 0,=20 mask =3D 1; i < IDX_COUNT; i++, mask <<=3D 1)
if = (sp->lcp.protos & mask && ((cps[i])->flags & = CP_LCP) =3D=3D 0)=20 {

My suggested = lines:

for (i =3D 0; i < IDX_COUNT;=20 i++)
if (((cps[i])->flags & = CP_LCP) =3D=3D=20 0) {

The idea here is that since = the ipcp is=20 in closed state, its bit in the lcp.protos is not set, so it never = receives=20 the

down and close event (inside = the if). It=20 also does not put the bit on when getting open event (since it is in the = stopped=20 state), so it never receives up event in sppp_lcp_tlu.

If anyone has an idea why = the interface=20 gets stack in the first place, I'll be very glad to hear.

I also want to know if = my code=20 change seems reasonable.

Thanks, Ido

------=_NextPart_000_0019_01C04727.3FF3C1D0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message