Re: [lwip-users] Configuring PPP Options in Version 2.0.0 Beta1

[Greg Smith]

Hi, Sylvain.

> From: Sylvain Rochet [mailto:address@hidden
> Sent: Tuesday, 10 May 2016 16:56
> 
> Hi Greg,
> 
> 
> On Tue, May 10, 2016 at 03:10:55PM +0000, Greg Smith wrote:
> > From: Sylvain Rochet [mailto:address@hidden
> > >
> > > Well, you are right, you can't. You are actually the first one to
> > > ask. I can't remember that far away but that wasn't possible in
> > > 1.4.1 as well isn't it ?
> >
> > It was not in 1.4.1, either.  But I found a blog post somewhere with
> > the above hack.  Since there was no delay in connecting, it worked
> > fine.  In 2.0.0, with the optional delay, that workaround now only
> > works for no delay.
> 
> Indeed, and well, it's just a stupid hack. Of course the first packet sent by
> the stack is not going to be an IPCP packet (LCP must be opened first), but
> that's still wrong.

Agreed.  And since I'm pretty new to PPP (and TCP/IP for that matter), I'm still learning where/when/how all the different phases and handshaking work.  But I'm getting my application to a point where it's starting to work well.

> > Since the server function wasn't really working in 1.4.1 (at least, it
> > wasn't for me), I needed a way to set a fixed address as a "client".
> > Now that the feature is working, this may be moot.  However, it would
> > be a nice feature, I think , for future revs.
> 
> I fully agree, at least with a proper way of changing the default PPP
> configuration we could get rid of most of our ppp_settings struct members that
> are actually just duplicate of existing {proto}_wantoptions fields.

Yes, I noticed that most seem to be a copy of the _wantoptions.  When trying to find options, that's typically what I've been searching for anyway.  But having a "proper way" to adjust configuration would be welcome.

> 
> > > What worry me about both of them is that it is not possible to add
> > > them without an API change, and we are in beta… that would have been
> > > possible months ago but it's a bit too late now, you should have
> > > tried the Git master branch :-)
> >
> > I just started using lwIP earlier this year and am pretty new at all
> > IP stacks.  While I wanted the newer stuff in 1.5/2.0 (master) builds,
> > I couldn't tolerate that kind of volatility.  I just needed to get the
> > thing working to begin with!  It's just coincidentally fortunate that
> > at the 2.0.0 beta, I was at a point where I could try upgrading to it.
> 
> Given what Simon says ("just a Beta" part), which is a great news, I can fulfil
> your need for the next stable release.
> 
> 
> > What I'm really after is being able to adjust the settings at
> > compile-time (or during init at runtime) so that when a new version of
> > lwIP comes out, it doesn't clobber my changes when I overwrite with
> > the new files.  I don't think there's going to need to be a lot of
> > configuration once we get it close to production and get things
> > settled.  So I'll take a look at ppp_settings.
> >
> > If I understand your comment above, I'll remove ppp_clear() from the
> > source files as they are now, then update ppp_settings as I need, then
> > call ppp_clear(), and finally, ppp_connect()/listen().
> 
> Not exactly, you can update ppp_settings whenever you want when the
> session is in the dead state, it is not cleared when the PPP state
> machine is cleared, hence its name. What is cleared is almost everything
> else, especially all the {proto}_wantoptions structures, if you add the
> options you want in ppp_settings then the current way of clearing the
> PPP state machine will still be fine.

Thank you for the clarification.  I think this will work for what I need.  (For now anyway.)

> I'm first going to check if {proto}_wantoptions are changed while PPP is
> running, I don't think they are, but I really need to double or even
> triple check that. If they are not I could then move them out from the
> runtime state part that need to be cleared between sessions and try to
> skip the part where PPP protocols are initialized to their default
> values. That would be the best outcome so far.

I'm not in great need of this kind of change right now, but I would certainly appreciate it if it landed on a "requested feature list" somewhere for the future.

> I don't really like my proposal where you need to reconfigure everything
> that is not the default before calling _connect() or _listen() for each
> run, a configuration is a configuration and it _should_ stay between
> runs.
> 

I can go either way.  If it's truly a "configuration," then I agree that it should stay between runs.  If it's more "initialization," then it does not seem inconsistent to have to set it each time.

-- Greg

---

This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com

---