[Top][All Lists]

[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: Wed, 11 May 2016 14:23:09 +0000

Hi, Sylvain.

> From: Sylvain Rochet [mailto:address@hidden
> Sent: Tuesday, 10 May 2016 16:09
> If you could configure your MUA to properly add quote-marks that would be
> great, that's a bit hard to guess where you answered in the text/plain form.

Sorry about that! I thought I had it configured right (it looks fine on my screen); it should be fixed now.
And, in the future, please continue to let me know about things like this. It's been a long time since I've had interact on forums this way and I probably need to (re)learn appropriate etiquette again. So if you see other things that are wrong (or just grating), not only will I not be offended, I'll appreciate the heads-up. :-)

> On Tue, May 10, 2016 at 03:14:02PM +0000, Greg Smith wrote:
> > From: Sylvain Rochet [mailto:address@hidden
> > >
> > > 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.)
> Well, RC1 is actually the Beta you downloaded, the name is unfortunate because
> it's very misleading.

Yes, I realized a little later that Beta1 and RC1 are the same and that Simon's message wasn't a new, new update, but just the same RC1. (Though, I think it was smart of Simon to push a message out the group, as well as the news article.)

> > 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...
> Yeah, thousands was just a way of speaking, anyway, there is really a lot of
> options. lwIP users should never have to manually access struct members. our
> way of allowing users to get/set struct members is to provide macros to do
> that. You could say that many options does not have their corresponding get/set
> macro for our current ppp_settings and you will be right, I'm probably the only
> user of most of them anyway.

Well, now there's two of us! :-)
I'm pretty much OK with macros or functions. Though, again, I'm not in dire need of this feature right now. As I get more into fiddling with it all, if I think of a good way, I'll let you know.

> So far I only saw the PPP stack in lwIP used with "3g" modems over UART links,
> where PPP is only used in its simpliest possible form. It was probably used
> with dialup modems in the past indeed but that's not going to happen anymore.
> You are actually the first one ever asking how to change the default
> configuration :-)

Given the lack of chatter about PPP, I thought I might be one of the few users -- especially give PPP's state prior to 2.0.0.

My application is talking directly between two embedded controllers, and not a modem, as you suspect. I am using a serial link (RS485, in particular), so I'll only be able to test/review that part. But as I find things, I'll try to post about them.

Likewise, I'll be happy to "beta test" changes as they come along. I don't think I'm anywhere near versed enough in the details of the PPP implementation (let alone the rest of lwIP!) to contribute directly, but I'll be happy to work with you and the community to bring up issues and try to resolve them, if that's helpful.

-- Greg

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]