Commit 7df5496e7b revealed a regression introduced in commit 5a71509353
which broke IPCP reset state.
ask_for_local was set to 0 if ouraddr initial value is 0, if
ask_for_local was false go->ouraddr was cleared in reset callback,
commit 5a71509353 breaks it by removing this clearing. This regression
was silent because the whole ppp pcb runtime data was cleared before
reconnecting until commit 7df5496e7b which removed this giant clearing.
Fix it by reintroducing ask_for_local boolean value, with proper initial
value following what unused function ip_check_options do.
Fixes: 7df5496e7b ("PPP, rework initial/reconnect cleanup")
Fixes: 5a71509353 ("PPP, CORE, IPCP: removed useless ask_for_local boolean")
Master state is almost exactly the same thing as dead state, move it
next to dead state. Holdoff state is actually the state just before
initialize, move it before initialize.
The goal is to be able to use > running or => terminate condition to
check a currently running disconnection phase, which is not possible
today without excluding master and holdoff states.
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.
Setting PPP authentication most only be done when the PPP PCB is in the
dead phase (i.e. disconnected). This is safe to access the PPP PCB
members while the session is down, therefore providing a thread-safe
function of it is meaningless and it might even be misleading.
All our new ppp_set_* functions do not have their equivalent
pppapi_set_* functions and they are not going to have them. At least
we make ppp_set_auth consistent with all others ppp_set_*, so that it
doesn't look like special.
Helper function to setup MPPE (Microsoft Point to Point Encryption) for
a PPP link. Allows enabling/disabled MPPE itself, enabling/disabling
stateless support, and whether we are willing to negotiate 40-bit
and/or 128-bit encryptions.
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 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.
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 might negotiate to not compress if peers cannot agree on a
compressor, therefore if the null compressor is chosen we must pass
packets as is instead of dropping them.
Reported-by: Stephan Linz <linz@li-pro.net>
Fixes: 987f6237c4 "PPP, MPPE, drop input/output packets if we couldn't find the chosen decompressor/compressor"
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
Most of them were wrong actually. We have to use unsigned int because
C90 only allows int types for bitfields, so we are stuck to 32-bit
bitfields in most cases.
We need to do VJ compression before CCP/MPPE compression and VJ
decompression after CCP/MPPE decompression. This leads to a massive
rewrite of how we currently handled VJ only in the PPPoS lower protocol
handler.
Moved VJ structures from pppos to ppp_pcb because we need them back in
PPP core. This is a bit unfortunate because that's not necessary for
PPPoE or PPPoL2TP, but, hey!. Fixed CCP+MPPE+VJ order.
Removed mutiple copies of keys by pre-setting MPPE keys during MSCHAP
negotiation.
Improved MPPE init so we don't need to pass a buffer formatted in a
special way to MPPE, this is necessary for pppd to talk to the kernel,
we don't need that here.
ip_addr_t is used for all generic IP addresses for the API, ip(4/6)_addr_t are only used internally or when initializing netifs or when calling version-related functions
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.
We don't need ask_for_local boolean, this is only useful for setup which
can determine the local IP address from the system hostname, which is
probably meaningless for embedded devices (and probably any devices).
It was actually only set by ip_check_options() which is commented out in
lwIP because we don't parse a config file nor check PPP configuration
(user is responsible about writing a configuration which is logical ;-).
Furthermore ask_for_local boolean never set actually had the wrong
default for PPP server setups.
