Riot: usb: fails to respond ro ping when used with 802.15.4
Description
I'm trying to make examples/gnrc_networking work with usb stack. In #11077 I read that it worked when only adding:
USEMODULE += usbus auto_init_usbus usbus_cdc_ecm
CFLAGS += -DGNRC_NETIF_NUMOF=2
When doing exactly that (and adding USB_VID and USB_PID) I see both the wireless and wired interface showing up:
ifconfig
2019-08-13 10:57:30,920 - INFO # Iface 8 HWaddr: 52:DA Channel: 26 Page: 0 NID: 0x23
2019-08-13 10:57:30,924 - INFO # Long HWaddr: 79:7C:09:1A:4E:AA:52:DA
2019-08-13 10:57:30,931 - INFO # TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4
2019-08-13 10:57:30,938 - INFO # AUTOACK ACK_REQ CSMA L2-PDU:102 MTU:1280 HL:64 RTR
2019-08-13 10:57:30,940 - INFO # 6LO IPHC
2019-08-13 10:57:30,943 - INFO # Source address length: 8
2019-08-13 10:57:30,946 - INFO # Link type: wireless
2019-08-13 10:57:30,952 - INFO # inet6 addr: fe80::7b7c:91a:4eaa:52da scope: local VAL
2019-08-13 10:57:30,954 - INFO # inet6 group: ff02::2
2019-08-13 10:57:30,957 - INFO # inet6 group: ff02::1
2019-08-13 10:57:30,961 - INFO # inet6 group: ff02::1:ffaa:52da
2019-08-13 10:57:30,962 - INFO #
2019-08-13 10:57:30,965 - INFO # Statistics for Layer 2
2019-08-13 10:57:30,968 - INFO # RX packets 0 bytes 0
2019-08-13 10:57:30,972 - INFO # TX packets 2 (Multicast: 2) bytes 86
2019-08-13 10:57:30,976 - INFO # TX succeeded 2 errors 0
2019-08-13 10:57:30,978 - INFO # Statistics for IPv6
2019-08-13 10:57:30,981 - INFO # RX packets 0 bytes 0
2019-08-13 10:57:30,986 - INFO # TX packets 2 (Multicast: 2) bytes 128
2019-08-13 10:57:30,989 - INFO # TX succeeded 2 errors 0
2019-08-13 10:57:30,990 - INFO #
2019-08-13 10:57:30,993 - INFO # Iface 9 HWaddr: BE:3B:B8:53:34:27
2019-08-13 10:57:30,998 - INFO # L2-PDU:1500 MTU:1500 HL:64 RTR
2019-08-13 10:57:31,001 - INFO # Source address length: 6
2019-08-13 10:57:31,003 - INFO # Link type: wired
2019-08-13 10:57:31,010 - INFO # inet6 addr: fe80::bc3b:b8ff:fe53:3427 scope: local TNT[1]
2019-08-13 10:57:31,013 - INFO # inet6 group: ff02::2
2019-08-13 10:57:31,015 - INFO # inet6 group: ff02::1
2019-08-13 10:57:31,019 - INFO # inet6 group: ff02::1:ff53:3427
2019-08-13 10:57:31,020 - INFO #
2019-08-13 10:57:31,023 - INFO # Statistics for Layer 2
2019-08-13 10:57:31,026 - INFO # RX packets 12 bytes 1909
2019-08-13 10:57:31,031 - INFO # TX packets 1 (Multicast: 1) bytes 0
2019-08-13 10:57:31,034 - INFO # TX succeeded 0 errors 0
2019-08-13 10:57:31,037 - INFO # Statistics for IPv6
2019-08-13 10:57:31,040 - INFO # RX packets 10 bytes 1085
2019-08-13 10:57:31,044 - INFO # TX packets 1 (Multicast: 1) bytes 48
2019-08-13 10:57:31,049 - INFO # TX succeeded 1 errors 0
I also see that a ethernet device shows up on my host:
ethtool
ethtool enp0s20u2
Settings for enp0s20u2:
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
enp0s20u2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::fc88:8fcb:85a3:bbf0 prefixlen 64 scopeid 0x20<link>
ether be:3b:b8:53:34:27 txqueuelen 1000 (Ethernet)
RX packets 143 bytes 8972 (8.9 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 329 bytes 46865 (46.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
md5-18d3dae528cec633f3b94dd8656a7d0c
PING fe80::bc3b:b8ff:fe53:3427%enp0s20u2(fe80::bc3b:b8ff:fe53:3427%enp0s20u2) 56 data bytes
^C
--- fe80::bc3b:b8ff:fe53:3427%enp0s20u2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3061ms
md5-774fa53c4724a984b4c1af162d50120e
ping6 fe80::fc88:8fcb:85a3:bbf0%9
2019-08-13 11:06:17,740 - INFO # ping6 fe80::fc88:8fcb:85a3:bbf0%9
2019-08-13 11:06:20,741 - INFO #
2019-08-13 11:06:20,745 - INFO # --- fe80::fc88:8fcb:85a3:bbf0 PING statistics ---
2019-08-13 11:06:20,751 - INFO # 3 packets transmitted, 0 packets received, 100% packet loss
> ping6 fe80::fc88:8fcb:85a3:bbf0%9
2019-08-13 11:06:22,230 - INFO # ping6 fe80::fc88:8fcb:85a3:bbf0%9
2019-08-13 11:06:25,232 - INFO #
2019-08-13 11:06:25,235 - INFO # --- fe80::fc88:8fcb:85a3:bbf0 PING statistics ---
2019-08-13 11:06:25,241 - INFO # 3 packets transmitted, 0 packets received, 100% packet loss
> ping6 fe80::fc88:8fcb:85a3:bbf0%9
2019-08-13 11:07:04,238 - INFO # ping6 fe80::fc88:8fcb:85a3:bbf0%9
2019-08-13 11:07:07,239 - INFO #
2019-08-13 11:07:07,243 - INFO # --- fe80::fc88:8fcb:85a3:bbf0 PING statistics ---
2019-08-13 11:07:07,249 - INFO # 3 packets transmitted, 0 packets received, 100% packet loss
md5-a9f27d440d4f8ae3ad2e2d5271b37d5d
> 2019-08-13 11:11:25,584 - INFO # icmpv6_echo: Building echo message with type=huid=129, seq=7778, payload:
2019-08-13 11:11:25,590 - INFO # 00000000 BD 7E 52 5D 00 00 00 00 19 C9 08 00 00 00 00 00
2019-08-13 11:11:25,597 - INFO # 00000010 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
2019-08-13 11:11:25,603 - INFO # 00000020 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
2019-08-13 11:11:25,607 - INFO # 00000030 30 31 32 33 34 35 36 37
2019-08-13 11:11:25,607 - INFO #
md5-070c4b29a9347137c633733f5d69cc53
ping6 fe80::bc3b:b8ff:fe53:3427%enp0s20u2
PING fe80::bc3b:b8ff:fe53:3427%enp0s20u2(fe80::bc3b:b8ff:fe53:3427%enp0s20u2) 56 data bytes
64 bytes from fe80::bc3b:b8ff:fe53:3427%enp0s20u2: icmp_seq=1 ttl=64 time=32.0 ms
64 bytes from fe80::bc3b:b8ff:fe53:3427%enp0s20u2: icmp_seq=2 ttl=64 time=30.8 ms
64 bytes from fe80::bc3b:b8ff:fe53:3427%enp0s20u2: icmp_seq=3 ttl=64 time=30.9 ms
64 bytes from fe80::bc3b:b8ff:fe53:3427%enp0s20u2: icmp_seq=4 ttl=64 time=30.8 ms
64 bytes from fe80::bc3b:b8ff:fe53:3427%enp0s20u2: icmp_seq=5 ttl=64 time=30.8 ms
md5-066c81049b84c207423bef93b2267714
+# Include usb modules
+USEMODULE += usbus_cdc_ecm
+USEMODULE += auto_init_usbus
+# Increase the number of network interfaces in case the board under test also provides a network interface
+CFLAGS += -DGNRC_NETIF_NUMOF=2
+# USB device vendor and product ID
+# pid.codes test VID/PID, not globally unique
+USB_VID ?= 1209
+USB_PID ?= 0001
+CFLAGS += -DUSB_CONFIG_VID=0x$(USB_VID) -DUSB_CONFIG_PID=0x$(USB_PID)
md5-2f2b43d1575ae2aec9253ba9dc01902f
make -C examples/gnrc_networking BOARD=samr21-xpro flash -j3 term
md5-06537b863a7587b3ad470d1d4e76860a
Operating System Environment
-----------------------------
Operating System: "Ubuntu" "18.04.2 LTS (Bionic Beaver)"
Kernel: Linux 4.18.0-25-generic x86_64 x86_64
Installed compiler toolchains
-----------------------------
native gcc: gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
avr-gcc: missing
mips-mti-elf-gcc: missing
msp430-gcc: missing
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.14.0-rc3
cppcheck: Cppcheck 1.82
doxygen: 1.8.16
flake8: missing
git: git version 2.21.0
make: GNU Make 4.1
openocd: Open On-Chip Debugger 0.10.0+dev-00703-g92bb76a4-dirty (2019-07-19-14:27)
python: Python 3.6.7
python2: Python 2.7.15rc1
python3: Python 3.6.7
coccinelle: missing
fjmolinas
All 22 comments
I might be missing to include and additional requirement that isn't needed in tests/usbus_cdc_ecm/?
fjmolinas
on 13 Aug 2019
I'm seeing the same behavior on the nRF52840-dongle. When I add, to the usbus_minimal example, the modules usbus_cdc_ecm, auto_init_gnrc_netif, gnrc_ipv6_default and gnrc_icmpv6_echo along with -DGNRC_NETIF_NUMOF=2, I can ping the board via USB. As soon as I add gnrc_netdev_default which pulls in 802.15.4, I don't get answers to pings or even to the ICMPv6 neighbor solicitation messages sent over USB. (I don't have serial console there yet to provide additional debug information).
chrysn
on 13 Sep 2019
I wrote a guide on the wiki on how to configure a USB border router. Please let me know if the steps shown there resolve the issue here.
bergzand
on 16 Sep 2019
And of course feel free to fix any late night writing errors you can find in the guide :smile:
bergzand
on 16 Sep 2019
I wrote a guide on the wiki on how to configure a USB border router. Please let me know if the steps shown there resolve the issue here.
This indeed fixed the issue for me (well didn't fix since it was a layer 8 issue :) ). I did a quick test and was able to get it working.
I think it would be better to have the documentation in code than in the wiki though.
fjmolinas
on 17 Sep 2019
@fjmolinas good to hear. Does this mean we can close this issue? @chrysn is that okay with you?
I think it would be better to have the documentation in code than in the wiki though.
I agree, but I'm not sure how to structure the information in the guide to fit into the current doxygen documentation. I wanted to structure it as a guide to give readers some insight into the requirements for the setup. I don't know yet how to translate this to the doxygen, assuming we don't want to just copy the whole thing into a doxygen file.
bergzand
on 17 Sep 2019
@chrysn is that okay with you?
I couldn't reproduce this as a fix yet, but then again I only matched my
problem here from the phenotype, so as this fixes what fjmolinas
described, yeah close it -- either it'll solve my problem as well or I
misfiled it anyway and will open something else when I have better
debugging capabilities on my board.
chrysn
on 17 Sep 2019
@fjmolinas good to hear. Does this mean we can close this issue? @chrysn is that okay with you?
Yep closed.
fjmolinas
on 17 Sep 2019
Going through the issue now that I have good terminal usability, I can confirm that following the tutorial did solve my issues with USB ethernet and nimble IPSP; adding the gnrc_sixlowpan_border_router_default (…6lowpan_router… was insufficient, as was gnrc_ipv6_router_default alone which gets pulled in by …border_router…) module made the difference.
The difference between working and non-working setups was that in the non-working cases, all addresses the USB interface got were always tentative (even with prefix delegation) and thus not used, whereas in the working cases they were VALid (as were the other interface's addresses in the non-working cases).
ifconfig's output on the USB interface when NetworkManager IPv6 forwarding is active and another interface is present
Iface 11 HWaddr: CA:63:71:D5:F4:A4
L2-PDU:1500 MTU:1500 HL:64 Source address length: 6
Link type: wired
inet6 addr: fe80::c863:71ff:fed5:f4a4 scope: local TNT[1]
inet6 addr: 2a02:1234:abcd:8016:c863:71ff:fed5:f4a4 scope: global TNT[1]
inet6 group: ff02::1
@bergzand, can you confirm that it is expected behavior to require a router module in the presence of two network interfaces for link-local addresses on at least one of them to come up? (Because I don't think so, and that would make the approved solution here a workaround rather than a fix.)
chrysn
on 18 Sep 2019
@bergzand, can you confirm that it is expected behavior to require a router module in the presence of two network interfaces for link-local addresses on at least one of them to come up?
@miri64 I think you have a better understanding of the details involved here.
bergzand
on 18 Sep 2019
@bergzand, can you confirm that it is expected behavior to require a router module in the presence of two network interfaces for link-local addresses on at least one of them to come up?
@miri64 I think you have a better understanding of the details involved here.
From the wording of the quoted queston: No that shouldn't be the case.
However, I'm confused. This issue is about pinging a node. So just to clarify: Pinging a node interface's link-local address through the another interface of that node should not be possible, as a link-local address is _per definition_ only local (and thus valid) to the link (i.e. also the interface).
miri64
on 18 Sep 2019
From the wording of the quoted queston: No that shouldn't be the case.
Is the start of the USB interface maybe delayed? It might be that in that case the initial messages might not be sent because they are try to be sent before the interface was really up.
miri64
on 18 Sep 2019
However, I'm confused. This issue is about pinging a node. So just to
clarify: Pinging a node interface's link-local address through the
another interface of that node should not be possible, as a link-local
address is _per definition_ only local (and thus valid) to the link
(i.e. also the interface).
This is about being able to ping the USB-attached node on its link-local
address on the USB interface from the host. When nimble or 802154 are
added, these addresses are the same, but they stay in TNT[1]
indefinitely (ok, at least 5') rather than being VAL.
Is the start of the USB interface maybe delayed? It might be that in
that case the initial messages might not be sent because they are try
to be sent before the interface was really up.
That'd be a plausible explanation, given that unlike the others it does
need to wait for the host. (And I don't have a setup where I can hotplug
that w/o power cycling the whole device). I tried ifconfig 11 set state
reset, but unable to set status.
chrysn
on 18 Sep 2019
This is about being able to ping the USB-attached node on its link-local address on the USB interface from the host. When nimble or 802154 are added, these addresses are the same, but they stay in
TNT[1]indefinitely (ok, at least 5') rather than being VAL.
That the addresses are the same _should_ have been fixed ages ago. luid_get() (which typically is used to generate a hardware address on which in turn the link-local address is generated from) is supposed to return something different with every call.
miri64
on 18 Sep 2019
This is about being able to ping the USB-attached node on its
link-local address on the USB interface from the host. When nimble
or 802154 are added, these addresses are the same, but they stay in
TNT[1]indefinitely (ok, at least 5') rather than being VAL.That the addresses are the same _should_ have been fixed ages ago.
I may have phrased that unclearly: The device's USB interface uses the
same address independently of whether an additional netif is present or
not -- just in one case the address is VAL and in the other it's TNT[1].
I don't see any misbehavior in the address assignment.
chrysn
on 18 Sep 2019
[…] -- just in one case the address is VAL and in the other it's TNT[1].
Ok, then I'm unclear what the "cases" are :thinking:
miri64
on 18 Sep 2019
Do you mean different run-times of the device?
miri64
on 18 Sep 2019
To summarize, there are three variations of the gcoap example I'm building:
In the base version (let's call it version A), I add the
usbus_cdc_ecmmodule (and set-DGNRC_NETIF_NUMOF=2to keep me out of trouble later), but keepgnrc_netdev_defaultand any other netdev out of the modules set. When I flash that, I get exactly one interface inifconfig, which is the USB interface with its proper address. That address is VAL and I can ping it from the host.Once I add
nimble_netifto the mix (call that version B), there are two network interfaces. They have no ambitions of routing but why should they. When I flash that, I see both interfaces. Both get their respective addresses, but the USB interface's address staysTNT[1]and can not be pinged from the host.Only if I add
gnrc_sixlowpan_border_router_defaultto get a third version (C), then the USB interface becomesVALafter bootup, and can be pinged.
In none of the examples I make any actual attempts to configure the other network interface yet. In the original issue description the same was done with the default 802.15.4 network stack there (similar to my B), and the problem went away when fjmolinas followed bergzand's border router instructions, as part of which the border router was pulled in (similar to my C), working around the issue.
chrysn
on 18 Sep 2019
- Once I add
nimble_netifto the mix (call that version B), there are two network interfaces. They have no ambitions of routing but why should they. When I flash that, I see both interfaces. Both get their respective addresses, but the USB interface's address staysTNT[1]and can not be pinged from the host.
Ahhhh I think here the node assumes that it is a 6LN, and waits for the upstream router to register to. Problem: the Ethernet interface should not do that. IIRC https://github.com/RIOT-OS/RIOT/pull/10499 solved a similar problem on ESP32 with esp_now.
miri64
on 18 Sep 2019
(about time that PR gets in ;-P)
miri64
on 18 Sep 2019
I merged that PR #10499 into my testing branch and saw no change in either case A, B or C (and frankly don't understand the interactions between #10499 and #11077). Should this have changed things out of the box or is there a particular change I can try on the USB Ethernet device?
chrysn
on 19 Sep 2019
The general resolution to this issue (ie. even for the non-router case) happened in 7cba2fb63df2c7cf915b374195d7f28dea48da91.
chrysn
on 22 Oct 2019
Related issues
silkeh
·
5Comments
l3nko
·
7Comments
pietrotedeschi
·
4Comments
miri64
·
3Comments
jcarrano
·
5Comments