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
Reproducer (in bash):
base64 -d <<< "H4sIAP/9L2QCA+3WoQ2AMBSE4QoCTFHBBJfgSRF4RDfpRmgmYBpGQRBCk4ZiSfk/+fJMK+5dZRVpzSQzSs6oPierDV4y87WxLQLwE42SfNCdDyHJB9/xZwAARPbMJbUq4JJmu4JVT1cAAACfbGIqoqcMzy90eu+aBw2+N28WFgAA" | gunzip | test/fuzz/lwip_fuzz2
Crash log:
../../src/core/altcp_tcp.c:178:13: runtime error: member access within null pointer of type 'struct tcp_pcb'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../src/core/altcp_tcp.c:178:13 in
AddressSanitizer:DEADLYSIGNAL
=================================================================
==192415==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000048 (pc 0x557065081703 bp 0x0aae0cb71204 sp 0x7ffd034dabc0 T0)
==192415==The signal is caused by a READ memory access.
==192415==Hint: address points to the zero page.
#0 0x557065081703 in altcp_tcp_setup_callbacks /.../lwip/test/fuzz/../../src/core/altcp_tcp.c:178:19
#1 0x55706508206f in altcp_tcp_setup /.../lwip/test/fuzz/../../src/core/altcp_tcp.c:189:3
#2 0x55706508206f in altcp_tcp_accept /.../lwip/test/fuzz/../../src/core/altcp_tcp.c:84:5
#3 0x557065095592 in tcp_input /.../lwip/test/fuzz/../../src/core/tcp_in.c:380:9
#4 0x5570650e752f in ip4_input /.../lwip/test/fuzz/../../src/core/ipv4/ip4.c:743:9
#5 0x55706513d4de in ethernet_input /.../lwip/test/fuzz/../../src/netif/ethernet.c:186:9
#6 0x557064fe0959 in input_pkt /.../lwip/test/fuzz/fuzz_common.c:209:9
#7 0x557064fdeb6a in input_pkts /.../lwip/test/fuzz/fuzz_common.c:257:9
#8 0x557064fdeb6a in lwip_fuzztest /.../lwip/test/fuzz/fuzz_common.c:669:3
#9 0x7ff4f578e189 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#10 0x7ff4f578e244 in __libc_start_main csu/../csu/libc-start.c:381:3
#11 0x557064f20420 in _start (/.../lwip/test/fuzz/lwip_fuzz2+0x81420) (BuildId: 8680a96430d5749c90111fe9c3a3d4f881a5dbcd)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /.../lwip/test/fuzz/../../src/core/altcp_tcp.c:178:19 in altcp_tcp_setup_callbacks
==192415==ABORTING
Aborted
When using multiple netifs on one hardware interface (e.g. when mapping multiple IP addresses to one hardware interface), if the netif's low-level receive routine cannot decide for the correct netif, here the `netif` parameter may be a default netif, in this case, `p-> if_idx` will get a wrong netif index value. It should be placed after `netif = LWIP_ARP_FILTER_NETIF_FN(p, netif, lwip_htons(type));`. Filter function can returns the correct netif before assigning `p-> if_idx`.
This fixes downloads longer than 15 seconds.
See bug #60787 (http_client does not reset timeout counter)
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Update to cxong/tinydir commit 97a6032ddb ("Fix tinydir_file_open for root or subfolder of root in Linux.")
This should fix bug #61106 (compiling newest source fails with "-O3" optims)
When a registered netif ext-callback unregisters itself when being
called (e.g. because some state is reached by this event), the invoke
iteration might access uninitialized memory or at least stop the
iteration (because next is set to null).
Fix his by caching the next pointer during iteration before calling
callbacks.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
It turns out the crash only occurs if LWIP_DEBUG is enabled. If the
parameter dest is NULL the function tries to find a route using the
destination address of the packet instead. If this fails as well a
debug message is printed but it is still using dest causing a NULL
pointer dereference and crash at src/core/ipv6/ip6.c line 1312.
[erik@kryo.se: Apply fix to ip6_output_hinted as well]
This simple patch causes tcp_listen() to inherit the netbuf_idx setting
of the original pcb. Without this, it is not possible to restrict a
socket to a specific interface using SO_BINDTODEVICE before listening.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
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.
upap_timeout is not currently stopped on authentication success or
fail events. This may have strange results if session is restarted
in a high pace because even if the timeout callback have a sanity
check against the PAP state the session can be restarted and be
back in the valid state before the timeout callback is actually
called.
Do not assume LWIP_RAND will return 32 bits of randomness because it is
probably going to be defined to directly return the rand() value. For
example, LCP magic numbers are 32-bit random values.
This is already what we inherently have always done for IPv4/IPv6
packets, so it works. Receivers must handle both cases anyway because
both behaviors are seen in the wild.
A previous call to ppp_input might have disconnected the session while
there were still packets in flight in the tcpip mailbox. Drop incoming
packets because ppp_input must never be called if the upper layer is
down.
Speed-up a little bit the PPPoS input parser by only checking the open
flag after calling the ppp_input function, the only one that can induce
a state change here.
ppp_set_* functions that set the PPP session parameters must only be
called when the session is in a dead state (i.e. disconnected),
otherwise not fatal but surprising results may happen.
This function call the notify phase callback that should be called from
the lwIP core thread. This is especially true if the user callback
is not designed to be reentrant.
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".
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.
