ea449f3f9e
When reworking the reception of IPv6 packets I reset a previously set
`ipv6` snip as follows when the IPv6 extension handler returns a
packet (see first hunk of this commit):
```C
ipv6 = pkt->next->next
```
With `gnrc_ipv6_ext` this makes *somewhat* sense, `pkt->next` was
previously equal to `ipv6` and after the function call `pkt->next`
is the marked extension header, while `pkt->next->next` is the IPv6
header. However, since `ipv6` is already write-protected i.e.
`ipv6->users == 1` (see ll. 665-675), any additional call of
`gnrc_pktbuf_start_write()` [won't][start-write-doc] duplicate the
packet. In fact, the only `gnrc_pktbuf_start_write()` in
`gnrc_ipv6_ext` is used to send the *result* to the subscribers of that
extension header type, leaving the original packet unchanged for the
caller. As such `ipv6` remains the pointer to the IPv6 header whether
we set it in the line above or not. So we actually don't need that
line.
However, the extension header handling also returns a packet when
`gnrc_ipv6_ext` is not compiled in. In that case it is just a dummy
define that returns the packet you give provide it which means that
this still holds true: `pkt->next == ipv6`.
So setting `ipv6` in this case is actually harmful, as `ipv6` now
points to the NETIF header [following the IPv6 header][pkt-structure]
in the packet and this causes the `user` counter of that NETIF header
`hdr` to be decremented if `hdr->users > 1` in the write-protection I
removed in hunk 2 of this commit:
```C
/* pkt might not be writable yet, if header was given above */
ipv6 = gnrc_pktbuf_start_write(ipv6);
if (ipv6 == NULL) {
DEBUG("ipv6: unable to get write access to packet: dropping it\n");
gnrc_pktbuf_release(pkt);
return;
}
```
But as we already established, `ipv6->users` is already 1, so we don't
actually need the write protection here either.
Since the packet stays unchanged after the `ipv6` snip, we also don't
need to re-search for `netif_hdr` after the other two lines are
removed.
[start-write-doc]: https://doc.riot-os.org/group__net__gnrc__pktbuf.html#ga640418467294ae3d408c109ab27bd617
[pkt-structure]: https://doc.riot-os.org/group__net__gnrc__pkt.html#ga278e783e56a5ee6f1bd7b81077ed82a7
ZZZZZZ
ZZZZZZZZZZZZ
ZZZZZZZZZZZZZZZZ
ZZZZZZZ ZZZZZZ
ZZZZZZ ZZZZZ
ZZZZZ ZZZZ
ZZZZ ZZZZZ
ZZZZ ZZZZ
ZZZZ ZZZZZ
ZZZZ ZZZZZZ
ZZZZ ZZZZZZZZ 777 7777 7777777777
ZZ ZZZZ ZZZZZZZZ 777 77777777 77777777777
ZZZZZZZ ZZZZ ZZZZZZZ 777 7777 7777 777
ZZZZZZZZZ ZZZZ Z 777 777 777 777
ZZZZZZ ZZZZ 777 777 777 777
ZZZZZ ZZZZ 777 777 777 777
ZZZZZ ZZZZZ ZZZZ 777 777 777 777
ZZZZ ZZZZZ ZZZZZ 777 777 777 777
ZZZZ ZZZZZ ZZZZZ 777 777 777 777
ZZZZ ZZZZ ZZZZZ 777 777 777 777
ZZZZZ ZZZZZ ZZZZZ 777 777 777 777
ZZZZZZ ZZZZZZ ZZZZZ 777 7777777777 777
ZZZZZZZZZZZZZZZ ZZZZ 777 77777777 777
ZZZZZZZZZZZ Z
ZZZZZ
The friendly Operating System for IoT!
RIOT is a real-time multi-threading operating system that supports a range of devices that are typically found in the Internet of Things (IoT): 8-bit, 16-bit and 32-bit microcontrollers.
RIOT is based on the following design principles: energy-efficiency, real-time capabilities, small memory footprint, modularity, and uniform API access, independent of the underlying hardware (this API offers partial POSIX compliance).
RIOT is developed by an international open source community which is independent of specific vendors (e.g. similarly to the Linux community). RIOT is licensed with LGPLv2.1, a copyleft license which fosters indirect business models around the free open-source software platform provided by RIOT, e.g. it is possible to link closed-source code with the LGPL code.
FEATURES
RIOT is based on a microkernel architecture, and provides features including, but not limited to:
- a preemptive, tickless scheduler with priorities
- flexible memory management
- high resolution, long-term timers
- support 100+ boards based on AVR, MSP430, ESP8266, ESP32, MIPS, RISC-V, ARM7 and ARM Cortex-M
- the native port allows to run RIOT as-is on Linux, BSD, and MacOS. Multiple instances of RIOT running on a single machine can also be interconnected via a simple virtual Ethernet bridge
- IPv6
- 6LoWPAN (RFC4944, RFC6282, and RFC6775)
- UDP
- RPL (storing mode, P2P mode)
- CoAP
- CCN-Lite
- Sigfox
- LoRaWAN
GETTING STARTED
- You want to start the RIOT? Just follow our quickstart guide or try this tutorial. For specific toolchain installation, follow instructions in the getting started page.
- The RIOT API itself can be built from the code using doxygen. The latest version of the documentation is uploaded daily to riot-os.org/api.
USING THE NATIVE PORT WITH NETWORKING
If you compile RIOT for the native cpu and include the netdev_tap module,
you can specify a network interface like this: PORT=tap0 make term
SETTING UP A TAP NETWORK
There is a shell script in RIOT/dist/tools/tapsetup called tapsetup which
you can use to create a network of tap interfaces.
USAGE
To create a bridge and two (or count at your option) tap interfaces:
./dist/tools/tapsetup/tapsetup [-c [<count>]]
CONTRIBUTE
To contribute something to RIOT, please refer to our contributing document.
MAILING LISTS
- RIOT OS kernel developers list
- devel@riot-os.org (https://lists.riot-os.org/mailman/listinfo/devel)
- RIOT OS users list
- users@riot-os.org (https://lists.riot-os.org/mailman/listinfo/users)
- RIOT commits
- commits@riot-os.org (https://lists.riot-os.org/mailman/listinfo/commits)
- Github notifications
- notifications@riot-os.org (https://lists.riot-os.org/mailman/listinfo/notifications)
LICENSE
- Most of the code developed by the RIOT community is licensed under the GNU Lesser General Public License (LGPL) version 2.1 as published by the Free Software Foundation.
- Some external sources, especially files developed by SICS are published under a separate license.
All code files contain licensing information.
For more information, see the RIOT website: