lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Smith
Subject: Re: [lwip-users] Configuring PPP Options in Version 2.0.0 Beta1
Date: Tue, 10 May 2016 15:14:02 +0000

Hi, Sylvain.

 

From: Sylvain Rochet [mailto:address@hidden
Sent: Friday, 06 May 2016 20:47

Hi Greg,

 

 

On Sat, May 07, 2016 at 02:27:15AM +0200, Sylvain Rochet wrote:

> On Wed, May 04, 2016 at 08:10:41PM +0000, Greg Smith wrote:

> > Hello.

> >

> > I have been looking forward to the PPP enhancements made in lwIP

> > 2.0.0

> > Beta1 compared to 1.4.1.  I've added the new version to my project

> > with success and have a few questions about configuring PPP.  I

> > appreciate any help you can give.

> >

> > 1) How can I setup a static IP address when _not_ running in PPP

> > Server mode?  (I have been successful when setting the IP address as

> > second argument of pppapi_listen() when running as a server.)

> > However, when running as a "client" using pppapi_connect(), the only

> > thing I've found to work is something like: pppapi_connect(pppPcb,

> > 0);

> > pppPcb->ipcp_wantoptions.ouraddr = usartPpp.ip_addr.addr;

> >

> > That seems kludgy and wrong.  And, it does not work if the delay

> > time (second argument of pppapi_connect()) is set >0.  I would like

> > to be able to set a static IP address and have a delay time.

> > So how do I get something like:

> >

> > // <-- function call to set static IP address here --> //

> > pppapi_connect(pppPcb, 10);

>

> 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 ?

>

>

> > 2) In lcp_init(), several PPP options are hard-coded, such as

> > negotiating the async map and compression.  Is there a programmatic

> > way to set these options at either compile-time or run-time without

> > directly modifying the lcp_init() function?  If so, how?

>

> Well, you can't, this is the same issue as 1).

>

>

> 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 :-)

>

> The only way to achieve that is to add a timeframe when the user can

> change the default configuration after PPP initialisation, this way:

>

> ppp_clear(ppp);

> ... user configuration changes ...

> pppXX_connect(ppp_pcb *ppp, ...);

>

> It changes the API because the user will be then responsible of

> clearing the PPP machine state before re-connecting, which in my

> non-perfect world means that most of them won't do it properly.

>

>

> The only configurable settings, using functions or macro if they exist

> are currently our ppp_settings structure. That's actually the only way

> to add your 1) and 2) without breaking the API, but we can't do that

> for all options provided by the PPP stack, there are just too many

> configurable values everywhere.

>

>

> What you could do, for now, is to remove ppp_clear(ppp); calls from

> pppos_connect() and pppos_listen(), then don't forget to call it

> before calling pppos_connect() and pppos_listen(). This way it adds

> the necessary timeframe you need to manually change settings into all

> protocols structures.

 

After thinking about it again, this is probably one proper way to achieve that. Nothing prevent us to reset the PPP state machine at session termination instead of session opening. This way we can get rid of ppp_clear() calls in pppXX_connect|listen functions and you will be then allowed to change the PPP configuration before calling pppXX_connect|listen. Then we only need to add thousands of macros to change PPP protocols configuration and it should do the job without changing the API and, and this is very important, without adding a lot of more code which cannot be compiled-out.

That sounds like it would be great!  I just saw that 2.0.0RC1 was released.  Does that have this change?  (I suspect not.)

Also, I couldn't quite tell if there is sarcasm in needing "to add thousands of macros" or not, but that sounds tedious and unmanageable...  Though, I do like keeping code such that it can be compiled-out, as necessary.

 

Sylvain




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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]