Ipolite is used by netflood and route-discovery modules among others. If a route request is yet to be re-broadcasted and a local route discovery is started (interval == 0), the previous queuebuf used is freed but ctimer and queuebuf pointer is left unchanged. This causes corrupt route requests to be sent, invalid routing tables to be formed, memcmp() on NULL pointer on receive, and other undefined behavior.
Signed-off-by: Oskar Nordquist <oskar.nordquist@crlsweden.com>
An off-by-one error in resolv_found() could make an strncat() call
overflow by the terminating null byte.
When building with Clang the following warning was shown:
../../../core/net/ip/resolv.c:1458:17: warning: the value of the
size argument in 'strncat' is too large, might lead to a
buffer overflow [-Wstrncat-size]
sizeof(resolv_hostname) - strlen(resolv_hostname));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../core/net/ip/resolv.c:1458:17: note: change the argument to
be the free space in the destination buffer minus the
terminating null byte
sizeof(resolv_hostname) - strlen(resolv_hostname));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(resolv_hostname) - strlen(resolv_hostname) - 1
Signed-off-by: Joakim Gebart <joakim.gebart@eistec.se>
to allow for creating and securing frames in advance; Create and secure frames in advance when sending bursts; Do neither recreate nor resecure frames that come from phase
The next-hop address did not get updated in the routing table
in case an entry for the destination already existed.
This patch resolves the issue by removing the entry and
having it re-created from scratch.
The issue causes a routing error triggering reconstruction of
the DODAG through version increase.
In case of somewhat frequent downward traffic in not (yet) stabilized DODAG
a vicious circle is formed: unstable topology means churn, downward
routing under churn causes reconstruction of DODAG. In this situation
the network does not have chance to stabilize.
We encountered a constant churn caused by this bug
in a network of 50 nodes and a periodic traffic (a packet every 5
seconds) generated at the root.
More info and a PCAP demonstrating the issue can be found here:
https://github.com/contiki-os/contiki/issues/496
type process_data_t. This was an artifact when the choice was
made to use the void * type for the data parameter in processes.
Changed parameter 'void * data' of process_post_synch to
process_data_t for consistency.
Checked all the uses of process_start() in contiki and fixed casts
of the data parameter.
