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.
Follow-up of the #44565 bug fix, renamed the misnamed
PPP_INPROC_MULTITHREADED to PPP_INPROC_IRQ_SAFE because it is
IRQ safe but not thread safe.
Updated PPP documentation which now clearly state when and how
this feature can be used.
lwip/src/netif/ppp/pppol2tp.c: In function ‘pppol2tp_udp_send’:
lwip/src/netif/ppp/pppol2tp.c:1229:3: warning: ‘err’ may be used uninitialized in this function [-Wmaybe-uninitialized]
return err;
^
Renamed pppos_drop() → pppos_input_drop()
Renamed pppos_free_current_input_packet() → pppos_input_free_current_packet()
Moved pppos_output_last() after pppos_output_append()
Moved pppos_input_free_current_packet() before pppos_input_drop()
We actually allocated a pbuf chain only to iterate later the linked list
calling sio_write() for each pbuf, improved by calling sio_write() when
buffer is full and by recycling the pbuf, therefore only using one pbuf
for PPPoS output path.
Reworked pppos_write() and pppos_netif_output() to share more common
code into pppos_output_append() and pppos_output_last().
If PPP_INPROC_MULTITHREADED is true, then user does not what to use
the TCPIP API. Disabling the TCPIP API helps the user to understand
that PPP_INPROC_MULTITHREADED must not be used if he wish to use
the TCPIP API.
!NO_SYS users may now use as well the TCPIP API for PPPoS input data,
this way they can disable PPP_INPROC_MULTITHREADED and run pppos_input()
inside the lwIP thread, which fixes, at least for them, all the
threading issues related to PPP_INPROC_MULTITHREADED.
If PPP_INPROC_MULTITHREADED is not enabled, we can free unfinished
RX pbuf from the pppos_disconnect() function because pppos_input()
is running in the same context. Thanks to the pppos->open flags we
now only need to free remaining pbuf in the disconnect function
if PPP_INPROC_MULTITHREADED is not enabled.
Don't process input data if PPPoS is closed, it helps using
pppos_input() from a different context to prevent pppos_input() to
modify PPPoS RX machine state on a closed PPPoS session. It also
prevents allocating pbuf (which are going to be tossed out by PPP core)
and parsing serial input on a closed session.
It only mitigates the fact that this function is actually NOT thread
safe in absolutely all cases, it does not fix it but it helps for a low
cost.
For example user application should never call pppos_input() while
pppos_connect() or pppos_listen() is currently running because both of
them are freeing any input pbuf left over from the last session before
resetting the PPPoS state, they really have to to prevent pbuf leaks.
We cannot fix that easily because we don't have spinlock with an
irqsave/irqrestore helper for IRQ contexts. Mutex cannot be used in
interrupt contexts (or again, with an IRQ mutex helper).
We are going to improve the documentation on this point.
