tests/gnrc_tcp_*: #2 not working on 6Lo-based boards

[PeterKietzmann]

Description

In #10947 and #10950 we found and fixed an issue which let a board hard fault running the above mentioned apps. Now that this is fixed it turns out the code is executed but the protocol doesn't work. Looking at a sniffer, all I see is Router Solicitations, nothing more. Digging a bit deeper it seems that TCP packets are dropped within the network stack:

• The packet is dropped in the NIB here because netif is NULL
• netif is NULL because it was initialized here and not set again baceause the pkt->type is not GNRC_NETTYPE_NETIF, compare this statement

I think this is missing somewhere:
gnrc_pktsnip_t *netif = gnrc_netif_hdr_build(NULL, 0, NULL, 0);

Steps to reproduce the issue

• Optionally enable debug messages in gnrc_ipv6.c and nib.c
• Optionally use a 802.15.4 sniffer on channel 20 (RIOT defualt channel)

server
TCP_LOCAL_ADDR=<ll_addr_server> BOARD=samr21-xpro make flash term SERIAL=XXX PORT=/dev/ttyXXX

client
TCP_TARGET_ADDR=<ll_addr_server> BOARD=samr21-xpro make flash term SERIAL=XXX PORT=/dev/ttyXXX

Expected results

TCP connection should be established.

Actual results

No packets are sent -> no connection establishment. Instead, with above mentioned and enabled debug messages, would should get information from the NIB module that host is unreachable.

Versions

Operating System Environment
-----------------------------
       Operating System: "Ubuntu" "18.04.1 LTS (Bionic Beaver)"
                 Kernel: Linux 4.15.0-45-generic x86_64 x86_64

Installed compiler toolchains
-----------------------------
             native gcc: gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
      arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
                avr-gcc: missing
       mips-mti-elf-gcc: missing
             msp430-gcc: msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)
   riscv-none-embed-gcc: missing
   xtensa-esp32-elf-gcc: missing
   xtensa-lx106-elf-gcc: missing
                  clang: missing

Installed compiler libs
-----------------------
   arm-none-eabi-newlib: "3.0.0"
    mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
xtensa-esp32-elf-newlib: missing
xtensa-lx106-elf-newlib: missing
               avr-libc: missing (missing)

Installed development tools
---------------------------
                  cmake: cmake version 3.10.2
               cppcheck: missing
                doxygen: 1.8.13
                 flake8: 3.6.0 (mccabe: 0.6.1, pycodestyle: 2.4.0, pyflakes: 2.0.0) CPython 3.6.7 on Linux
                    git: git version 2.17.1
                   make: GNU Make 4.1
                openocd: Open On-Chip Debugger 0.10.0
                 python: Python 2.7.15rc1
                python2: Python 2.7.15rc1
                python3: Python 3.6.7
             coccinelle: missing

[miri64]

I had a quick look at the stack and the gnrc_netif_hdr_build() is there. Here

RIOT/sys/net/gnrc/transport_layer/tcp/gnrc_tcp_pkt.c

Lines 114 to 135 in 3e5658d

	if (ipv6_addr_is_link_local(&ip6_hdr->src)) {
	/* Search for netif header in received packet */
	gnrc_pktsnip_t *net_snp;
	LL_SEARCH_SCALAR(in_pkt, net_snp, type, GNRC_NETTYPE_NETIF);
	gnrc_netif_hdr_t *net_hdr = (gnrc_netif_hdr_t *)net_snp->data;
	/* Allocate new header and set interface id */
	net_snp = gnrc_netif_hdr_build(NULL, 0, NULL, 0);
	if (net_snp == NULL) {
	DEBUG("gnrc_tcp_pkt.c : _pkt_build_reset_from_pkt() :\
	Can't alloc buffer for netif Header.\n");
	gnrc_pktbuf_release(ip6_snp);
	*(out_pkt) = NULL;
	return -ENOMEM;
	}
	else {
	((gnrc_netif_hdr_t *)net_snp->data)->if_pid = net_hdr->if_pid;
	LL_PREPEND(ip6_snp, net_snp);
	*(out_pkt) = net_snp;
	}
	}

and here

RIOT/sys/net/gnrc/transport_layer/tcp/gnrc_tcp_pkt.c

Lines 223 to 236 in 3e5658d

	if (tcb->ll_iface > 0) {
	gnrc_pktsnip_t *net_snp = gnrc_netif_hdr_build(NULL, 0, NULL, 0);
	if (net_snp == NULL) {
	DEBUG("gnrc_tcp_pkt.c : _pkt_build() : Can't allocate buffer for netif header.\n");
	gnrc_pktbuf_release(ip6_snp);
	*(out_pkt) = NULL;
	return -ENOMEM;
	}
	else {
	((gnrc_netif_hdr_t *)net_snp->data)->if_pid = (kernel_pid_t)tcb->ll_iface;
	LL_PREPEND(ip6_snp, net_snp);
	*(out_pkt) = net_snp;
	}
	}

For the first case, I'm not quite sure why it is only build when the source is link-local. To me it seems sensible to always use the information available (i.e. if a netif header is there, use it), but since we are only using link-local addresses and that case is only for constructing reset replies, this can't be the problem I believe.

For the second case it can only be, that tcb->ll_iface might not be set or set to a wrong value.
edit: this was earlier posted than I wanted. will continue in follow-up comment.

[miri64]

RIOT/tests/gnrc_tcp_client/Makefile

Line 10 in 3e5658d

TCP_TARGET_ADDR ?= fe80::affe%5

Hardcodes the interface identifier to 5. Since we use 6LoWPAN, which adds an extra thread, this might not be the correct one.

[PeterKietzmann]

Hardcodes the interface identifier to 5

I used TCP_TARGET_ADDR=<ll_addr_server> without any interface info I think that's the probelm

[PeterKietzmann]

With %6 at least this issue seems to be fixed. Improving the documentation should do. However, now I see floods of TCP packets which doesn't seem correct. Here I would ask @brummer-simon for clarification

[brummer-simon]

Sorry guys I can't take a look into the issue currently (I am supposed to do the things I am getting paid for during the day;). Maybe I find the time this evening to find something out.

There is still the Problem that I can test only on native currently. Does the TCP packet flooding occur on real boards or on native too?

[miri64]

Sorry guys I can't take a look into the issue currently (I am supposed to do the things I am getting paid for during the day;). Maybe I find the time this evening to find something out.

There is still the Problem that I can test only on native currently. Does the TCP packet flooding occur on real boards or on native too?

I think this goes into the direction I already pointed out when we had the discussion about TCP accepting strings for connect. You promised to fix this at some point anyway ;-).

[miri64]

Improving the documentation should do.

Yepp.

[brummer-simon]

Sorry guys I can't take a look into the issue currently (I am supposed to do the things I am getting paid for during the day;). Maybe I find the time this evening to find something out.
There is still the Problem that I can test only on native currently. Does the TCP packet flooding occur on real boards or on native too?

I think this goes into the direction I already pointed out when we had the discussion about TCP accepting strings for connect. You promised to fix this at some point anyway ;-).

Jeah we talked about that ;). I think the outcome was that moving the adress buffer out of the tcb, this is part of the integration of gnrc_tcp into the sock interface.

[PeterKietzmann]

Does the TCP packet flooding occur on real boards or on native too

Only on hardware (samr21-xpro - samr21-xpro)

[brummer-simon]

Hm this is something I can't test at home :(.

Could you capture the traffic and send me the wireshark dump?

[miri64]

Hm this is something I can't test at home :(.

But in the IoT-LAB ;-).