Hi, Sylvain.
> From: Sylvain Rochet [mailto:[email protected]]
> 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:[email protected]]
> > >
> > > 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
---------------------------------------------------------------------------------------
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
