From owner-freebsd-net Thu Nov 21 13:20:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 816BC37B401 for ; Thu, 21 Nov 2002 13:20:18 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A17343E91 for ; Thu, 21 Nov 2002 13:20:11 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id WAA05176; Thu, 21 Nov 2002 22:20:04 +0100 (CET) Received: from uriah.heep.sax.de (localhost.heep.sax.de [127.0.0.1]) by uriah.heep.sax.de (8.12.5/8.12.5) with ESMTP id gALLIXWc084881; Thu, 21 Nov 2002 22:18:33 +0100 (MET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.12.5/8.12.5/Submit) id gALLIXto084880; Thu, 21 Nov 2002 22:18:33 +0100 (MET) (envelope-from j) Date: Thu, 21 Nov 2002 22:18:33 +0100 From: Joerg Wunsch To: Roman Kurakin Cc: freebsd-net@FreeBSD.org Subject: Re: sppp patch's Message-ID: <20021121221833.A70987@uriah.heep.sax.de> Reply-To: Joerg Wunsch References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011231165245.B73897@uriah.heep.sax.de> <3DDD1D67.4050905@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DDD1D67.4050905@cronyx.ru>; from rik@cronyx.ru on Thu, Nov 21, 2002 at 08:52:39PM +0300 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As Roman Kurakin wrote: > Sppp still have a quantity of bugs. Here is one of them: > > --- if_spppsubr.c.orig Wed Oct 16 18:41:16 2002 > +++ if_spppsubr.c Thu Nov 21 20:13:16 2002 > @@ -1672,12 +1672,12 @@ > case STATE_ACK_SENT: > break; > case STATE_CLOSING: > - sppp_cp_change_state(cp, sp, STATE_CLOSED); > (cp->tlf)(sp); > + sppp_cp_change_state(cp, sp, STATE_CLOSED); > break; [...] > In all cases we have the same problem: at first we should call tlf > that will changes state and then we should set proper state. If we > set some state and then call tlf we will get wrong final state. Can you please explain more, e. g. with a ifconfig debug trace? The RFC doesn't mandate a particular order between the actions and the actual state change, and IIRC (without digging down into the code right now), reverting the order has other unwanted side effects. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message