mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: rjd@xyzzy.clara.co.uk
To: paulkf@microgate.com (Paul Fulghum)
Cc: linux-kernel@vger.kernel.org, paulus@samba.org
Subject: Re: SyncPPP IPCP/LCP loop problem and patch
Date: Thu, 24 May 2001 16:30:39 +0100 (BST)	[thread overview]
Message-ID: <200105241530.f4OFUdw27786@xyzzy.clara.co.uk> (raw)
In-Reply-To: <01a801c0e2ea$dfffc5c0$0c00a8c0@diemos> from "Paul Fulghum" at May 22, 2001 06:27:34

Paul Fulghum wrote:
> 
> RFC1661 state table shows a transition to req-sent
> from opened when a (properly formated with 
> correct sequence ID) cfg-ack is received.
> 
> Syncppp does not do this (from sppp_lcp_input):
...
> Maybe adding:
> 
>   case LCP_STATE_OPENED:
>    sppp_lcp_open (sp);
>    sp->ipcp.state = IPCP_STATE_CLOSED;
>    sp->lcp.state = LCP_STATE_REQ_SENT;
>    break;

Thanks for the suggestion. I tried it and found that Linux syncppp does not
have a LCP_STATE_REQ_SENT the nearest alternate being LCP_STATE_CLOSED.
Looking at the RFC these are by no means compatable. Adding the extra state
and coding the transitions would not be difficult but as I've looked at it
I've seen more and more ommissions in the code. The magic number is not
randomised very well, jiffies is not a great random number :-)  Parameter
negotiation only takes place for the magic number plus dummys for MRU and
ACCM, I'm not even sure that enforcing and ACCM of all zeros is required.
If the remote end sends us a config request without a magic number we end
up testing an uninitialised variable, and so on.

Who's the owner for syncppp.c ?  I might be able to put some time in on
it, but would hate to be sending patches into empty space.

-- 
        Bob Dunlop                      FarSite Communications
        rjd@xyzzy.clara.co.uk           bob.dunlop@farsite.co.uk
        www.xyzzy.clara.co.uk           www.farsite.co.uk

  reply	other threads:[~2001-05-24 15:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-22 10:51 rjd
2001-05-22 12:31 ` Paul Mackerras
2001-05-22 13:34   ` rjd
2001-05-22 16:11     ` Paul Fulghum
2001-05-24 15:11       ` SyncPPP IPCP/LCP loop problem and patch. Take 2 rjd
2001-05-22 18:13     ` SyncPPP IPCP/LCP loop problem and patch Paul Fulghum
2001-05-24 15:30       ` rjd [this message]
2001-05-24 16:56         ` Paul Fulghum
2001-05-24 18:13           ` Alan Cox
2001-05-24 20:27             ` SyncPPP Generic PPP merge Paul Fulghum
2001-05-24 22:18               ` Alan Cox
2001-05-24 22:53                 ` Jeff Mcadams
2001-05-24 23:27                 ` Paul Fulghum
2001-05-25  0:55                 ` Paul Mackerras
2001-05-25 16:44                   ` Jeff Mcadams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200105241530.f4OFUdw27786@xyzzy.clara.co.uk \
    --to=rjd@xyzzy.clara.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulkf@microgate.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®