Date: Fri, 22 Nov 2002 14:42:53 +0300 From: Roman Kurakin <rik@cronyx.ru> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-net@FreeBSD.org Subject: Re: sppp patch's Message-ID: <3DDE183D.6040206@cronyx.ru> 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> <20021121221833.A70987@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
Joerg Wunsch wrote:
>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
>
I couldn't make debug trace right now, because this fix was made long
time ago and I don't
remember how to reproduce all those problems.
>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.
>
But RFC imply which final state should be at the and of all operations
in particular case.
If we call tlf and then change state we will get proper final state. If
we choose the other
way we will get wrong final state.
Current sppp has some fixes that cure a problem in place it become
apparent, but don't
fix it in place where it occurs. So, probably many of the problems are
solved, but they
are solved incorrectly, and maybe this one is solved too.
Best regards,
Roman Kurakin
>
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDE183D.6040206>