Re: [lwip-users] Solved: PPP no IP address assigned

[Sylvain Rochet]

Hello Michael,


On Thu, Apr 02, 2015 at 10:48:09AM +0200, Michael Waeber wrote:
> 
> Many thanks for your help! Now I've managed to get an IP address
> assigned. Details see below.

Yeah!, happy to hear that.


> On 01.04.2015 21:56, Sylvain Rochet wrote:
> > On Wed, Apr 01, 2015 at 05:27:41PM +0200, Michael Waeber wrote:
> > > On 01.04.2015 14:02, Sylvain Rochet wrote:
> > > >
> > > > Looks like your lwIP timeouts are not working or you don't have enough
> > > > of them, PPP needs a lot of timeouts, could you check that first ?
> > >
> > > What do you exactly mean with "timeouts"? We have set NO_SYS=1, so
> > > there is no such thing as OS timeout. Is the PPP part not driven by
> > > the TCP main task tcp_tmr()? Do i have to call another function for
> > > PPP if NO_SYS=1?
> >
> > You don't have to, tcp_tmr() should do the job.
> 
> It does not, see below.

I misread, of course it does not, this is TCP_tmr… that's only apply for 
TCP sessions.


> > It really should retry a few seconds later, could you dig what is
> > happening in IPCP (ipcp.c/fsm.c) ?
> 
> This was the crucial hint!
> 
> ipcp.c/fsm.c isn't run if no answer is received and only tcp_tmr() is
> called.
> 
> We have called the various timers tcp_tmr, etharp_tmr, ip_reass_tmr and
> others from our main loop. This was OK back in pre 1.4.x time and
> obviously works if only ethernet is used.
> 
> Now I've changed to call sys_check_timeouts()

Indeed *_tmr() are deprecated[1] AFAIK, you have to use 
sys_check_timeouts().


> and now fsm_timeout() in fsm.c is called. The IPCP request is repeated 
> after 6.8 s. To the second request the modem answers with a request on 
> his part. The IP address is assigned and the callback is called with 
> PPPERR_NONE.

IPCP was not designed to wait until the modem knows its IP from the 
network mainly because that was not necessary for dialup where the PPP 
session is end to end. That's also true for any other PPP protocol, 
there is no such concept of telling the remote to wait in PPP.

Some modems are using NAK and we have a workaround for that[2], your 
choose to not answer at all, which is the method I prefer, you can 
decrease FSM_DEFTIMEOUT and increase FSM_DEFMAXCONFREQS so your session 
will come up a little faster.

Sylvain


[1] 
http://git.savannah.gnu.org/cgit/lwip/lwip-contrib.git/commit/?id=9a8c3c0283b1481d436d3b360fd07ef05ff30662
[2] http://git.savannah.gnu.org/cgit/lwip.git/tree/src/netif/ppp/ipcp.c#n606

signature.asc
Description: Digital signature