Allow one to provide a custom implementation of free/malloc/calloc
instead of the lwip internal allocator. The code to use the libc's
implementation already existed, so generalize the existing code and make
the libc variant a specialized case of this new capability, retaining
full backwards compatibility.
lwIP might support different hardware address lengths (when using
Ethernet and 6LoWPAN for instance). Match provided lladdr length
from Router Advertisement to the current network interface instead
of comparing against longest that can be stored.
If the hostname is not set in the DISCOVER packet, then some servers might
issue an OFFER with hostname configured and consequently reject the REQUEST
with any other hostname.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Co-Authored-By: Simon Goldschmidt <goldsimon@gmx.de>
Enables to configure:
* DHCP_COARSE_TIMER_SECS
* if DHCP_DEFINE_CUSTOM_TIMEOUTS defined these addtional options are
available:
- DHCP_CALC_TIMEOUT_FROM_OFFERED_T0_LEASE to adjust the t0 lease timeout from the offered value
- DHCP_CALC_TIMEOUT_FROM_OFFERED_T1_RENEW same for t1 renew
- DHCP_CALC_TIMEOUT_FROM_OFFERED_T2_REBIND same for t2 rebind
- DHCP_NEXT_TIMEOUT_THRESHOLD to adjust the period of the next timeout
- DHCP_REQUEST_BACKOFF_SEQUENCE to adjust back-off times based on DHCP
request attempts
Also updates timeout type from u16 to u32 - eps useful when DHCP_COARSE_TIMER_SECS is a smaller number
To fix the build after ppp_output_cb started taking it as const in
commit b2d1fc119d.
Fixes this failure:
../contrib/examples/ppp/pppos_example.c: In function ‘ppp_output_cb’:
../contrib/examples/ppp/pppos_example.c:163:29: error: cast discards ‘const’ qualifier from pointer target type [-Werror=cast-qual]
return sio_write(ppp_sio, (u8_t*)data, len);
^
Authentication timer might still be running when entering network phase
for any necessary rechallenge, mostly for PPP server support.
Update the detailed analysis of simultaneously running PPP timers
taking into account the authentication timer that might still be
running and chose to increase the base number to 2 instead of
adding more unnecessary complexity.
There is no good reason why this function should take a non-const
pointer, as the output callback should never modify what lwIP gives it.
While changing that also switch to a more generic `void*` instead of
"byte".
There is no good reason why this function should take a non-const
pointer. While changing that also switch to a more generic `void*`
instead of "byte".
There is no good reason why this function should take a non-const
pointer. While changing that also switch to a more generic `void*`
instead of "byte".
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.
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.
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().
