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>
This reverts commit 6e7ea92d56e43de65c46396b82ceebce2b95e8af.
We better forbid building configurations that does not make sense instead
of bloating the code with more ifdef. Here building CCP support without
adding any compressor support serve no real use case.
This adds some basic checks to the subroutines of eap_input to check
that we have requested or agreed to doing EAP authentication before
doing any processing on the received packet. The motivation is to
make it harder for a malicious peer to disrupt the operation of pppd
by sending unsolicited EAP packets. Note that eap_success() already
has a check that the EAP client state is reasonable, and does nothing
(apart from possibly printing a debug message) if not.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Sylvain Rochet <gradator@gradator.net> (ported to lwIP PPP pcb struct)
Given that we have just checked vallen < len, it can never be the case
that vallen >= len + sizeof(rhostname). This fixes the check so we
actually avoid overflowing the rhostname array.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Sylvain Rochet <gradator@gradator.net> (compiler warning fix about int vs uint comparisons)
This converts all ppp_*() debug functions to ppp_*(()) macros that
ensure the code is left out by the linker if the corresponding debug
setting is disabled.
Downside is that many lines of code are touched, but since these
already differ to upstream PPP sources, I figured that's ok...
See bug #55199
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Replace '\n' with '<br>', as this allows doxygen to understand reference
names followed by newline. For some cases just drop the newline if it's
not required.
Doxygen 1.8.15 doesn't like if the name of reference is followed by
anything else than (selected?) punctuation or whitespace.
bug #56004
Make pppoe_create() actually store the passed service name and
concentrator name, so that they are passed in the PADI/PADR/PADS
packets.
Assume that the user application won't be freeing the strings and just
copy the string pointers, therefore remove the mem_free() in
pppoe_destroy().
Since only the pointers are copied now, make them 'const' in
pppoe_softc.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
Rename PPPOE_TODO to PPPOE_SCNAME_SUPPORT because this is the only
feature enclosed by them. Prepare for proper service name and
concentrator name support by moving PPPOE_SCNAME_SUPPORT define to
ppp_opts.h.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
pppos_input() is safe to call from outside tcpip_thread when
PPP_INPROC_IRQ_SAFE == 1, so only check if PPP_INPROC_IRQ_SAFE == 0
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Reverts a regression introduced in
3a8af612b3b818a89de5846cc9b046756af184cc:
Use hardware address fetched from neighbor cache *not* the hardware
address of the interface as destination address.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
magic_init() is first time called from ppp_init(), which is called from
lwip_init(). If system has no RTC, sys_jiffies() returns same value in
this moment after every power-up or system reset. This value used in LCP
magic number generation after ppp_connect(), which leads to same magic
number after every restart. Subsequent magic_randomize() calls takes
place in ppp_input(), after magic number generation.
Call magic_randomize() somewhere near start of ppp_connect() (and
ppp_listen()) as it might be called later at a random time.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
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: d4047ea1d185 ("Try to fix issues reported by coverity")
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
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>
