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.
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.
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
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.
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.
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.
Use LWIP_ARRAYSIZE to simplify the code.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Sylvain Rochet <gradator@gradator.net>
[Sylvain Rochet <gradator@gradator.net>: added missing casts]
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
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.
Work on PPP MEMPOOL re-added the previously removed ppp_init function
because we considered it useless. Re-add magic_init which was
previously in ppp_init and removed in commit 15fbfb7363, it does
not hurt doing so and might fill the gap if we failed understanding
the crypto implication about removing it.
Simon says:
ppp_init() does not seem to be used. The only thing it does is calling
magic_init(), which is not required because it its called again later
from ppp_input().
Also, the time from startup is rather constant, so calling sys_jiffies()
from ppp_init() does not create a random number.
Create special IP address type "IPADDR_TYPE_ANY" for it.
SNMP uses new feature in non-netconn mode.
TODO: Same for TCP & RAW, adapt NETCONN to use this feature
We used to modify in place the packet payload during compression but TCP
stack requires that we don't change the packet payload, therefore we now
copy the whole packet before compression.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
Prepare for VJ packet copy, reorder a bit VJ compressor so all TYPE_IP
return value are within the same code block. We do that because we don't
need to copy the packet if we are not able to compress it.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
lwIP TCP stack requires that we don't change the packet payload in netif
output functions in order to resend the pbuf if we don't receive a TCP
ACK in time, therefore we copy the whole packet before compression or
encryption.
It gets tricky because we should keep track of whether we previously
copied the buffer in PPP output netif function in order to free the
previous pbuf if necessary, BUT the first pbuf passed to the netif
output function must not be freed.
The worst case is VJ compression followed by MPPE encryption, in this
case we should free the packet allocated by VJ compressor after MPPE
encryption and we should free the packet allocated by MPPE encrypter
after calling the PPP low level output function.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
long type on LP64/ILP64 systems (such as x86_64 on Linux) is 8 byte
long, this leads to wrong offsets in packets header calculation.
Fixed it by using u32_t lwIP type instead of long type.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
It might be difficult to investigate the reason of dropped packets when
there is no debug notification of what is happening, thus, add error
debug messages for dropped packets due to missing transmit or receive
CCP method.
Signed-off-by: Stephan Linz <linz@li-pro.net>
[gradator@gradator.net: improved messages]
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
ppp_free() calls the low level protocol destroy function, pppol2tp_destroy()
here, which freed the l2tp pcb, followed by pppol2tp_create which also freed
the pcb.
Fixing it by reordering the L2TP init so we don't have to call ppp_free()
anymore.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
When I create a new PPP connection, I am seeing a hardfault (segfault)
coming from pbuf_free.
I traced the problem to an invalid in_head field of the pppos_pcb structure.
The field is invalid because the memory is never cleared to zero after the
pppos_pcb structure is created in pppos_create().
I was able to fix the issue by adding a memset after the memp_malloc call.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
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>
- include new SNMP header
- add missing pointer type casting
- add missing default cases
- use const for all ip address types
- distinguish between IPv4 and IPv6 address types
Signed-off-by: Stephan Linz <linz@li-pro.net>
lwip/src/netif/ppp/mppe.c: In function `mppe_rekey':
lwip/src/netif/ppp/mppe.c:74:15: error: declaration of`sha1' shadows a global declaration [-Werror=shadow]
lwip/src/include/netif/ppp/polarssl/sha1.h:88:6: error: shadowed declaration is here [-Werror=shadow]
Older compilers don't like variables with the same name as
global functions. md5.h contains a function md5(), rename
md5 variable in magic.c to md5_ctx.
Older compilers don't like variables with the same name as
global functions. md5.h contains a function md5(), rename
md5 variable in magic.c to md5_ctx.
lwip/src/netif/ppp/magic.c: In function `magic_churnrand':
lwip/src/netif/ppp/magic.c:105:15: error: declaration of `md5' shadows a global declaration [-Werror=shadow]
lwip/src/include/netif/ppp/polarssl/md5.h:88:6: error: shadowed declaration is here [-Werror=shadow]
lwip/src/netif/ppp/magic.c: In function `magic_random_bytes':
lwip/src/netif/ppp/magic.c:165:15: error: declaration of `md5' shadows a global declaration [-Werror=shadow]
lwip/src/include/netif/ppp/polarssl/md5.h:88:6: error: shadowed declaration is here [-Werror=shadow]
Older compilers (GCC 4.6) don't like variables with the same name as
global functions:
lwip/src/netif/ppp/lcp.c: In function 'lcp_received_echo_reply':
lwip/src/netif/ppp/lcp.c:2685:11: error: declaration of 'magic' shadows a global declaration [-Werror=shadow]
lwip/src/include/netif/ppp/magic.h:101:7: error: shadowed declaration is here [-Werror=shadow]
magic.h contains a function named magic(), so rename the variable.
It used to be this way because the original implementation was close to
the hardware and used a free running 16 bits timer so it was necessary.
Currently what it is only doing is removing potential entropy we might
get from upper bits, that's a bad idea.
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.
Added the random seed already used without PPP_MD5_RANDM
as an entropy source when PPP_MD5_RANDM feature is enabled.
(And a little bit of code cleaning for both)
If LWIP_RAND() is available, it is used instead of libc srand()/rand()
if PPP_MD5_RANDM is disabled and it is added as a source of randomness
if PPP_MD5_RANDM is enabled.
A disabled PPP_MD5_RANDM should not be used when challenge are used, but
anyway, improved magic_randomize() so magic_randomseed is not equals to
sys_jiffies() which is pretty useless because that's fully predicable.
The only API difference with and without the PPP_MD5_RANDM support is the
availability of the random_bytes() function. Added a random_bytes()
function on top of magic() when PPP_MD5_RANDM support is not enabled,
thus allowing builds for both cases.
PPP_MD5_RANDM is still enabled by default (it was mandatory) if a protocol
using encryption is enabled, such as CHAP, EAP, or L2TP auth support.
There is no point of calling magic_randomize() for each pppos_input()
call, making magic_randomize() potentially called for each serial input
byte which is quite a bad idea since magic_randomize() is quite
intensive in processing time (MD5 computation) compared to HDLC frame
parsing. There is no entropy added when being called for each input byte
rather than for each valid input packet because byte input is a
monotonic event at the packet level. Well, if packet arrival time is a
valid entropy source even so, which I doubt a lot, but we don't really
have anything else and we really need random for PPP authentication
layers.
Drop input/output packets if we couldn't find a decompressor/compressor,
it can't really happen because we only negotiate what we are able to
compress/decompress, but for the sake of code consistency it makes much
more sense to do so.
We used to modify in place the packet payload during encryption, it works
well for UDP and ICMP but TCP stack requires that we don't change the
packet payload, therefore we now copy the whole packet before encryption.
When PPP is used over a link which does not guarantee packet ordering,
we might get late MPPE packets. This is a problem because MPPE must be
kept synchronized and the current implementation does not drop them and
rekey 4095 times instead of 0, which is wrong.
In order to prevent rekeying about a whole count space times (~ 4095
times), drop packets which are not within the forward 4096/2 window and
increase sanity error counter.
