Notify phase callback, enabled using the PPP_NOTIFY_PHASE config option,
let user configure a callback that is called on each PPP internal state
change. This documents how to use it.
There is two passive modes for PPPoS, passive more, for which we will
try to connect and then listen silently, and silent mode, for which we
will listen silently from the beginning.
Introduce ppp_set_passive and ppp_set_silent so the mode can be chosen
before connecting/listening.
PPP auth required flag is currently hardcoded to true if PPP is
acting as a server and set to false if PPP is acting as a client.
This is probably the most wanted behavior, but since we now have the
ability to change that at runtime, allow users to do it.
It means we can now have a server which asks the client to authenticate
or vice versa. This is pretty unusual thought. What we don't support
yet is mutual authentication with a different set of user and password
per direction which is even less usual.
PPP use peer DNS setting is currently hardcoded to true if PPP is
acting as a client and set to false if PPP is actinf as a server.
This is probably the most wanted behavior, but since we now have the
ability to change that at runtime, allow users to do it.
We don't have a way to have a different default configuration if the
PPP PCB is going to be used as a client or as a server, therefore the
default configuration should be fine for both of them. Since enabling
peer DNS by default is dangerous for server mode, the default is now
not to ask for DNS servers and it should now be explicitely enabled
if needed, update the documentation accordingly.
Now that creating a PPP listener session is a bit less obvious than
before (but much versatile!), add documentation about the most common
way to setup a PPP listener.
Jiffies isn't really a humanly readable value and it means the default
PPP_MAXIDLEFLAG period depends on the platform "jiffies" frequency,
which isn't nice.
Change PPP_MAXIDLEFLAG to use ms instead of jiffies, the current
PPP_MAXIDLEFLAG default (100 ms), looks like a sane value and is
left unchanged.
The overall lwIP design on data flows (netif,udp,tcp) is to use a user
defined callback to get data from stack and a static function to send
data to stack, which makes perfect sense. The SIO port was an exception,
the PPP stack never really used the SIO port by only using the
sio_send() function (and the ignominious sio_read_abort() function a
while back).
The way the SIO port is currently designed adds a tight coupling between
the lwIP port and the user code if the user need to do specific user
code if the current uart used is the PPPoS uart, which is not nice,
especially because all the lwIP stack is quite clean at this subject.
While we are at stabilizing the PPP API, change this behavior before
it's too late by replacing the static sio_write() calls to a user
defined callback.
Follow-up of the #44565 bug fix, renamed the misnamed
PPP_INPROC_MULTITHREADED to PPP_INPROC_IRQ_SAFE because it is
IRQ safe but not thread safe.
Updated PPP documentation which now clearly state when and how
this feature can be used.
Makes it clear we are initiating the PPP session with ppp_connect
(i.e. acting as a PPP client) so there is no confusion possible
between ppp_connect and ppp_listen.
