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.
Check tot_len for ZLB instead of len, it might happens we are just
between 2 pbuf, although almost impossible.
Check buffer is at least 2 byte long before checking address & flags
header.
PBUF_LINK_ENCAPSULATION_HLEN support was introduced by 6ef7563f and
missed the fact that header size calculation/reservation using
computation like PBUF_LINK_HLEN + PBUF_IP_HLEN + ... are used all over
the source code. Hopefully fixed all of them.
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.
We need to know which methods were chosen when CCP is up, this used to be done
using ccp_test() which we are in the process of removing.
Using non-existing method 0 instead of -1 in CCP for unset method, allowing
type change from s16_t to u8_t for method.
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.
MSCHAP was written the old-way, with all functions declared non static in
header, independent of their local or global scope status. Same for local
constants. Reworked in a more mordern way.
We are going to need ppp_pcb* in MSCHAP and MSCHAPv2 for MPPE for
int mppe_keys_set, u_char mppe_send_key and u_char mppe_recv_key
which are currently global variable which must be moved to ppp_pcb.
Removing a bit of redundancy and previous artefact of a generic kernel
interface. Exporting mppe_init() instead of mppe_comp_init() plus
mppe_decomp_init().
We are going to use statically allocated struct ppp_mppe_state through PPP PCB,
removed now useless mppe_alloc() and mppe_free().
Merged mppe_alloc() key copy to mppe_init().
ccp_test() is not only used to test kernel support, but also to set MPPE keys,
we will change that further, but for now, re-add the necessary ccp_test()
Our PPP stack deals with packet without address and control byte nor 2-byte
protocol field, improved mppe_compress() so we don't have to worry about
them.
Our PPP stack deals with packet without address and control byte nor 2-byte
protocol field, improved mppe_compress() so we don't have to worry about
them.
If LWIP_IPV4 is true but PPP_IPV4_SUPPORT is false, we need
a dummy ppp_netif_output_ip4() callback because we don't have
a netif_null_output_ip4() by default like we have for IPv6 with
netif_null_output_ip6().
Removed ppp_singlebuf() in pppol2tp_input(), chained pbuf are perfectly
acceptable for IP data and we are currently supporting them perfectly
for PPPoS. The PPP stack itself (LCP, IPCP et al.) does not support
chained pbuf and is already calling ppp_singlebuf() just before passing
packet to the protocol handler.
Added ppp_singlebuf() in pppol2tp_dispatch_control_packet() because we
do not support chained pbuf in L2TP control packet.
mppe_decompress() now takes a pointer to a pbuf pointer and re-use the
passed buffer for MPPE "decompression". Removed sub protocol handling
which can be shared among all decompressors in ppp.c
Removed ppp_singlebuf() in pppoe_data_input(), chained pbuf are
perfectly acceptable for IP data and we are currently supporting them
perfectly for PPPoS. The PPP stack itself (LCP, IPCP et al.) does not
support chained pbuf and is already calling ppp_singlebuf() just before
passing packet to the protocol handler.
Our PPP stack deals with packet without address and control byte nor 2-byte
protocol field, improved mppe_decompress() so we don't have to worry about
them.
In PPP, we previously know if we are dealing with a IPv4 or a IPv6 packet,
we don't need to use the ip_input() dispatch function, removing a useless
if and reducing call stack by one.
We don't need anymore an input function for ip4 and an input function
for ip6, work to achieve that was partially done by ce7e31cd.
pppol2tp_input() is now only called by pppol2tp_input_ip(), finishing
dual stack support by merging pppol2tp_input_ip() into pppol2tp_input().
Replaced ip4_addr_t to ip_addr_t in pppapi_pppol2tp_create() prototype,
now binding to UDPv6 or UDPv4 depending on the passed ip_addr_t type.
Removed pppol2tp_create_ip6() and pppapi_pppol2tp_create_ip6().
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
We don't need "compression" stats on a encryption protocols, as commented
"Since every frame grows by MPPE_OVHD + 2 bytes, this is always going
to look bad ... and the longer the link is up the worse it will get."
This file, which is an unmodified copy of Linux MPPE encoder/decoder, is
licensed under a dual License BSD/GPL model. It was previously in the
pppd source tree and it was removed because this is merged into the Linux
kernel.
We don't need to test our available compression protocols that much, we know
what we are going to be able to use in embedded. Even PPPd don't need that.
Checking only in ccp_resetci() is enough, this way we know our cilen size
before ccp_addci() is called. PPPd is designed that *_addci() can use less
bytes than it previously asked in *_cilen(), we prefer to avoid that here.
We actually don't need at all ccp_test() calls, we know what we are
able to support at compile time, we don't need to ask the kernel like
PPPd does. This is just the first step in ccp_test() removal.
