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

[Greg Smith]

Hi, Sylvain.


> -----Original Message-----
> From: lwip-users
> On Behalf Of Sylvain Rochet
> Sent: Saturday, 02 July 2016 16:31
> To: Mailing list for lwIP users <address@hidden>
> Subject: Re: [lwip-users] Configuring PPP Options in Version 2.0.0 Beta1
> 
> >
> > Agreed that most won't be necessary.
> > Right now, I'd like to be able to set the following lcp_options:
> > passive,
> 
> Done.
> 
> 
> > silent,
> 
> Done.
> 
> 
> > restart*,
> >
> > *restart may not be needed.  I don't see it implemented anywhere.  But
> > for my application, I need a way to ensure the PPP connection stays
> > up/reconnects as often as possible.  (I do it with the link status
> > callback now, which is fine.)
> 
> I don't want to. Restart have a very different meaning whether we use PPPoS,
> PPPoE or PPPoL2TP.
> 
> The main problem here is that PPP was designed for PPPoS at first, there are a
> lot of PPP options that are only there for PPPoS and which are totally useless
> or even dangerous for PPPoE or PPPoL2TP. LCP restart is one of them :-)
> 
> This is the same problem with listening, listening for PPPoS means waiting for
> a LCP packet, so LCP is already running, listening for PPPoE means waiting for
> a PADI packet, and once PPPoE session is established, start the PPP session,
> and listening for PPPoL2TP means waiting for a SCCRQ packet, and once PPPoL2TP
> session is established, start the PPP session.
> 
> I prefer to keep the PPP state flow logical, by doing our best to keep the
> major part of the API common and to have the same behavior for PPPoS, PPPoE,
> and PPPoL2TP.

I can agree with that logic.  Would it possibly make sense to remove the option completely from the code then?  (I'm not necessarily advocating this; just asking the question.)
 
> 
> > neg_pcompression,
> 
> Done.
> 
> 
> > neg_acompression
> 
> Done.
> 
> 
> > I don't need it myself, but there should also (probably) be an "easy"
> > way to set neg_asyncmap, along with defining the actual async map
> > itself.  (Maybe there already is?  I didn't look.)
> 
> Done.
> 
> 

Thank you for the all the settings implementations!

-- G

---

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

---