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>
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>
We don't have to keep a helper function just for the sake of a PBUF_RAW
constant. Inline ppp_singlebuf function.
Signed-off-by: Sylvain Rochet <gradator@gradator.net>
User should not use ppp_connect or ppp_listen return value to retry
later, it must wait for the callback to be called. This is primarily
done this way to have a consistent behavior with and without the
holdoff feature.
Remove returned error value from PPP link level API connect and listen
callbacks because we are not using them anymore, then make ppp_connect
or ppp_listen to always return ERR_OK, thus we are not breaking the PPP
user API.
We don't need the return code here, all PPP link level drivers can't
fail at all (e.g. PPPoS) or retry if necessary (PPPoE and PPPoL2TP).
The check for link up was missing, meaning valid LCP echo request/reply
packets are filtered whatever the PPP state is, despite what the comment
says.
Fix it by checking the PPP state as we would like to have done when it
was written.
This function only set PPP to initialize phase, and it is only called at
the very beginning of functions where it is called. It means we could
as well set the initialize phase before calling those functions in the
PPP core.
Now that we have helpers to set those members externaly, pppos_listen
struct ppp_addrs* argument does not add any value. In addition it
was not a well chosen design choice because the user needed to keep a
copy of struct ppp_addrs when listening again for a new connection.
This function does not clear anything anymore. What it is now is an
optional way to notify PPP that link layer is started, changing the
PPP state from "dead" to "initialize". Rename it accordingly to what
the function really is.
Simon says:
ppp_init() does not seem to be used. The only thing it does is calling
magic_init(), which is not required because it its called again later
from ppp_input().
Also, the time from startup is rather constant, so calling sys_jiffies()
from ppp_init() does not create a random number.
We need to do VJ compression before CCP/MPPE compression and VJ
decompression after CCP/MPPE decompression. This leads to a massive
rewrite of how we currently handled VJ only in the PPPoS lower protocol
handler.
Moved VJ structures from pppos to ppp_pcb because we need them back in
PPP core. This is a bit unfortunate because that's not necessary for
PPPoE or PPPoL2TP, but, hey!. Fixed CCP+MPPE+VJ order.
We need to know which methods were chosen when CCP is up, this used to be done
using ccp_test() which we are in the process of removing.
Using non-existing method 0 instead of -1 in CCP for unset method, allowing
type change from s16_t to u8_t for method.
Prepare for PPP_SERVER support, we need to move auth configuration before
lcp_allowoptions is copied into lcp_gotoptions. Restore unused
auth_reset() function using pppd original source code.
Added macro PPP_AUTH_SUPPORT, if none of auth protocols are enabled
(PAP, CHAP, EAP) we reduce PPP memory usage by compiling out all
struct fields and source code used for authentication.
We only need to keep track of existing PPPoS interfaces if PPPoS
is not the only enabled protocol.
PPP CORE does not have callbacks pointers for all PPPoS callbacks
which should actually be required for PPPoS (VJ config, asyncmap, ...),
there is too much callbacks to create and PPPoS must be kept light,
especially for users who are only using PPPoS.
But there is a drawback, PPP CORE does not know which
lower protocols it is talking to thanks to the abstraction,
therefore if PPPoS is enabled as well as PPPoE or PPPoL2TP there
might be situation where PPP CORE calls pppos_ config functions
on interfaces which are NOT PPPoS one. This is very unlikely to
happen because protocols not supported by PPPoE or PPPoL2TP are
disabled at LCP/IPCP negotiation but we are better safe than sorry.
So we check if passed PPP pointer to PPPoS configuration functions
is a PPPoS interface by checking against a linked list of existing
PPPoS interfaces.
