[Top][All Lists]

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

[lwip-devel] [bug #49285] PPP doesn't get connected anymore after a link

From: Sylvain Rochet
Subject: [lwip-devel] [bug #49285] PPP doesn't get connected anymore after a link fail
Date: Thu, 20 Oct 2016 09:54:57 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

Follow-up Comment #18, bug #49285 (project lwip):

Great!, thanks you very much for testing, time for the real fix then.

By the way, to answer various Simon's questions:

> That would mean removing the 'memset()' to parts of the ppp_pcb broke it?


> Sylvain, in the commit message, you say that 'init' has been moved from
'connect' to first-init because one user wanted to change the default
> Do all the protocols handle init being called only once correctly?

They should :-)

> I'm lost in checking how the original pppd code does that...

Init is actually called only once.

Resetting is done in the resetci fsm callbacks, which is called when protocol
send the first configure request frame, see fsm_sconfreq function.

> On the other hand, the remote side seems to terminate the connection, maybe
because of too many IPCP reqs?

Not here.

> Or because the old address is now requested?


> How did the retry look with commit

It worked, because the giant memset cleared the IPCP wanted options struct.

IPCP is special regarding that, I suppose but I am not sure, because of a
protocol design flaw on the old ADDRS protocol (which shouldn't be used
anymore) wanted options struct need to be changed to improve the chance of
converging. That's only a guess and I don't want to change that because it was
clearly done on purpose in pppd.

Anyway, I am very well aware that removing the giant memset between retries
may reveal bugs that were previously shadowed, but it was worth it to allow
user configuration.



Reply to this item at:


  Message sent via/by Savannah

reply via email to

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