- SNMPv2c support
- Greatly reduced RAM usage, no memory pools any more
- API cleanup
- MIB2 is separated from SNMP stack
- Support for multiple MIBs (snmp_set_mibs call) - e.g. for private MIB
- Improved MIB2 implementation (tcpConnTable etc.)
- Redesigned simple and generic API for MIB implementation
- Comfortable node types for scalar arrays and tables
- Counter64, bit and truthvalue datatype support
- Callbacks for SNMP writes
- Runs on two APIs: RAW and netconn
- Async API is gone - the stack now supports netconn API instead,
so blocking operations can be done in MIB calls.
SNMP runs in a worker thread when netconn API is used.
- Simplified thread sync support for MIBs - useful when MIBs
need to access variables shared with other threads without locking
(used in MIB2 to access lwIP stats from lwIP thread)
Currently in work:
- Traps rewrite
- MIB compiler
When LWIP_RAND is defined, calling LWIP_RAND() is not necessary if max_time <= 2
because group->timer will be set to 1 anyway.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Problem is that declaring functions as static in a public header will produce warnings in every file it is included because the static functions are not implemented.
Solution: When socket api is enabled, netconn is simply available, too
(Socket api uses netconn api internally)
tcpip_callback_with_block() can fail with ERR_MEM or ERR_VAL, and in the
error paths the code does not post the msg to the mailbox thus the
sys_sem_wait() call might wait forever. Fix it by testing return value of
tcpip_callback() and return error immediately.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
I got below build warning if LWIP_HOOK_MEMP_AVAILABLE is defined.
src/core/memp.c: In function 'memp_free_pool':
src/core/memp.c:352:16: warning: variable 'old_first' set but not used [-Wunused-but-set-variable]
struct memp *old_first;
^
src/core/memp.c: In function 'memp_free':
src/core/memp.c:413:6: warning: 'old_first' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (old_first == NULL) {
The LWIP_HOOK_MEMP_AVAILABLE() hook does not work, fix it.
Fixes: c838e1ed5b ("Implement possibility to declare private memory pools")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
LWIP_NETCONN and LWIP_SOCKET are defined in opt.h,
so move #include "lwip/opt.h" out of #if LWIP_NETCONN || LWIP_SOCKET guard.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
pbuf_alloc() for PBUF_RAM type always return big enough memory on success.
So checking p->len is not necessary. Testing if p is NULL or not is enough.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Current code already checks memp_overflow_check_all() in memp_free() if
MEMP_OVERFLOW_CHECK >= 2. So in memp_free_pool(), it should use
MEMP_OVERFLOW_CHECK == 1 instead.
Fixes: c838e1ed5b ("Implement possibility to declare private memory pools")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
The h will point to NULL if h->next->next is NULL anyway.
So remove the unnecessary NULL test for h->next->next in each iteration.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
There should be no duplicate pcb in raw_pcbs/udp_pcbs list.
So the implementation of raw_remove()/udp_remove() can break from the for
loop once the target pcb is found and removed from the list.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
The TCPIP_APIMSG_ACK will call NETCONN_SET_SAFE_ERR for both
LWIP_TCPIP_CORE_LOCKING and !LWIP_TCPIP_CORE_LOCKING cases.
So remove superfluous NETCONN_SET_SAFE_ERR call before TCPIP_APIMSG_ACK.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
The logic to use an already existing pcb is wrong because the idx never
advanced in the for loop, so it keep checking the same dns_pcbs[idx] for
each loop iteration. Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
This commit updates the snd_queuelen comment documentation to reflect
that snd_queuelen tracks the number of pbufs currently in the send
buffer (unsent + unacked queues) rather than the number of pbufs
available in the buffer (which was what previous comment implied)
This commit updates socket option comments to reflect which ones are
currently supported:
* SO_REUSEPORT is no longer implemented
* SO_SNDTIMEO is implemented
lwip/src/netif/ppp/mppe.c: In function `mppe_rekey':
lwip/src/netif/ppp/mppe.c:74:15: error: declaration of`sha1' shadows a global declaration [-Werror=shadow]
lwip/src/include/netif/ppp/polarssl/sha1.h:88:6: error: shadowed declaration is here [-Werror=shadow]
Older compilers don't like variables with the same name as
global functions. md5.h contains a function md5(), rename
md5 variable in magic.c to md5_ctx.
Older compilers don't like variables with the same name as
global functions. md5.h contains a function md5(), rename
md5 variable in magic.c to md5_ctx.
lwip/src/netif/ppp/magic.c: In function `magic_churnrand':
lwip/src/netif/ppp/magic.c:105:15: error: declaration of `md5' shadows a global declaration [-Werror=shadow]
lwip/src/include/netif/ppp/polarssl/md5.h:88:6: error: shadowed declaration is here [-Werror=shadow]
lwip/src/netif/ppp/magic.c: In function `magic_random_bytes':
lwip/src/netif/ppp/magic.c:165:15: error: declaration of `md5' shadows a global declaration [-Werror=shadow]
lwip/src/include/netif/ppp/polarssl/md5.h:88:6: error: shadowed declaration is here [-Werror=shadow]
Older compilers (GCC 4.6) don't like variables with the same name as
global functions:
lwip/src/netif/ppp/lcp.c: In function 'lcp_received_echo_reply':
lwip/src/netif/ppp/lcp.c:2685:11: error: declaration of 'magic' shadows a global declaration [-Werror=shadow]
lwip/src/include/netif/ppp/magic.h:101:7: error: shadowed declaration is here [-Werror=shadow]
magic.h contains a function named magic(), so rename the variable.
Existing functions are based on IP address, but the address is used
only to look up which netif to act on. The netif-based core code is
extracted to new exported functions.
If you have a netif handle, this makes it easier to join/leave
groups, without the need to convert to IP address first only for the
mld6 code to convert back to netif.
Existing functions are based on IP address, but the address is used
only to look up which netif to act on. The netif-based core code is
extracted to new exported functions.
If you have a netif handle, this makes it easier to join/leave
groups, without the need to convert to IP address first only for the
IGMP code to convert back to netif.
It used to be this way because the original implementation was close to
the hardware and used a free running 16 bits timer so it was necessary.
Currently what it is only doing is removing potential entropy we might
get from upper bits, that's a bad idea.
Jiffies isn't really a humanly readable value and it means the default
PPP_MAXIDLEFLAG period depends on the platform "jiffies" frequency,
which isn't nice.
Change PPP_MAXIDLEFLAG to use ms instead of jiffies, the current
PPP_MAXIDLEFLAG default (100 ms), looks like a sane value and is
left unchanged.
gw netif field for point to point interfaces is the peer IP address.
Check if the destination is equals to the gw field of point to point
interfaces (broadcast flag is not set) when routing an IP packet.
LWIP_ERROR macro exited the function early with the return code
indicating a SUCCESS. Fix the error codes. Return the specified
error code for cases when the pbuf is too short.
This commit hooks up the TCP cachehit stat to the PCB locality feature
so that when a PCB is moved to the head of the list and a segment comes
in, we consider this a cache hit
This also matches the usage of the cachehit stat in UDP
Adds sendmsg implementation for TCP and UDP sockets. Control messages
are not supported at this point, but could be added in the future
https://savannah.nongnu.org/bugs/?44805
Change-Id: Iddb287fd4b693f7563f8c923f76785cdde782d2f
The overall lwIP design on data flows (netif,udp,tcp) is to use a user
defined callback to get data from stack and a static function to send
data to stack, which makes perfect sense. The SIO port was an exception,
the PPP stack never really used the SIO port by only using the
sio_send() function (and the ignominious sio_read_abort() function a
while back).
The way the SIO port is currently designed adds a tight coupling between
the lwIP port and the user code if the user need to do specific user
code if the current uart used is the PPPoS uart, which is not nice,
especially because all the lwIP stack is quite clean at this subject.
While we are at stabilizing the PPP API, change this behavior before
it's too late by replacing the static sio_write() calls to a user
defined callback.
Added the random seed already used without PPP_MD5_RANDM
as an entropy source when PPP_MD5_RANDM feature is enabled.
(And a little bit of code cleaning for both)
If LWIP_RAND() is available, it is used instead of libc srand()/rand()
if PPP_MD5_RANDM is disabled and it is added as a source of randomness
if PPP_MD5_RANDM is enabled.
A disabled PPP_MD5_RANDM should not be used when challenge are used, but
anyway, improved magic_randomize() so magic_randomseed is not equals to
sys_jiffies() which is pretty useless because that's fully predicable.
The only API difference with and without the PPP_MD5_RANDM support is the
availability of the random_bytes() function. Added a random_bytes()
function on top of magic() when PPP_MD5_RANDM support is not enabled,
thus allowing builds for both cases.
PPP_MD5_RANDM is still enabled by default (it was mandatory) if a protocol
using encryption is enabled, such as CHAP, EAP, or L2TP auth support.
There is no point of calling magic_randomize() for each pppos_input()
call, making magic_randomize() potentially called for each serial input
byte which is quite a bad idea since magic_randomize() is quite
intensive in processing time (MD5 computation) compared to HDLC frame
parsing. There is no entropy added when being called for each input byte
rather than for each valid input packet because byte input is a
monotonic event at the packet level. Well, if packet arrival time is a
valid entropy source even so, which I doubt a lot, but we don't really
have anything else and we really need random for PPP authentication
layers.
Drop input/output packets if we couldn't find a decompressor/compressor,
it can't really happen because we only negotiate what we are able to
compress/decompress, but for the sake of code consistency it makes much
more sense to do so.
We used to modify in place the packet payload during encryption, it works
well for UDP and ICMP but TCP stack requires that we don't change the
packet payload, therefore we now copy the whole packet before encryption.
This commit adds support to send and receive multicast on the loopback
netif by enabling IGMP via NETIF_FLAG_IGMP
This commit also introduces an LwIP configuration option,
LWIP_LOOPIF_MCAST, to control the behavior and it defaults to off
This commit address two issues with sockaddr struct implementations for
IPv6:
1) struct sockaddr_in6 should have 32-bit unsigned field sin6_scope_id
as specified in Section 3.4 of RFC 3493 (Basic Socket Interface
Extensions for IPv6)
2) struct sockaddr is not extended in IPv6 to contain space for
struct sockaddr_in6. Applications should be using struct
sockaddr_storage when needing generic storage. This removes the
extra bytes added when LWIP_IPV6 is defined
the netif_add_ip6_address function was declared err_t in
src/include/lwip/netif.h, but defined as s8_t (the default value of
err_t) in its implementation in src/core/netif.c.
this causes "conflicting types for 'netif_add_ip6_address'" errors if
err_t is defined differently in cc.h (as for example recommended in
[1]).
as it only returns error constants, it is changed to use err_t
throughout.
[1] http://lwip.wikia.com/wiki/Porting_For_Bare_Metal
Writes to offsets pointing to the start of a pbuf in the chain
did nothing and just returned ERR_OK.
Added unit tests to verify the fix, and also
that pbuf_get_at()/pbuf_put_at() handles this case.
When LWIP_HAVE_LOOPIF is enabled, a separate loopback interface is added
as a netif. A netif need to have its link state set to up to be able to be
selected as a route in ip4_route or ip6_route.
The regression appears to be when bug #43904 (ip_route() and ip6_route()
must detect linkup status) was fixed.
Furthermore, there is no point of having the loopif down by default.
This commit fixes a bug in netbuf_destport() where LWIP_NETBUF_RECVINFO is
enabled, but not LWIP_CHECKSUM_ON_COPY is enabled
The flags field is only available when LWIP_CHECKSUM_ON_COPY is enabled. In
this mode, the toport_chksum is dual functioning as storage for port and
checksum
When a client sends an ICMP echo request with ID 0, sequence 0 and
either no data or any amount of 0x00 bytes as data, the checksum in the
reply is wrong (off-by-one).
Expected checksum is 0xffff in that case, observed is 0x0000.
We used a static 4 instead of MEM_ALIGNMENT earlier, however it broke
things for MEM_ALIGNMENT 1 or 2, fixed using a LWIP_MIN(MEM_ALIGNMENT,
4) statement.
When PPP is used over a link which does not guarantee packet ordering,
we might get late MPPE packets. This is a problem because MPPE must be
kept synchronized and the current implementation does not drop them and
rekey 4095 times instead of 0, which is wrong.
In order to prevent rekeying about a whole count space times (~ 4095
times), drop packets which are not within the forward 4096/2 window and
increase sanity error counter.
Check tot_len for ZLB instead of len, it might happens we are just
between 2 pbuf, although almost impossible.
Check buffer is at least 2 byte long before checking address & flags
header.
Most of them were wrong actually. We have to use unsigned int because
C90 only allows int types for bitfields, so we are stuck to 32-bit
bitfields in most cases.
PBUF_LINK_ENCAPSULATION_HLEN support was introduced by 6ef7563f and
missed the fact that header size calculation/reservation using
computation like PBUF_LINK_HLEN + PBUF_IP_HLEN + ... are used all over
the source code. Hopefully fixed all of them.
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.
Removed mutiple copies of keys by pre-setting MPPE keys during MSCHAP
negotiation.
Improved MPPE init so we don't need to pass a buffer formatted in a
special way to MPPE, this is necessary for pppd to talk to the kernel,
we don't need that here.
MSCHAP was written the old-way, with all functions declared non static in
header, independent of their local or global scope status. Same for local
constants. Reworked in a more mordern way.
We are going to need ppp_pcb* in MSCHAP and MSCHAPv2 for MPPE for
int mppe_keys_set, u_char mppe_send_key and u_char mppe_recv_key
which are currently global variable which must be moved to ppp_pcb.
Removing a bit of redundancy and previous artefact of a generic kernel
interface. Exporting mppe_init() instead of mppe_comp_init() plus
mppe_decomp_init().
We are going to use statically allocated struct ppp_mppe_state through PPP PCB,
removed now useless mppe_alloc() and mppe_free().
Merged mppe_alloc() key copy to mppe_init().
ccp_test() is not only used to test kernel support, but also to set MPPE keys,
we will change that further, but for now, re-add the necessary ccp_test()
Our PPP stack deals with packet without address and control byte nor 2-byte
protocol field, improved mppe_compress() so we don't have to worry about
them.
Our PPP stack deals with packet without address and control byte nor 2-byte
protocol field, improved mppe_compress() so we don't have to worry about
them.
If LWIP_IPV4 is true but PPP_IPV4_SUPPORT is false, we need
a dummy ppp_netif_output_ip4() callback because we don't have
a netif_null_output_ip4() by default like we have for IPv6 with
netif_null_output_ip6().
Removed ppp_singlebuf() in pppol2tp_input(), chained pbuf are perfectly
acceptable for IP data and we are currently supporting them perfectly
for PPPoS. The PPP stack itself (LCP, IPCP et al.) does not support
chained pbuf and is already calling ppp_singlebuf() just before passing
packet to the protocol handler.
Added ppp_singlebuf() in pppol2tp_dispatch_control_packet() because we
do not support chained pbuf in L2TP control packet.
mppe_decompress() now takes a pointer to a pbuf pointer and re-use the
passed buffer for MPPE "decompression". Removed sub protocol handling
which can be shared among all decompressors in ppp.c
Removed ppp_singlebuf() in pppoe_data_input(), chained pbuf are
perfectly acceptable for IP data and we are currently supporting them
perfectly for PPPoS. The PPP stack itself (LCP, IPCP et al.) does not
support chained pbuf and is already calling ppp_singlebuf() just before
passing packet to the protocol handler.
Our PPP stack deals with packet without address and control byte nor 2-byte
protocol field, improved mppe_decompress() so we don't have to worry about
them.
In PPP, we previously know if we are dealing with a IPv4 or a IPv6 packet,
we don't need to use the ip_input() dispatch function, removing a useless
if and reducing call stack by one.