Wait for up to the specified milliseconds for a valid PPP packet from
the peer. At the end of this time, or when a valid PPP packet is
received from the peer, we commence negotiation by sending our first
LCP packet.
This is useful because PPP does not deal properly when both peers
are sending the first LCP packet in the exact same time, which causes
delays because they both wait for a reply for their own packet.
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.
Now that we have helpers to set those members externaly, pppos_listen
struct ppp_addrs* argument does not add any value. In addition it
was not a well chosen design choice because the user needed to keep a
copy of struct ppp_addrs when listening again for a new connection.
Mostly for PPP server support, but not limited too, we need a way to
configure static IPv4 addresses for our side (our), peer side (his),
and two DNS server addresses if peer asks for them.
DNS servers should be set in IPCP allowoptions instead of wantoptions.
In addition if server mode is enabled we need to disable usepeerdns
config flag so we are not asking DNS servers to our client.
issue 1:
sys_arch_sem_wait() is supposed to return an elapsed time in ms, what could
happen given a > 1 kHz calling rate for high throughput systems is that it
might always returns 0 ms. This is a problem for systems which compute the
elapsed time from a high precision clock source.
This is what is currently happening in the unix port in sys_arch_sem_wait():
start time -> 1000000000; // ns
-- less than a ms before an event arrive --
end time -> 1000xxxxxx; // ns
return value -> (end time - start time)/1000000 -> 0
The return value is used to reduce the next timer interval, if
sys_arch_sem_wait() always return 0 no more timers are fired anymore
issue 2:
The current timer implementation for !NO_SYS targets only count elapsed
time while -waiting- for semaphore and doesn't count at all the time
spent by the stack to process packets. For CPU bound traffic patterns no
more timers are fired anymore.
Both are serious design issues which cannot be easily fixed without reworking
everything. This patch uses the properly implemented timers for NO_SYS targets
for !NO_SYS targets and merge them both into one single timers implementation.
This function does not clear anything anymore. What it is now is an
optional way to notify PPP that link layer is started, changing the
PPP state from "dead" to "initialize". Rename it accordingly to what
the function really is.
What we really need here is to cleanup the PPP environment before
starting LCP, we don't care about the PPP state before LCP is
started. Move cleanups from ppp_clear to ppp_start to clean them
just before we need them cleaned.
What protocols init functions are meant to is to be called once to set
the default configuration before user specific configuration is set.
Until now, we reset to the default configuration just before
reconnecting, thus without allowing any time frame to let users change
it. That was fine until one user asked to be able to do that.
This change move protocols init functions calls from ppp_clear to
ppp_new, meaning user configuration is not overwritten anymore.
Our previous way of doing it was to clear everything except a small part
of the ppp_pcb structure and then populate the structure with default
values using protocols init functions.
But it means the user is currently not allowed to change the default
configuration except the few flags and values that are currently
available in the ppp_settings structure.
Instead of adding more and more fields to the ppp_settings structure,
actually making them duplicate of already existing structure members
of ppp_pcb, but unfortunately cleaned, we carefully checked that
everything is properly cleaned during protocol lowerdown/close and
replaced our giant memset to selective memset of the few ppp_pcb
members that are not properly cleaned.
ccp_init() is meant to be called once, providing default configuration
before user specific configuration is applied. In pppd user configuration
is set just after all protocol init functions are called, in lwIP we
use protocol reset functions to do that, which is more or less the same.
Therefore, be consistent and move CCP user configuration from ccp_init
to ccp_resetci.
Since allowing input validation to trip the ASSERT handler is bad,
let's just drop the packets instead if validation fails.
Signed-off-by: sg <goldsimon@gmx.de>
