ieee802154_submac: IPv6 fragmentation broken

[benpicco]

Description

Steps to reproduce the issue

• Select the gnrc_ipv6_ext_frag module.
• send a large ICMPv6 ping message (e.g. 2k) to another node with gnrc_ipv6_ext_frag enabled

Expected results

Fragmented IPv6 packets should be echoed back

2021-10-17 19:29:50,937 # ping -s 2048 fe80::ac8d:fee1:6041:91f1
2021-10-17 19:29:51,232 # 2056 bytes from fe80::ac8d:fee1:6041:91f1%6: icmp_seq=0 ttl=64 rssi=-40 dBm time=286.008 ms
2021-10-17 19:29:52,232 # 2056 bytes from fe80::ac8d:fee1:6041:91f1%6: icmp_seq=1 ttl=64 rssi=-40 dBm time=284.409 ms
2021-10-17 19:29:53,234 # 2056 bytes from fe80::ac8d:fee1:6041:91f1%6: icmp_seq=2 ttl=64 rssi=-40 dBm time=285.100 ms
2021-10-17 19:29:53,234 # 
2021-10-17 19:29:53,238 # --- fe80::ac8d:fee1:6041:91f1 PING statistics ---
2021-10-17 19:29:53,243 # 3 packets transmitted, 3 packets received, 0% packet loss
2021-10-17 19:29:53,248 # round-trip min/avg/max = 284.409/285.172/286.008 ms

Actual results

Sending of fragmented IPv6 packets fails

2021-10-17 19:40:39,173 # ping -s 2048 fe80::204:2519:1801:c905
2021-10-17 19:40:40,176 # gnrc_netif: can't queue packet for sending
2021-10-17 19:40:40,177 # gnrc_netif: can't queue packet for sending
2021-10-17 19:40:40,179 # gnrc_netif: can't queue packet for sending
2021-10-17 19:40:40,180 # gnrc_netif: can't queue packet for sending
2021-10-17 19:40:40,182 # gnrc_netif: can't queue packet for sending
2021-10-17 19:40:40,184 # gnrc_netif: can't queue packet for sending
2021-10-17 19:40:40,185 # gnrc_netif: can't queue packet for sending
2021-10-17 19:40:40,186 # gnrc_netif: can't queue packet for sending
2021-10-17 19:40:42,173 # 
2021-10-17 19:40:42,175 # --- fe80::204:2519:1801:c905 PING statistics ---
2021-10-17 19:40:42,176 # 3 packets transmitted, 0 packets received, 100% packet loss

6LoWPAN fragmented frames still work

2021-10-17 19:41:10,772 # ping -s 512 fe80::204:2519:1801:c905
2021-10-17 19:41:10,865 # 520 bytes from fe80::204:2519:1801:c905%7: icmp_seq=0 ttl=64 rssi=68 dBm time=91.283 ms
2021-10-17 19:41:11,867 # 520 bytes from fe80::204:2519:1801:c905%7: icmp_seq=1 ttl=64 rssi=68 dBm time=92.051 ms
2021-10-17 19:41:12,858 # 520 bytes from fe80::204:2519:1801:c905%7: icmp_seq=2 ttl=64 rssi=68 dBm time=83.843 ms
2021-10-17 19:41:12,858 # 
2021-10-17 19:41:12,858 # --- fe80::204:2519:1801:c905 PING statistics ---
2021-10-17 19:41:12,859 # 3 packets transmitted, 3 packets received, 0% packet loss
2021-10-17 19:41:12,860 # round-trip min/avg/max = 83.843/89.059/92.051 ms

Versions

RIOT master & 2021.10-branch

[miri64]

That is a known issue for IEEE 802.15.4 in general (there is fragmentation on top of fragmentation happening and that is causing the radio to be overwhelmed with fast switches from RX to TX mode), that's why 4.10 is still marked as experimental. But good thing, there is an issue now and to know that this apparently is not fixed by ieee802154_submac alone.

[jia200x]

I suspect this is an issue of the queue on top rather than the SubMAC.
Could you try increasing CONFIG_GNRC_NETIF_PKTQ_POOL_SIZE? If this fixes it, we should probably look for solutions that throttle packet flow going to the interface, rather than putting everything in the queue.

[benpicco]

Could you try increasing CONFIG_GNRC_NETIF_PKTQ_POOL_SIZE?

Yes with CFLAGS += -DCONFIG_GNRC_NETIF_PKTQ_POOL_SIZE=32 I get

2021-10-18 13:35:07,437 # ping -s 2048 fe80::ac8d:fee1:6041:91f1
2021-10-18 13:35:07,730 # 2056 bytes from fe80::ac8d:fee1:6041:91f1%7: icmp_seq=0 ttl=64 rssi=-136 dBm time=289.273 ms
2021-10-18 13:35:10,438 # 
2021-10-18 13:35:10,439 # --- fe80::ac8d:fee1:6041:91f1 PING statistics ---
2021-10-18 13:35:10,441 # 3 packets transmitted, 1 packets received, 66% packet loss
2021-10-18 13:35:10,442 # round-trip min/avg/max = 289.273/289.273/289.273 ms

But after the first round-trip, none are successful. Round-trips with smaller payload still work.

we should probably look for solutions that throttle packet flow going to the interface, rather than putting everything in the queue.

👍

[maribu]

we should probably look for solutions that throttle packet flow going to the interface, rather than putting everything in the queue.

Does gnrc_tx_sync fix the issue?