We do not have equivalents in PPPAPI for ppp_set_* functions because
calling them only makes sense while session is disconnected, furthermore
they are only setting structure members of the session configuration.
We only have to reserve header space for forwarding for IPv4 and IPv6
packets, all other packets are PPP control packets. Doing so reduce
the need of having to coalesce the PBUF chain before PPP processes
control packets.
PPP peer can negotiate its MRU, therefore we don't know the MTU we are
going to use before starting PPP. This is an issue because netif_add
function assume that the netif init callback function will set the MTU,
netif_add will then copy mtu to mtu6. We have then to update mtu6 each
time we update mtu to keep them in sync. Doing so is fine because PPP
netif MTU is only updated when the netif is in link down state.
Our current HDLC decoder does not protect against starving the Rx
PBUF POOL for one packet, most likely due to received garbage on
the serial port.
Prevent starving the Rx pool by checking incoming packets length
against PPP_MRU with a 10% margin because we only want to avoid
filling all PBUFs with garbage, we don't have to be pedantic.
Fixes bug #58441: Invalid PPP data accumulates forever.
PPP_MRU is now free to be used for what it should have been. Now using
it at PPP init stage to set the wanted MRU value, triggering a MRU
negotiation at the LCP phase.
I doubt anyone needs it anyway, but, well, at least it is fixed and the
MRU/MTU config mess is cleaned.
And while we are at it, better document PPP MRU config values.
RFC1661 mandates that default MRU value, that must be used prior
negotiation of MRU value and if MRU value is not negotiated later, must
be 1500.
That is, any PPP host must accept control frames of at least 1500 when
the PPP session start (there are no way to split them in multiples
frames anyway) and must use a value of 1500 if MRU is no negotiated
during LCP exchanges.
Therefore, having it configurable in ppp_opts is a mistake. It was wrong
and never worked because changing the value never triggered a MRU value
negotiation because it changed both the wanted MRU value and the RFC
default value to which the wanted value is compared to trigger a MRU
negotiation if values are not equal.
Those are private functions, using the netif_ prefix here is not really
nice, especially with functions named netif_set_mtu and netif_get_mtu
for obvious reasons.
We currently retry indefinitely if sending packets fails, for example
if the output interface is down. We are even doing it if we are in
a middle of a connection process. This is not a very nice behavior
because PPP low level will retry indefinitely to connect and the user
application will never be warned that something is wrong.
We have the persist boolean in PPP settings to achieve more or less
the same thing anyway. Except it does it better at only retrying
indefinitely the initiation packet.
Having it configurable does not really make sense anymore, we already
need PBUF_RAM in all transmit paths. There are no real reason to keep
allocating PPP response buffers from the PBUF_POOL which should be now
reserved for receive paths only.
We need PBUF_RAM for quite a while for PPP, e.g. through pbuf_coalesce
and for all PPP transmit paths. There are no real reason to keep
allocating packets from PBUF_POOL for PPP control packets transmit path
by default today.
When pbuf_coalesce fails it does nothing and returns the previous buffer
chain. Adds checks that pbuf_coalesce succeeded, otherwise drop incoming
packet.
If we fail to receive a full packet, for exemple if a memory allocation
fail for some reason, we currently do not wait for next packet flag
character and we start filling a new packet at next received byte. Then
we expect the checksum check to discard the packet.
The behavior seem to have been broken one or two decades ago when adding
support for PFC (Protocol-Field-Compression) and ACFC
(Address-and-Control-Field-Compression).
Rework to drop any character until we receive a flag character at init
and when we drop a packet before it is complete.
VJ support is known to be broken when built with some compiler
optimizations enabled, disabling it by default until someone needs it
and fixes it.
It was mostly used with dial-up modems, it is useless with PPPoE and
PPPoL2TP and is probably useless as well with cellular modems, so
disabling it by default makes sense anyway.
In theory, if provided username or password is over 0x80000000 byte long
(err...), casts to signed integer of strlen() return values is going to
return negative values breaking lengths checks.
Fix it by only using unsigned integer or size_t (guaranteed to be
unsigned) comparisons.
Generating docs for file src/incl/home/travis/build/lwip-tcpip/lwip/src/include/lwip/ip4_addr.h:151:s
error: unable to resolve reference to `ip4_addr_eq' for \ref command (warning treated as error, aborting now)
Like pbuf_copy, but can copy part of a pbuf to an offset in another.
pbuf_copy now uses this function internally.
Replace pbuf_take_at loop in icmp6 with pbuf_copy_partial_pbuf().
../../../../src/../test/unit/ip6/test_ip6.c: In function ‘test_ip6_dest_unreachable_chained_pbuf’:
../../../../src/../test/unit/ip6/test_ip6.c:314:16: error: ‘main’ is usually a function [-Werror=main]
struct pbuf *main = pbuf_alloc(PBUF_RAW, sizeof(udp_hdr), PBUF_ROM);
^~~~
cc1: all warnings being treated as errors
With the payload lengths not matching between source and destination.
Also remove redundant allocation check in other test, it is now done
in the test setup code.
Fixes bug #58553, and the newly added unit test.
The pbuf_take_at loop should probably be made into a pbuf library
function, which would avoid this mistake in the future and provide
a simpler implementation of pbuf_copy.
When using LWIP_RAND_FOR_FUZZ_SIMULATE_GLIBC:
fuzz_common.c: In function ‘lwip_fuzz_rand’:
fuzz_common.c:683:11: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
683 | if (idx >= sizeof(rand_nrs)/sizeof((rand_nrs)[0])) {
| ^~
cc1: all warnings being treated as errors
User application code should be responsible to call netif_set_up() but
let's not break compatibility for now.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
NETIF_FLAG_UP flag is not supposed to be set by netif init callback
anymore, call netif_set_up() instead.
Sure it would be better to let user application code call netif_set_up()
by itself as it is now meant to be but let's not break compatibility for
now and add a FIXME for next release with allowed behavior break.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
