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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Reply via email to