I think that "#define SZT_F PRIuPTR" has a much better chance
of being right, making the assumption that uintptr_t is the same as
size_t.
Dirk: I think Ambroz is right.
lwip/src/core/init.c:256:32: error: "LWIP_COMPAT_MUTEX" is not defined [-Werror=undef]
#if LWIP_TCPIP_CORE_LOCKING && LWIP_COMPAT_MUTEX && !defined(LWIP_COMPAT_MUTEX_ALLOWED)
^
Setting LWIP_TCPIP_CORE_LOCKING is meaningless for NO_SYS targets,
therefore checking if LWIP_COMPAT_MUTEX is set does not make sense.
Introduced by 42dfa71f97: Make LWIP_TCPIP_CORE_LOCKING==1 the default
(and warn if LWIP_COMPAT_MUTEX==1 in that case as mutexes are required
to prevent priority inversion on tcpip_thread operations)
PPP is just the upper protocol for PPPoE and PPPoL2TP, meaning it is only
started once "E" or L2TP is established. Therefore waiting indefinitely
for LCP packets on the PPP side does not make sense at all, if the lower
level protocol is UP, PPP *MUST* comes up as well or we should restart from
the beginning.
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.
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.
print_string() displays characters as \\%.03o but without first
casting it from "char" to "unsigned char" so it gets sign-extended
to an int. This causes output like \37777777630 instead of \230.
(Based from pppd commit 5e8c3cb256a7e86e3572a82a75d51c6850efdbdc)
Found by coverity.
Introduced by c0e7d54e37 "Removed 2 mem_mallocs: error string can be a
global variable, include memory for sc_ac_cookie in struct pppoe_softc;
commented out unused code (sc_service_name/sc_concentrator_name)".
Fixes it by bailing out if received AC cookie is to big for us, this
can't really happen anyway.
There is absolutely no reason I did it this way in the first
place, maybe I feared that not all compilers have a proper
implementation of offsetof() ? It sounds stupid.
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.
Unfortunately, there is no standard way to declare a pointer with
potentially unaligned accesses. The only portable way is to create
packed struct.
VJ support uses optimized accesses to IP and TCP struct to check a
whole part of them at once to speed up the (de)compressor.
This commit wrap potentially unaligned *u16_t and *u32_t accesses with
packed struct so all compilers are able to deal with them properly.
Closes: #48308
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.
Dirk Ziegelmeier
Sylvain Rochet
goldsimon
Erik Ekman