An edge case in out-of-sequence TCP packet processing did not use the
appropriate macro to check if the sender overran the recieve window.
Consequently, this case sometimes evaluated to true when it shouldn't, which
resulted in various bad behavior, including trying to resize a TCP buffer to 4
gigabytes.
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.
Reduced static buffer to the strict necessary (26 bytes), removed
call to eui64_ntoa(), merged eui64_ntoa() into llv6_ntoa().
272 bytes (code + static buffers) to 140 bytes on x86_64.
Improved eui64_ntoa() as well, we don't need it anymore but I'd
like to keep all eui64_* helpers functions.
Set IPv6 link local invalid before clearing it. Don't wait sif6up() to set
the link local valid, netif_ip6_addr_set_state() is only an accessor function
so it does not start any discovery whatsoever.
PPPoS was actually not thread safe, pppos_input() can be called from
lwIP user port at any time, whatever the PPP state is. It might even be
called during pppos_connect() and pppos_listen(), this is quite unlikely
the port do that but nothing prevent the user to since we document
pppos_input() as being thread safe.
Added a mutex if PPP_INPROC_MULTITHREADED is set and ensure pppos_input()
is safe in regard to other pppos_* functions.
Now setting DNS addresses in sdns() using dns_setserver() instead
of keeping a local copy. This is probably the wanted PPP behavior,
we will see if users want this conditional.
This was confusing, recent lwIP changes fixed the meaning as well as
how it is used everywhere, making the administrative status a user-only
controlled flag. Now that it's clear, updated PPP to follow lwIP
core change.
Using netif_set_link_{up,down} instead of netif_set_{up,down} when PPP
reaches/leaves running state. PPP interface is now set to administratively
UP when created with link state down.
lwIP core might send packet when calling netif_set_up(), don't drop packets
anymore in ppp_netif_output_ip4() and ppp_netif_output_ip6() because flags
are cleared.
Only used for debug, reworked in a more clever way. It was actually broken
by design: setting an interface integer into a string without formatting
was quite a dumb idea.
