e.g. if the calling stack should not invoke the mdns functions due
to high stack usage, disable the option and trigger it yourself.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Also remove additonal (cname == '\0' || cname == '.') check because
it's covered by !lwip_isupper(cname) test.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
If a chained pbuf starts with DHCP_OPTION_PAD, an overflow check
triggers and the packet is ignored.
Fix this by changing the way the offset is increased for PAD.
Also ignore a packet that is missing the END option.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Can be combined into a single check using LWIP_MIN.
See bug #54194
Reported-by: Andrey Vinogradov <andrey.vinogradov@teplomonitor.ru>
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Fix below build error:
In file included from
../../../../lwip/src/../test/unit/tcp/test_tcp.c:3:0:
../../../../lwip/src/../test/unit/tcp/test_tcp.c: In function
‘test_tcp_rto_timeout_syn_sent_impl’:
../../../../lwip/src/../test/unit/tcp/test_tcp.c:1246:113: error: suggest parentheses around arithmetic in operand of ‘|’ [-Werror=parentheses]
const u16_t tcp_syn_opts_len = LWIP_TCP_OPT_LENGTH(TF_SEG_OPTS_MSS|TF_SEG_OPTS_WND_SCALE|TF_SEG_OPTS_SACK_PERM|TF_SEG_OPTS_TS);
^
../../../../lwip/src/include/lwip/priv/tcp_priv.h:305:4: note: in definition of macro ‘LWIP_TCP_OPT_LENGTH’
(flags & TF_SEG_OPTS_MSS ? LWIP_TCP_OPT_LEN_MSS : 0) + \
^~~~~
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Fail to build if PPP_SUPPORT is disabled because PPP_NUM_TIMEOUTS
references defines that are unknown if PPP_SUPPORT == 0. Move
PPP_NUM_TIMEOUTS to PPP_SUPPORT block and set a default value to 0
if PPP_NUM_TIMEOUTS is still not defined at the end of ppp_opts.h.
Fixes: e4e0fc4193 ("PPP: set PPP_NUM_TIMEOUTS_PER_PCB value to computed number of simultaneous timers")
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
A deep analysis of simultaneously running timers showed we can use a
slightly smaller value for PPP_NUM_TIMEOUTS_PER_PCB, value which was
arbitrarily chosen to a safe value based on the number of enabled PPP
features. Add the boring and long analysis to the end of our internal
header file and use the result in ppp_opts.h.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
Only the transmission side works for now (todo: dual and tradeoff mode).
Also, only a 10 second timeout mode is implemented for now.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Managed to find the spirit behind the RFC. Looks like we need to send
a ZLB packet with counters as is to the packet (ZLB or not) we
previously sent to ack the message. Luckily we don't need more than
received NS/NR counters to forge the resent ack.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
We never use the current peer NS value but always the next expected peer
NS value (current value plus one).
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
Conform a little bit more to the RFC by dropping duplicate received
packets. It might help discover Ns sequence issues.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
It can't be an issue since we only send and receive a few L2TP control
packets and we don't care about anything received next other than
sending Ack packet. For the sake of correctness properly handle Ns/Nr
counters wraparounds, it doesn't add more code anyway.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
L2TP tunnel is really UP only once we received the ICCN Ack packet,
generally with a ZLB packet. We actually drop all data packets until
we reach the "data" L2TP state, which is a sane thing to do, therefore
it makes no sense at all to start the PPP session a bit earlier.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
