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.
During documentation updated LWIP_MEMPOOL_PROTOTYPE was moved inside
"#if MEMP_MEM_MALLOC" which cause ppp build to break. This patch fix that
issue.
ref commit-id: 2f950a7dcc
Signed-off-by: Ajay Bhargav <contact@rickeyworld.info>
VJ packets, Compressed packets, IPv4 and IPv6 packets are useless in
the PPP packet dump. We properly filtered IPv4 and IPv6 packets but
we forgot filtering VJ and Compressed packets.
Improve the filtering rule to filter packets which are not auth
protocol (< 0xC000) and which are not control protocol (0x8000 bit
not set).
I have below code in my cc.h:
#ifdef MYSDK_LWIP_DEBUG
#define LWIP_PLATFORM_ASSERT(x) MYSDK_ASSERTION_FAIL_ACTION()
#else
#define LWIP_PLATFORM_ASSERT(x)
#endif /* ifdef MYSDK_LWIP_DEBUG */
I got below error when in non-debug build:
src/include/lwip/debug.h:76:32: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
LWIP_PLATFORM_ASSERT(message); } while(0)
^
Fix the build error by adding braces around empty body in an 'if' statement.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: sg <goldsimon@gmx.de>
If LCP is not started yet, we are only closing the link protocol, in
this case we have to set the disconnect state ourself because PPP
is not actually started yet.
Include stdlib.h to fix below build warnings when MEM_LIBC_MALLOC is set:
src/core/mem.c:119:3: warning: implicit declaration of function 'malloc' [-Wimplicit-function-declaration]
void* ret = mem_clib_malloc(size + MEM_LIBC_STATSHELPER_SIZE);
^
src/core/mem.c:96:25: warning: incompatible implicit declaration of built-in function 'malloc'
#define mem_clib_malloc malloc
^
src/core/mem.c:119:15: note: in expansion of macro 'mem_clib_malloc'
void* ret = mem_clib_malloc(size + MEM_LIBC_STATSHELPER_SIZE);
^
src/core/mem.c: In function 'mem_free':
src/core/mem.c:146:3: warning: implicit declaration of function 'free' [-Wimplicit-function-declaration]
mem_clib_free(rmem);
^
src/core/mem.c:93:23: warning: incompatible implicit declaration of built-in function 'free'
#define mem_clib_free free
^
src/core/mem.c:146:3: note: in expansion of macro 'mem_clib_free'
mem_clib_free(rmem);
^
Signed-off-by: Axel Lin <axel.lin@ingics.com>
pppoe_softc_list is always not null when pppoe_find_softc_by_session is
called, furthermore pppoe_softc_list being null here does not hurt.
session is still checked whatsoever in pppoe_find_softc_by_session,
prechecking the session value for a value which can't really happen
except for forged frames does not add any value.
Remove unnecessary cleanup at the end of session, cleanup as much as
possible in the connect callback instead. It follows what PPPoE is
currently doing and it makes everything simpler to read.
Instead of relying on cleanup at the end of session, cleanup as much as
possible in the connect callback. It removes duplicated code and make
everything simpler to read.
While we are at it, remove useless initialization code from create
and connect functions.
ppp_close might try to close LCP even if LCP is not started, it happens
because because the PPP session might be waiting for the link protocol
to come up and we do not check that.
We say in the PPP documentation that ppp_close() can be called anytime,
so, if link protocol is currently trying to connect, we must cancel
the link connection.
Fix it by calling the link protocol disconnect callback if LCP is not
started yet.
Disconnect callback does not currently support a disconnect event while
initiation is in progress. Retry timer is not stopped and PADT frame is
sent whatever the current state is. PADT frame can only be sent if we
received a PADS frame, otherwise sc_session is 0 and sending a PADT
frame is meaningless.
Fix both issues to allow calling the disconnect callback whatever the
PPPoE state is.
We say in the PPP documentation that ppp_close() can be called anytime,
as of today, this is not entirely true, there are still conditions that
are not handled properly.
If PPP is already disconnecting, ppp_close() must do nothing and returns
ERR_INPROGRESS instead of messing up the PPP disconnection state.
Master state is almost exactly the same thing as dead state, move it
next to dead state. Holdoff state is actually the state just before
initialize, move it before initialize.
The goal is to be able to use > running or => terminate condition to
check a currently running disconnection phase, which is not possible
today without excluding master and holdoff states.
PPP_PHASE_MASTER state is only used if multilink mode is enabled. Since
we don't support multilink mode checking for this state only add some
code for no value added at all.
Build-out PPP_PHASE_MASTER state check if multilink mode is disabled.
Van Jacobson TCP header compression only apply if TCP is enabled,
therefore we need to disable VJ compression if TCP is disabled.
We already have conditions to enforce VJ disabling if IPv4 is disabled
or if PPPoS is disabled, add TCP to those conditions and remove
unecessary VJ_SUPPORT && LWIP_TCP conditions.
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.
PPP is currently in initialize phase until authentication is started
or until we start IPCP negotiation.
It works, because PPP states are mostly used for user information, most
state are actually useless for PPP itself. Being in initialize state
while PPP is started is not very consistent, switch to establish phase
before starting LCP.
sc->sc_ethif can't be NULL, it is set definitively in pppoe_create.
PPPoE can't by anything else than PADI sent in pppoe_send_padi, it
is only called when this is true.
PPPoE state can't be anything else than initial state in
pppoe_connect, this function is called from PPP core only when PPP
is in the dead phase, if PPP is in the dead phase it means the link
protocol is dead as well.
PPPoE can't be anything else than data phase in pppoe_disconnect
this function is only called by PPP core only when PPP session is up,
if PPP session is UP it means the link protocol is UP as well.
PPPoE can't by anything else than PADR sent in pppoe_send_padr, it
is only called when this is true.
PPPoE can't by anything else than PADO sent in pppoe_send_pado, it
is only called when this is true.
PPPoE can't by anything else than PADO sent in pppoe_send_pads, it
is only called when this is true.
PPPoE can't be anything else than session phase in pppoe_xmit,
function is only called by pppoe_write and pppoe_netif_output
which are both called by PPP core only when PPP session is up, if
PPP session is UP it means the link protocol is UP as well.
L2TP state can't be anything else than initial state in
pppol2tp_connect, this function is called from PPP core only when PPP
is in the dead phase, if PPP is in the dead phase it means the link
protocol is dead as well.
L2TP can't be anything else than data phase in pppol2tp_xmit, this
function is only called by pppol2tp_write and pppol2tp_netif_output
which are both called by PPP core only when PPP session is up, if
PPP session is UP it means the link protocol is UP as well.
L2TP can't be anything else than data phase in pppol2tp_disconnect,
this function is only called by PPP core only when PPP session is up,
if PPP session is UP it means the link protocol is UP as well.
When we are disconnecting, we should switch to PPP dead phase at the
very end, because this is our final disconnection phase allowing
reconnect, therefore we should switch to dead phase after the link
protocol finished disconnecting.
We are currently switching to dead phase when LCP detected that the link
is down, this is obviously wrong. Fix this flaw by continuing in
disconnect phase until ppp_link_end is called from link protocol.
In the BSD socket API world, IP_HDRINCL is a socket option for "raw"
sockets that indicates whether sent packets already include an IP
header. Within lwIP, "IP_HDRINCL" is redefined as a special value
that indicates to lwIP-internal functions that an IP header is already
included. While somewhat related, the two meanings are different and,
on platforms that define the IP_HDRINCL socket option, this results in
a conflict. This patch renames the lwIP one to "LWIP_IP_HDRINCL",
thus resolving the conflict.
Doxygen does not handle #ifndef foo #define foo #endif properly. It does not see the #define foo inside.
If someone has objections or a fix for it, please tell me.
Inspired by Marco Veeneman. Change signature of get_value function to return s16_t, where values <0 indicate an error. This is mapped to SNMP_ERR_GENERROR.
- support memp stats when MEMP_MEM_MALLOC==1 (bug #48442);
- hide MEMP_MEM_MALLOC in memp.c instead of messing up the header file;
- make MEMP_OVERFLOW_CHECK work when MEMP_MEM_MALLOC==1
This reverts commit d43c092f17.
We don't actually need it, init.c is including ppp_opts.h and is doing
the following:
#if !LWIP_ETHERNET && (LWIP_ARP || PPPOE_SUPPORT)
#error "LWIP_ETHERNET needs to be turned on for LWIP_ARP or PPPOE_SUPPORT"
#endif
so the LWIP_ETHERNET fixup is not necessary per se, compatibility with
previously used lwipopts.h files is broken but at least user is warned.
Ethernet support is required for PPPoE but Ethernet support is only set
by default in opt.h if ARP is enabled, which is wrong because the right
condition is ARP and/or PPPoE, unfortunately PPPOE_SUPPORT can't be used
in opt.h because it is not defined if ppp_opts.h is not included before
opt.h in user code.
Fixup the LWIP_ETHERNET configuration value in ppp_opts.h in order to
force Ethernet support if PPPoE is enabled.
Fixes: 3ad2ad2329 ("Remove reference to PPPOE_SUPPORT in opt.h - leads
to compile errors because it has no default definition (only in
ppp_opts.h)"
