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.
