How to Choose Network Interface to Send Packets Over

I am relatively new to RIOT and I hope someone can provide some expertise here; I am exploring the gnrc networking stack in the pursuit of a functioning border router.

This question is centered around “examples/posix_sockets.” I am using ATMEL SAMR21 chips.

The posix_example works as expected, without modification, provided I am communicating between two SAMR21 nodes using the 802.15.4 radio (SAMR21 depends on at86rf2xx).

BUT, I am also working towards a functioning border router by adding an ethernet interface to the SAM.

I have explored the edge case (no pun intended) of the posix_sockets example where I use ONLY an ethernet adapter (i.e., replacing the dependency on at86rf2xx with ksz8851snl, the ethernet driver). It works as expected: I am able to send UDP data from the SAM over the ethernet to my computer’s UDP server (and back). In this edge case, the ethernet is the only interface the SAM reports, also expected.

But, when I combine these two cases – so that I have both at86rf2xx and ksz8851snl interfaces enabled – it seems that UDP data is only transmitted via the radio! Other SAMs can receive the UDP packets, but the computer server stops receiving them. No IP addresses were changed; only the number of interfaces available to the SAM (i.e. GNRC_NETIF_NUMOF := 2).

This leads me to a slightly deeper question – how does RIOT decide what physical interface to attempt to communicate over when I use network send calls such as conn_udp_sendto?

As an associated question – is it the intention of the gnrc_border_router example to automatically bridge interfaces (such as ethernet & 802.15.4)? As far as I can tell it really only initializes interfaces but does not provide any actual routing between them.

Thank you,

Mark Solters

Hey Mark!

This leads me to a slightly deeper question -- how does RIOT decide what physical interface to attempt to communicate over when I use network send calls such as conn_udp_sendto?

Selecting the proper interface for sending, is task of the network layer and is implemented according to the procedures explained in the according RFCs [1][2] in GNRC. This means that a node will first check if the destination prefix is "on-link" (if applicable) and use the according interface. If not, it will look up the destination in the FIB (Forwarding Information Base) if available (e.g., if a routing protocol is available or someone else filled the FIB manually) for the next hop's IP address. You can check the content of the FIB using the `fibroute` shell command. Finally, the neighbor cache (check with `ncache` shell command) is checked or a neighbor solicitation may be performed.

Hence, if your IPv6 prefixes are configured correctly (e.g. as described in the gnrc_border_router example's README), the appropriate interface should be chosen.

As an associated question -- is it the intention of the gnrc_border_router example to automatically bridge interfaces (such as ethernet & 802.15.4)? As far as I can tell it really only initializes interfaces but does not provide any actual routing between them.

The border router is (as the name suggests ;-)) a router, not a bridge. Forwarding packets via the correct interface is done according to the rules stated above.

HTH, Oleg

[1] RFC 4861 - Neighbor Discovery for IP version 6 (IPv6) [2] RFC 6775 - Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)