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>
Our Ns counter is the current slot rather than the next to ease packet
retransmission. Therefore we increment the Ns counter before using the
next slot instead of after. The RFC is written with post-increment in
mind rather than pre-increment, thus when the RFC says that Ns in not
incremented for ZLB packets it actually means that ZLB packets are sent
with the next Ns without post-incrementing the Ns value, meaning the
ZLB packet does not take a slot. Since we are using a pre-incremented
value for real slots we need to send ZLB packets with our current Ns
value plus one.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
lwip/src/netif/ppp/pppoe.c: In function ‘pppoe_send_padt’:
lwip/src/netif/ppp/pppoe.c:1048:108: error: ‘sc’ undeclared (first use in this function)
sc is not passed to ‘pppoe_send_padt’ function because it might be
called to terminate unknown sessions.
Fixes: d4047ea1d1 ("Try to fix issues reported by coverity")
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
The new NULL checking against netif_input_fn make ppp stop working
because in ppp_new() it calls netif_add with NULL netif_input_fn.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
This partly reverts 31bc2f9b which broke pppos tx as 'pppos_output_append'
implements a custom scheme of checking available pbuf size.
Added a comment why PBUF_POOL is ok for tx in this special case.
See bug #51908
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
