All modules using PolarSSL embedded library are now using pppcrypt.h.
This header use to be only necessary for MSCHAP and was not built if
MSCHAP wasn't enabled, we unfortunately left the build condition.
Introduced by 3417a02b25: PPP: add a function map for hashes and ciphers
to prepare for mbed TLS support.
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.
Ports now only need to define datatypes and format strings on compilers that do not provide these two headers. Known good: GCC, IAR. Known bad: MSVC 2010.
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.
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.
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.
PPP users can now choose to use an external mbed TLS copy instead of using
our internal old version (but released under a BSDish license) PolarSSL copy.
In order to welcome mbed TLS, we need to ease the switch to:
- embedded PolarSSL 0.10.1-bsd copy
or - external PolarSSL
or - external mbed TLS
This change cleanup all our previously used LWIP_INCLUDED_POLARSSL_* defines,
which were not really useful after all, making them internal build triggers
only, and this change provides a new unique global flag to use an external
PolarSSL copy.
Unfortunately, all functions were renamed when PolarSSL was renamed to
mbed TLS, breaking the API. In order to continue supporting our embedded
PolarSSL copy while allowing our users to use mbed TLS, we need a function
map to deal with the API break.
This commit add a function map for all hashes and ciphers we are currently
using.
lwip/src/core/timers.c: In function ‘sys_check_timeouts’:
lwip/src/core/timers.c:328:5: error: "PBUF_POOL_FREE_OOSEQ" is not defined [-Werror=undef]
#if PBUF_POOL_FREE_OOSEQ
Fix it by declaring an empty PBUF_CHECK_FREE_OOSEQ() function if feature is
not enabled.
Simon and I think it can be removed - the receive window handling get a little less precise, but that should be OK for a lightweight stack.
Receive window is now updated with the whole pbuf size (instead of only count of read bytes from socket) as soon as socket implementation gets a pbuf from netconn layer.
Work on bug #47512: MPU_COMPATIBLE may fail on empty pool (still not finished)
