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 problem came from the fact that there two opposite macro (UIP_CONF_ROUTER) that could not activate the code responsible to send the PIO option in NDP.
In Neighbor Discovery Protocol, when IPv6 host adds a prefix (coming from PIO) but it is always failing whatever if is successfully add in prefix table. The reason comes from the fact that the function uip_ds6_prefix_add in host version always return NULL. This is opposite of the specification of the router version.
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.
Currently the SPI driver in core/ sets `SPI_FLUSH()` to be a single read
of the spi RX buffer. This is fine for many microcontrollers, but newer
platforms like the CC2538 have a multi-byte FIFO for the RX buffer. In
that case, a single read is not guaranteed to flush the RX. This commit
allows `SPI_FLUSH()` to be platform dependent if needed, but doesn't
change for platforms where it works.
would create a header with the current packet information.
This allows sicslowpan to calculate the max payload size without
consuming a sequence number or clearing/restoring the packet buffer.
TTL (which has a rather low default of 15), MAC level retransmissions,
overall number of retransmissions, and the header bits dedicated to these
were all fixed in the collect.h and collect.c, without a simple way to
override them.
Extracted these as COLLECT_CONF_ parameters, keeping defaults as they were
before.
Signed-off-by: Csaba Kiraly <kiraly@disi.unitn.it>
The leds_set() function is added on top of leds_arch_set() in order to have a
means of displaying a pattern on a set of LEDs, while keeping the ENERGEST
information up to date, which would be missing with a direct call to
leds_arch_set().
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The leds API did not work in some cases. E.g. with the following sequence:
leds_off(LEDS_ALL);
leds_toggle(LEDS_GREEN);
leds_off(LEDS_ALL);
the green LED was remaining on after the last call.
This was caused by the toggle feature made synonymous with the invert feature,
although it is unrelated. leds_toggle() is indeed supposed to toggle an LED,
while leds_invert() is supposed to change the active level of an LED. However,
all users of leds_invert() actually meant leds_toggle(), and the invert feature
does not make sense in this module because it is not handy due to successive
calls to leds_invert() changing the intended behavior, and hardware active
levels should be managed in leds_arch_set() (e.g. by XORing the passed value
with a hardware-specific constant before setting the output levels of the pins).
Consequently, this change:
- removes the leds_invert() function,
- makes leds_toggle() behave as expected relatively to leds_off() / leds_on(),
- sanitizes the code in the leds module.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
According to IEEE 802.15.4e (§6.4.3.9), in order to detect duplicate received
MAC-layer frames, only the most recently received frame's sequence number needs
to be stored for each unique device address. Doing so limits the possible false
duplicate packet detections to a single sequence number. This also allows to
keep the last sequence number of more device addresses for the same value of
MAX_SEQNOS.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The code detecting duplicate packets in the RDC layer had been copied into most
RDC implementations. Factor it out into a new mac-sequence module in order to
have a single instance of this code.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
According to IEEE 802.15.4 (§5.1.6.1, §6.4.2), the MAC sequence numbers should
be initialized to random values. This was already the case in
framer-802154.c:create(), but not in csma.c:send_packet(), sometimes causing
false detections of duplicate MAC-layer packets in other devices when a device
was restarted too quickly. This patch decreases the probability of such an
event.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
* Mesh: this is the normal case. Nodes route data on behalf of others and the node can be reached via a DAO route.
* Leaf: the node does not route data on behalf of others, but others can route data to the node (it has a RPL DAO route).
* Feather: this is a new type of node. A feather node routes data on behalf of others, but does not install DAO routes in the network. Feather nodes allow having a larger number of nodes than the RPL network can sustain in terms of routing tables.
This commit introduces the RPL node types and the feather mode, but does not add support for the leaf node type.
* Added a DAO lifetime timer that sends out a new DAO after half the lifetime of the DAO. This allows implementing DAO route soft state that avoids routing tables in the network keeping stale routes for ever.
* Added ways to schedule a new DAO transmission as well as cancelling an active DAO transmit timer, which makes it possible to do nodes that don't send DAOs.
The CCA-threshold now defaults to -46 which give better simulation
results and typically also better experimental results.
This adjustment is also needed due to commit 0a13f99 in mspsim. As
promised in https://github.com/mspsim/mspsim/pull/18 it broke the
regression tests.
Fixed a wrapping problem in the ETX EWMA calculation.
Corrected the multiplier of the link metric, and simplified the configuration
so that the user does not need to specify the multiplier.
interaction with the behavior of the rdc layer. If the first packet of a
fragment transmission was lost, the remaining packets would get dropped
on reception. Moreover, the reception code contained a bug that
sometimes would cause fragments to be misidentified as fragments. Taken
together, these problems would result in a pathelogical network
breakdown if too many fragmented packets would occur simultaneously.
This patch removes a defunct EEPROM implementation from the native
platform and provides a new EEPROM implementation for the native cpu.
The previous implementation appears to be vestigal.
This is useful for testing code which uses the EEPROM without running
the code on the actual hardware.
By default the code will create a new temporary file as the EEPROM
backing, reinitializing each time. If you would like to preserve the
EEPROM contents or specify a specific EEPROM file to use, you can set the
`CONTIKI_EEPROM` environment variable to the name of the EEPROM file you
wish to use instead. If it already exists, its contents will be used.
If it does not already exist, it will be created and initialized by
filling it with `0xFF`---just like a real EEPROM.
A new example is also included, which was used to verify the correctness
of the implementation. It can easily be used to verify the EEPROM
implementations of other targets.
This is a temporary fix for #183, so that things can
build cleanly until the issue is fixed properly.
If RIMESTATS_CONF_ENABLED is 0, rimestats.foo will always
read as 0, since RIMESTATS_ADD(foo) doesn't do anything
Unfortunately, some platforms don't properly drop unreferenced functions,
so on these broken platforms we can save a significant amount
of space by skipping the definition of the convenience functions.
This commit moves the Settings Manager from the AVR codebase
into the Contiki core library. Any platform that implements
the Contiki EEPROM API can now use the Settings Manager's
key-value store for storing their persistent configuration info.
The Settings Manager is a EEPROM-based key-value store. Keys
are 16-bit integers and values may be up to 16,383 bytes long.
It is intended to be used to store configuration-related information,
like network settings, radio channels, etc.
* Robust data format which requires no initialization.
* Supports multiple values with the same key.
* Data can be appended without erasing EEPROM.
* Max size of settings data can be easily increased in the future,
as long as it doesn't overlap with application data.
The format was inspired by the [OLPC manufacturing data format][].
Since the beginning of EEPROM often contains application-specific
information, the best place to store settings is at the end of EEPROM
(the "top"). Because we are starting at the end of EEPROM, it makes
sense to grow the list of key-value pairs downward, toward the start of
EEPROM.
Each key-value pair is stored in memory in the following format:
Order | Size | Name | Description
--------:|---------:|--------------|-------------------------------
0 | 2 | `key` | 16-bit key
-2 | 1 | `size_check` | One's-complement of next byte
-3 | 1 or 2 | `size` | The size of `value`, in bytes
-4 or -5 | variable | `value` | Value associated with `key`
The end of the key-value pairs is denoted by the first invalid entry.
An invalid entry has any of the following attributes:
* The `size_check` byte doesn't match the one's compliment of the
`size` byte (or `size_low` byte).
* The key has a value of 0x0000.
[OLPC manufacturing data format]: http://wiki.laptop.org/go/Manufacturing_data
* add a few rimestats to keep track of sent and received acks
* made a number of configuration options possible to override (ack timing)
* added the logic for sending 802.15.4 link layer ack packets, despite not being able to guarentee the 802.15.4 MAC timing
* increased the number of sequence numbers to keep track of for duplicate filtering
The contiki-default-conf.h file is intended as a safe fallback for
a number of configuration options in Contiki, to avoid putting too
much in the individual contiki-conf.h files.
Combined recent changes from darconeous...
- Refactor to decrease minimum code footprint.
- Added `RESOLV_CONF_SUPPORTS_RECORD_EXPIRATION`.
...with a few additional changes to reduce code size.
"Bridge mode" allows devices to more easily send 802.15.4 packets as if
they were a different device. It also turns off any packet filtering
that may be implemented at layer 2. It works by allowing
`PACKETBUF_ADDR_SENDER` to be set earlier in the stack.
This is useful for implementing 6LoWPAN-ethernet bridges.
Enabled via setting `NETSTACK_CONF_BRIDGE_MODE` to 1. Disabled by
default.
This patch updates the DNS resolver to support IPv6 and introduces an
improved API for looking up DNS entries. This patch also adds optional
support for mDNS lookups and responses to the DNS resolver.
Here is a quick summary of the changes:
* Added support for IPv6 lookups.
* DNS queries now honor record expiration.
* Added support for mDNS, compatible with "Bonjour".
* Implemented a new lookup api, `resolv_lookup2()`, which provides
more information about the state of the record(error, expired,
looking-up, etc.).
About mDNS/Bonjour Support
--------------------------
This patch adds basic support for mDNS/Bonjour, which allows you to
refer to the name of a device instead of its IP address. This is
incredibly convenient for IPv6 addresses because they tend to be very
long and difficult to remember. It is especially important for
link-local IPv6 addresses, since not all programs support the '%'
notation for indicating a network interface (required on systems with
more than one network interface to disambiguate).
In other words, instead of typing in this:
* `http://[fe80::58dc:d7ed:a644:628f%en1]/`
You can type this instead:
* `http://contiki.local/`
Huge improvement, no?
The convenience extends beyond that: this mechanism can be used for
nodes to talk to each other based on their human-readable names instead
of their IPv6 addresses. So instead of a switch on
`aaaa::58dc:d7ed:a644:628f` triggering an actuator on
`aaaa::ed26:19c1:4bd2:f95b`, `light-switch.local` can trigger the
actuator on `living-room-lights.local`.
What you need to do to be able to look up `.local` names on your
workstation depends on a few factors:
* Your machine needs to be able to send and receive multicast packets
to and from the LoWPAN. You can do this easily with the Jackdaw
firmware on an RZUSBStick. If you have a border router, you will need
it to bridge the mDNS multicast packets across the border.
* If you are using a Mac, you win. All Apple devices support mDNS
lookups.
* If you are using Windows, you can install Apple's Bonjour for Windows
package. (This may be already installed on your machine if you have
installed iTunes) After you install this you can easily do `.local`
lookups.
* If you are using a Unix machine, you can install Avahi.
The default hostname is set to `contiki.local.`. You can change the
hostname programmatically by calling `resolv_set_hostname()`. You can
change the default hostname by changing `CONTIKI_CONF_DEFAULT_HOSTNAME`.
You may disable mDNS support by setting `RESOLV_CONF_SUPPORTS_MDNS` to
`0`.
---------------------------------
core/net/resolv: `resolv_lookup2()` -> `resolv_lookup()`
Note that this patch should fix several `resolv_lookup()` bugs
that already existed. There were many cases where `resolv_lookup()`
was being called and the IP address ignored, but later code
assumed that the IP address had been fetched... ANYWAY, those
should be fixed now.
---------------------------------
examples/udp-ipv6: Updated client to use MDNS to lookup the server.
Also updated the Cooja regression test simulation.
Modern compilers (especially GCC) ignore the register keyword anyway and the latest cc65 snapshot generates actually larger code with the register keyword at the locations in question.
Either I found and fixed a severe bug in PSOCK_READTO() or I misunderstood something completely. To me PSOCK_READTO() is supposed to return if either the supplied character was read or if the user supplied buffer is exhausted - sor far so good.
However if the latter occurs up to now PSOCK_READTO() was continuing to process characters already read from the network (aka present in the uIP buffer) in order to check if the supplied character was found there and adjust the return value accordingly. But this means that the character processed this way were lost forever for the caller as the next call to PSOCK_READTO() would continue to read past the characters processed this way.
Therefore I removed that character processing altogether. So now if the user supplied buffer is exhausted before the supplied character is found the next call to PSOCK_READTO() starts exactly where previous call left off.
While it may very well be beneficial to have explict uiplib_ip4addrconv() and uiplib_ip6addrconv() available for IPv6 builds I'm having a hard time to see the point in uiplib_ip6addrconv() for IPv4 builds.
Unrelated to the above the dispatching of uiplib_ipaddrconv() to either uiplib_ip4addrconv() or uiplib_ip6addrconv() can be accomplished by the C preprocessor only thus avoiding the size/speed overhead of an additional callframe.
Setting UIP_CONF_IPV6 to zero from the make build command line is
something that seems like it should ensure that IPv6 is disabled, but in
fact it actually *enables* IPv6. This seems counter intuitive, so this
patch changes the behavior of the makefiles to handle this case
properly.
There is a bug in the current route purge routine which would
result in a route's lifetime getting decremented more than once
during the same pass. This commit fixes it
The bug is documented here:
http://thread.gmane.org/gmane.os.contiki.devel/16209
NETSTACK_ENCRYPT and NETSTACK_DECRYPT are defined. Those are intended
to be called as functions NETSTACK_ENCRYPT() and NETSTACK_DECRYPT() to
encrypt and decrypt the packetbuf, respectively. If needed, an
initialization function by the name NETSTACK_ENCRYPTION_INIT() can
also be defined.
