search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.55k stars 6.46k forks source link

UDP over IPSP not working on nRF52840 #50598

Closed jmrua closed 1 year ago

jmrua commented 2 years ago

Describe the bug UDP packets are not sent through the IPSP interface if the destination IP is a global IP. It works just fine if the destination IP is link-local. Both ICMPv6 and TCP traffic work as expected.

Although the packets do not appear on the interface between the host and the device (analyzed using Wireshark from the host), the zephyr logs seem to indicate that they are sent, no errors occur and the packet send callback returns a value greater than zero. This was tested and replicated on the IPSP sample and other samples such as the echo server.

Environment Tested on:

The route and IP configuration were performed manually ( CONFIG_NET_CONFIG_MY_IPV6_ADDR and CONFIG_NET_CONFIG_PEER_IPV6_ADDR) and also tested with a remote configuration via Router Advertisement with RADVD service in the host (configuration shown below).

radvd.conf

interface bt0
{
AdvSendAdvert on;
AdvDefaultPreference high;
prefix 2001:db8::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};

    route 2001:db8::/64
    {
        AdvRoutePreference high;
            AdvRouteLifetime 3600;
    };

};

To Reproduce Steps to reproduce the behavior:

  1. Compile and flash the sample/bluetooth/ipsp sample

  2. Connect to the board from the host.

    modprobe bluetooth_6lowpan
echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
echo "connect  <nRF MAC> <type>" > /sys/kernel/debug/bluetooth/6lowpan_control
ip address add 2001:db8::2/64 dev bt0 # only needed on manual IP configuration

    3.a. send a UDP packet from the host to the board IP with port 4242. (for example, using Netcat) nc -6 -u <nRF IP> 4242

    3.b. Alternatively, the Zephyr shell command can be used to replicate the same behavior net udp send <host IP> <host port> <Payload>

When using a global IP as destination, the board never replies and starts to send a Neighbor Solicitation request to the host IP every time it should send a UDP packet, even if there is a valid neighbor entry on net nbr or a valid route installed on the board.

Additionally, the following settings have been added to the sample's prj_dbg.conf to try to identify the problem.

CONFIG_NET_BUF_LOG_LEVEL_DBG=y
CONFIG_NET_IF_LOG_LEVEL_DBG=y
CONFIG_NET_6LO_LOG_LEVEL_DBG=y
CONFIG_NET_IPV6_LOG_LEVEL_DBG=y
CONFIG_NET_UDP_LOG_LEVEL_DBG=y
CONFIG_NET_CORE_LOG_LEVEL_DBG=y
CONFIG_NET_ROUTE_LOG_LEVEL_DBG=y

Logs and console output In this case, the IPs will be: PC(Host)

 Link Local: fe80::8c88:2bff:fe20:39d8 with prefix length 64
Global: 2001:db8::8c88:2bff:fe20:39d8 with prefix length 64

nRf52840

 Link Local: fe80::c4b2:5bff:fe9b:d45a with prefix length 64
Global:  2001:db8::c4b2:5bff:fe9b:d45a with prefix length 64

Interface 0x200018f4 (Bluetooth) [1]

Link addr : C4:B2:5B:9B:D4:5A MTU : 1280 Flags : NO_AUTO_START,IPv6 IPv6 unicast addresses (max 3): fe80::c4b2:5bff:fe9b:d45a autoconf preferred infinite 2001:db8::c4b2:5bff:fe9b:d45a autoconf preferred IPv6 multicast addresses (max 4): ff02::1 ff02::1:ff9b:d45a IPv6 prefixes (max 2): 2001:db8::/64 IPv6 default router : fe80::8c88:2bff:fe20:39d8 IPv6 hop limit : 64 IPv6 base reachable time : 30000 IPv6 reachable time : 41009 IPv6 retransmit timer : 0

uart:~$ net route

IPv6 routes for interface 1 (0x200018f4) (Bluetooth)

IPv6 prefix : 2001:db8::/64 neighbor : 0x20000ab8 addr : 8C:88:2B:20:39:D8 lifetime : 3596 sec

uart:~$ net ipv6 IPv6 support : enabled IPv6 fragmentation support : disabled Multicast Listener Discovery support : enabled Neighbor cache support : enabled Neighbor discovery support : enabled Duplicate address detection (DAD) support : enabled Router advertisement RDNSS option support : enabled 6lo header compression support : enabled Max number of IPv6 network interfaces in the system : 1 Max number of unicast IPv6 addresses per network interface : 3 Max number of multicast IPv6 addresses per network interface : 4 Max number of IPv6 prefixes per network interface : 2

IPv6 addresses for interface 1 (0x200018f4) (Bluetooth)

Type State Lifetime (sec) Address autoconf preferred infinite fe80::c4b2:5bff:fe9b:d45a/128 autoconf preferred 2152792 2001:db8::c4b2:5bff:fe9b:d45a/64


- Console Log for a TCP packet send operation with the zephyr shell command(working for global and link local)

uart:~$ net tcp send "test" Message sent [00:06:37.625,885] net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor lookup 0x20000b0c (0) iface 0x200018f4/1 addr 2001:db8::e [00:06:37.625,915] net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor 0x20000b0c addr 8C:88:2B:20:39:D8 [00:06:37.625,946] net_if: net_if_tx: (shell_uart): Processing (pkt 0x200106f0, prio 1) network packet iface 0x200018f4/1 [00:06:37.626,007] net_6lo: compress_hoplimit: (shell_uart): HLIM compressed (64) [00:06:37.626,007] net_6lo: compress_tfl: (shell_uart): Traffic class and Flow label elided [00:06:37.719,757] net_core: net_recv_data: (BT RX): prio 0 iface 0x200018f4 pkt 0x20010a98 len 58 [00:06:37.719,940] net_core: net_rx: (rx_q[0]): Received pkt 0x20010a98 len 58 [00:06:37.719,970] net_6lo: get_ihpc_inlined_size: (rx_q[0]): Size of inlined IP HDR data: 36 [00:06:37.720,001] net_6lo: uncompress_IPHC_header: (rx_q[0]): Enough tailroom. Uncompress inplace [00:06:37.720,031] net_6lo: uncompress_tfl: (rx_q[0]): ECN + 2-bit Pad + Flow Label, DSCP is elided [00:06:37.720,031] net_6lo: uncompress_sa: (rx_q[0]): SAC_0 [00:06:37.720,092] net_6lo: uncompress_sa: (rx_q[0]): SAM_00 full src addr inlined [00:06:37.720,123] net_6lo: uncompress_da: (rx_q[0]): DAC_0 [00:06:37.720,184] net_6lo: uncompress_da: (rx_q[0]): DAM_00 full dst addr inlined

- Console Log for a UDP packet send operation with the zephyr shell command

 - To link-local IP (working)

uart:~$ net udp send fe80::8c88:2bff:fe20:39d8 4242 "test" [00:12:47.342,956] net_ipv6: check_route: (shell_uart): Router 0x20005b90 nexthop fe80::8c88:2bff:fe20:39d8 [00:12:47.343,048] net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor lookup 0x20000ab8 (0) iface 0x200018f4/1 addr fe80::8c88:2bff:fe20:39d8 state static [00:12:47.343,078] net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor 0x20000ab8 addr 8C:88:2B:20:39:D8 [00:12:47.343,109] net_if: net_if_tx: (shell_uart): Processing (pkt 0x20010810, prio 1) network packet iface 0x200018f4/1 [00:12:47.343,139] net_6lo: compress_nh_udp: (shell_uart): Can not compress ports, ports are inlined [00:12:47.343,170] net_6lo: compress_da: (shell_uart): DAM_11 dst addr fully elided [00:12:47.343,200] net_6lo: compress_sa: (shell_uart): SAM_11 src address is fully elided [00:12:47.343,231] net_6lo: compress_hoplimit: (shell_uart): HLIM compressed (64) [00:12:47.343,261] net_6lo: compress_tfl: (shell_uart): Traffic class and Flow label elided [00:12:47.343,383] net_if: net_if_tx: (shell_uart): Calling context send cb 0x20005d64 status 13 [00:12:47.416,717] net_core: net_recv_data: (BT RX): prio 0 iface 0x200018f4 pkt 0x20010ae0 len 66 [00:12:47.416,900] net_core: net_rx: (rx_q[0]): Received pkt 0x20010ae0 len 66 [00:12:47.416,931] net_6lo: get_ihpc_inlined_size: (rx_q[0]): Size of inlined IP HDR data: 4 [00:12:47.416,961] net_6lo: uncompress_IPHC_header: (rx_q[0]): Enough tailroom. Uncompress inplace [00:12:47.416,992] net_6lo: uncompress_tfl: (rx_q[0]): ECN + 2-bit Pad + Flow Label, DSCP is elided [00:12:47.417,022] net_6lo: uncompress_sa: (rx_q[0]): SAC_0 [00:12:47.417,053] net_6lo: uncompress_sa: (rx_q[0]): SAM_11 generate src addr from ll [00:12:47.417,083] net_6lo: uncompress_da: (rx_q[0]): DAC_0 [00:12:47.417,114] net_6lo: uncompress_da: (rx_q[0]): DAM_11 generate dst addr from ll

 - To global IP (not working)

uart:~$ net udp send 2001:db8::8c88:2bff:fe20:39d8 4242 "test" [00:14:00.579,254] net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor lookup 0x20000b0c (0) iface 0x200018f4/1 addr 2001:db8::8c88:2bff:fe20:39d8 state reachable [00:14:00.579,315] net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor 0x20000b0c addr 8C:88:2B:20:39:D8 [00:14:00.579,345] net_if: net_if_tx: (shell_uart): Processing (pkt 0x20010810, prio 1) network packet iface 0x200018f4/1 [00:14:00.579,376] net_6lo: compress_nh_udp: (shell_uart): Can not compress ports, ports are inlined [00:14:00.579,406] net_6lo: compress_hoplimit: (shell_uart): HLIM compressed (64) [00:14:00.579,437] net_6lo: compress_tfl: (shell_uart): Traffic class and Flow label elided [00:14:00.579,711] net_if: net_if_tx: (shell_uart): Calling context send cb 0x20005d64 status 45 [00:14:01.530,700] net_core: net_recv_data: (BT RX): prio 0 iface 0x200018f4 pkt 0x20010ae0 len 51 [00:14:01.530,883] net_core: net_rx: (rx_q[0]): Received pkt 0x20010ae0 len 51 [00:14:01.530,914] net_6lo: get_ihpc_inlined_size: (rx_q[0]): Size of inlined IP HDR data: 17 [00:14:01.530,944] net_6lo: uncompress_IPHC_header: (rx_q[0]): Enough tailroom. Uncompress inplace [00:14:01.530,975] net_6lo: uncompress_tfl: (rx_q[0]): Tcl and Flow label elided [00:14:01.531,005] net_6lo: uncompress_sa: (rx_q[0]): SAC_0 [00:14:01.531,036] net_6lo: uncompress_sa: (rx_q[0]): SAM_11 generate src addr from ll [00:14:01.531,066] net_6lo: uncompress_da: (rx_q[0]): DAC_0 [00:14:01.531,097] net_6lo: uncompress_da: (rx_q[0]): DAM_00 full dst addr inlined [00:14:01.531,188] net_ipv6: net_ipv6_input: (rx_q[0]): IPv6 packet len 72 received from fe80::8c88:2bff:fe20:39d8 to 2001:db8::c4b2:5bff:fe9b:d45a [00:14:01.531,341] net_ipv6: handle_ns_input: (rx_q[0]): Received Neighbor Solicitation from fe80::8c88:2bff:fe20:39d8 to 2001:db8::c4b2:5bff:fe9b:d45a, target 2001:db8::c4b2:5bff:fe9b:d45a iface 0x200018f4/1 [00:14:01.531,463] net_ipv6: net_ipv6_nbr_add: (rx_q[0]): [0] nbr 0x20000ab8 state 0 router 0 IPv6 fe80::8c88:2bff:fe20:39d8 ll 8C:88:2B:20:39:D8 iface 0x200018f4/1 [00:14:01.531,707] net_ipv6: net_ipv6_send_na: (rx_q[0]): Sent Neighbor Advertisement from 2001:db8::c4b2:5bff:fe9b:d45a to fe80::8c88:2bff:fe20:39d8, target 2001:db8::c4b2:5bff:fe9b:d45a iface 0x200018f4/1 [00:14:01.531,799] net_ipv6: check_route: (rx_q[0]): Router 0x20005b90 nexthop fe80::8c88:2bff:fe20:39d8 [00:14:01.531,860] net_ipv6: net_ipv6_prepare_for_send: (rx_q[0]): Neighbor lookup 0x20000ab8 (0) iface 0x200018f4/1 addr fe80::8c88:2bff:fe20:39d8 state static [00:14:01.531,921] net_ipv6: net_ipv6_prepare_for_send: (rx_q[0]): Neighbor 0x20000ab8 addr 8C:88:2B:20:39:D8 [00:14:01.531,951] net_if: net_if_tx: (rx_q[0]): Processing (pkt 0x20010810, prio 1) network packet iface 0x200018f4/1 [00:14:01.531,982] net_6lo: compress_da: (rx_q[0]): DAM_11 dst addr fully elided [00:14:01.531,982] net_6lo: compress_hoplimit: (rx_q[0]): HLIM compressed (255) [00:14:01.532,012] net_6lo: compress_tfl: (rx_q[0]): Traffic class and Flow label elided [00:14:01.532,135] net_core: processing_data: (rx_q[0]): Consumed pkt 0x20010ae0

carlescufi commented 2 years ago

@jmrua thanks for reporting this. Note that IPSP unfortunately lacks a maintainer right now in Zephyr, so we might not be able to help out in a timely manner.

carlescufi commented 1 year ago

@jmrua feel free to open a Pull Request if you have identified a fix for this.

jmrua commented 1 year ago

@carlescufi After some more debugging, I think that the problem may be a problem with the Bluetooth layer 2 code, specifically in the send function ( bt_l2cap_chan_send). For the same payload, (The same case as above, TCP/UDP packet with the string "test" ) the return value for UDP with a destination link-local IP it returns 13, with TCP it returns a 17 and with UDP and global IP as destination IP it returns 45. Which, It is a bit odd that fluctuates that differences in bytes between the global UDP send and the link local, when the difference in the packet should only be the IP fields. If I'm able to figure out a fix, I will Pull Request it.

carlescufi commented 1 year ago

@carlescufi After some more debugging, I think that the problem may be a problem with the Bluetooth layer 2 code, specifically in the send function ( bt_l2cap_chan_send). For the same payload, (The same case as above, TCP/UDP packet with the string "test" ) the return value for UDP with a destination link-local IP it returns 13, with TCP it returns a 17 and with UDP and global IP as destination IP it returns 45. Which, It is a bit odd that fluctuates that differences in bytes between the global UDP send and the link local, when the difference in the packet should only be the IP fields. If I'm able to figure out a fix, I will Pull Request it.

Thanks for the analysis! In that case I'll ask @jori-nordic to take a look, since he recently looked into the L2CAP internals.

jori-nordic commented 1 year ago

@jmrua could you log the exact L2CAP payload? I'm thinking its length differs between the packet types you listed. A simple 

    LOG_HEXDUMP_ERR(buf->data, buf->len, "l2cap payload");

inside bt_l2cap_chan_send (before the return ofc) should suffice.

The return value of chan_send is a bit cryptic, because it will sometimes return a lower value, even though it has queued the rest of the packet and will transmit it without needing further calls. I'll make a documentation PR to highlight this later.

jmrua commented 1 year ago

@jori-nordic Here are the logs with your suggested addition

UDP Global IP:

uart:~$ net udp send 2001:db8::8c88:2bff:fe20:39d8 2222 "test"
Message sent
[00:08:17.503,784] <dbg> net_ctx: net_context_bind: (shell_uart): Context 0x20005bf0 binding to UDP [::]:49737 iface 1 (0x20001898)
[00:08:17.503,906] <dbg> net_ctx: context_setup_udp_packet: (shell_uart): context_setup_udp_packet
[00:08:17.504,089] <dbg> net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor lookup 0x20000b0c (0) iface 0x20001898/1 addr 2001:db8::8c88:2bff:fe20:39d8 state stale
[00:08:17.504,119] <dbg> net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor 0x20000b0c addr 8C:88:2B:20:39:D8
[00:08:17.504,150] <dbg> net_ipv6: ipv6_nbr_set_state: (shell_uart): nbr 0x20000b0c stale -> delay
[00:08:17.504,180] <dbg> net_if: net_if_tx: (shell_uart): Processing (pkt 0x20010710, prio 1) network packet iface 0x20001898/1
[00:08:17.504,486] <err> net_bt: l2cap payload
                                 ad 81 05 00 5a                                   |....Z            

[00:08:17.504,547] <dbg> net_if: net_if_tx: (shell_uart): Calling context send cb 0x20005bf0 status 45
[00:08:17.504,730] <dbg> net_ctx: net_context_unref: (shell_uart): Context 0x20005bf0 released
[00:08:22.504,272] <dbg> net_ipv6: ipv6_nd_reachable_timeout: (sysworkq): nbr 0x20000b0c moving 2001:db8::8c88:2bff:fe20:39d8 state to PROBE (4)
[00:08:22.504,302] <dbg> net_ipv6: ipv6_nd_reachable_timeout: (sysworkq): nbr 0x20000b0c probe count 1
[00:08:22.504,547] <dbg> net_ipv6: net_ipv6_send_ns: (sysworkq): Sent Neighbor Solicitation from 2001:db8::c4b2:5bff:fe9b:d45a to ff02::1:ff20:39d8, target 2001:db8::8c88:2bff:fe20:39d8 iface 0x20001898/1
[00:08:22.504,608] <dbg> net_if: net_if_tx: (sysworkq): Processing (pkt 0x20010710, prio 1) network packet iface 0x20001898/1
[00:08:22.504,730] <err> net_bt: l2cap payload
                                 0d 00 40 00 ff fe 20 39  d8 01 01 c4 b2 5b 9b d4 |..@... 9 .....[..
                                 5a                                               |Z

UDP Link-Local:

uart:~$ net udp send fe80::8c88:2bff:fe20:39d8 2222 "test"
Message sent
[00:05:25.071,929] <dbg> net_ctx: net_context_bind: (shell_uart): Context 0x20005bf0 binding to UDP [::]:58176 iface 1 (0x20001898)
[00:05:25.072,052] <dbg> net_ctx: context_setup_udp_packet: (shell_uart): context_setup_udp_packet
[00:05:25.072,235] <dbg> net_ipv6: check_route: (shell_uart): Router 0x20005a98 nexthop fe80::8c88:2bff:fe20:39d8
[00:05:25.072,296] <dbg> net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor lookup 0x20000ab8 (0) iface 0x20001898/1 addr fe80::8c88:2bff:fe20:39d8 state static
[00:05:25.072,326] <dbg> net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor 0x20000ab8 addr 8C:88:2B:20:39:D8
[00:05:25.072,357] <dbg> net_if: net_if_tx: (shell_uart): Processing (pkt 0x20010710, prio 1) network packet iface 0x20001898/1
[00:05:25.072,387] <dbg> net_if: net_if_tx: (shell_uart): NET_IF_UP
[00:05:25.072,509] <err> net_bt: l2cap payload
                                 66 3a 66 65 32 30 3a 33  39 64 38 00 06 66 66 30 |f:fe20:3 9d8..ff0
                                 32 3a 3a                                         |2:: 

[00:05:25.072,570] <dbg> net_if: net_if_tx: (shell_uart): Calling context send cb 0x20005bf0 status 13
[00:05:25.073,059] <dbg> net_ctx: net_context_unref: (shell_uart): Context 0x20005bf0 released

TCP:

uart:~$ net tcp send "test"
Message sent
[00:11:53.549,865] <dbg> net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor lookup 0x20000b0c (0) iface 0x20001898/1 addr 2001:db8::8c88:2bff:fe20:39d8 state reachable
[00:11:53.549,926] <dbg> net_ipv6: net_ipv6_prepare_for_send: (shell_uart): Neighbor 0x20000b0c addr 8C:88:2B:20:39:D8
[00:11:53.549,957] <dbg> net_if: net_if_tx: (shell_uart): Processing (pkt 0x200105f0, prio 1) network packet iface 0x20001898/1
[00:11:53.550,262] <err> net_bt: l2cap payload
                                 69 87 05 00 07 02 00 00  59 82 05 00 e0 83 05 00 |i....... Y.......
                                 dd 25 00                                         |.%.

I also attach here some Wireshark screenshots for the UDP Link-Local and TCP packets UDP LL: udp TCP: tcp

jmrua commented 1 year ago

Hello @jori-nordic, are you able to extract meaningful information from the message above?

jori-nordic commented 1 year ago

Not really. I don't think the issue is in l2cap though, but I will try to reproduce it locally just in case. What strikes me as odd is that for the first two samples (udp ll / global), only the LL seems to have the IP in the payload.

edit: seems IPSP is really broken, so I won't investigate this any further. The interface doesn't even start up properly on the board, I get a timeout straight away. @jmrua If you want to step up, we are currently looking for maintainers, as this feature is not maintained or tested at all.

PS. log from init:

[00:00:00.386,138] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.386,169] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
[00:00:00.386,199] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 3.2 Build 99
[00:00:00.387,207] <inf> bt_hci_core: bt_dev_show_info: Identity: D7:99:F8:2D:DD:50 (random)
[00:00:00.387,237] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1
[00:00:00.387,268] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0xffff
[00:00:00.387,817] <inf> net_config: net_config_init_by_iface: Initializing network
[00:00:00.387,817] <inf> net_config: check_interface: Waiting interface 1 (0x20001860) to be up...
[00:00:30.388,488] <err> net_config: net_config_init_by_iface: Timeout while waiting network interface
[00:00:30.388,519] <err> net_config: net_config_init_app: Network initialization failed (-115)
[00:00:30.388,549] <inf> ipsp: init_app: Run IPSP sample
[00:00:30.388,702] <dbg> net_if: net_if_ipv6_addr_add: (main): [0] interface 0x20001860 address 2001:db8::1 type MANUAL added
[00:00:30.388,793] <dbg> net_if: net_if_ipv6_maddr_add: (main): [0] interface 0x20001860 address ff02::1 added
[00:00:30.389,007] <dbg> net_if: net_if_tx: (main): Processing (pkt 0x2000f678, prio 1) network packet iface 0x20001860/1
[00:00:30.389,038] <dbg> net_6lo: compress_da_mcast: (main): M_1 dst is mcast
[00:00:30.389,068] <dbg> net_6lo: compress_da_mcast: (main): DAM_11 dst maddr 8 bit compressible
[00:00:30.389,099] <dbg> net_6lo: compress_IPHC_header: (main): SAM_00, SAC_1 unspecified src address
[00:00:30.389,129] <dbg> net_6lo: compress_hoplimit: (main): HLIM compressed (1)
[00:00:30.389,160] <dbg> net_6lo: compress_tfl: (main): Traffic class and Flow label elided
[00:00:30.389,190] <err> net_bt: net_bt_send: Unable to send packet: -128
[00:00:30.389,282] <dbg> net_if: net_if_ipv6_maddr_add: (main): [1] interface 0x20001860 address ff02::1:ff00:1 added
[00:00:30.389,526] <dbg> net_if: net_if_tx: (main): Processing (pkt 0x2000f678, prio 1) network packet iface 0x20001860/1
[00:00:30.389,556] <dbg> net_6lo: compress_da_mcast: (main): M_1 dst is mcast
[00:00:30.389,587] <dbg> net_6lo: compress_da_mcast: (main): DAM_11 dst maddr 8 bit compressible
[00:00:30.389,617] <dbg> net_6lo: compress_IPHC_header: (main): SAM_00, SAC_1 unspecified src address
[00:00:30.389,648] <dbg> net_6lo: compress_hoplimit: (main): HLIM compressed (1)
[00:00:30.389,678] <dbg> net_6lo: compress_tfl: (main): Traffic class and Flow label elided
[00:00:30.389,678] <err> net_bt: net_bt_send: Unable to send packet: -128
[00:00:30.389,801] <dbg> net_if: net_if_ipv6_start_dad: (main): Interface 0x20001860 is down, starting DAD for 2001:db8::1 later.
[00:00:30.390,258] <inf> ipsp: listen: Starting to wait
jmrua commented 1 year ago

@jori-nordic Thank you for your answer, as I have a special interest in this technology I will be trying to correct that behavior even though there is no maintainer in this feature. As far as I can I will try to contribute to the development of this feature.

rlubos commented 1 year ago

@jori-nordic The network interface was not brought up at boot, I've sent a PR to fix that: https://github.com/zephyrproject-rtos/zephyr/pull/52934.

@jmrua I couldn't really reproduce the issue on current main (with #52934), UDP packets transfer in both ways correctly with global address (Kernel version 5.10). Did you try with current main branch?

jmrua commented 1 year ago

@rlubos Thank you for answering, I have upgraded my branch to master branch and I had the problem @jori-nordic reported above and using your PR seems to fix this. (Before I was testing with the last GitHub release and I didn't have connection issues) But I'm having the same issue with the UDP packets in #52934. UDP global packets are not received in the PC. I have done some pcapng captures on TCP, UDP and ICMP. TCP and ICMP work as expected, these are just for comparison. In the case of UDP link-local and global, I also attach a L2CAP capture, as for UDP global, there isn't any meaningful data in bt0 IP interface capture.

test-ipsp-udp.zip

rlubos commented 1 year ago

I'm afraid that I'm not able to help beyond #52934, I'm not well acquainted with BLE IPSP internals, especially given that I could not reproduce the issue on my end. Therefore, stepping down from the assignee role.

laurenmurphyx64 commented 1 year ago

@carlescufi Just assigning you to help figure out who to pass this to

jmrua commented 1 year ago

Hello everyone, after analyzing the packets in my previous message, I think I have located the problem in the connection. The main difference between both Wireshark captures is that in the case of UDP LL the header is compressed, so the packet is considerably smaller, but in the case that global IPs are used the packet is not compressed, the IP packet is sent uncompressed and unmodified through the L2CAP channel.

If we analyze the syslog of the host computer, the following message appears each time a UDP packet from the board arrives: received unknown nhc id which was not found

From Linux 6LoWPAN next header compression.

What seems to be happening is that the host is waiting for the compressed packet to arrive in the format defined in RFC 6282 and the nRF board is sending it as a flat IPv6 packet through the L2CAP channel, so the expected headers(LOWPAN_NHC format) are not there. So the host is reading data that does not make sense and is not able to retrieve the original IP packet.

In view of RFC 7668, which indicates that IPv6 header compression must be performed (“Per this specification, the IPv6 header compression format specified in [RFC 6282] MUST be used.”)

It appears that this compression and header appending is not being performed for UDP traffic with global IPs in the verions and yet it is being performed correctly for UDP Link Local traffic.

irgendwie commented 1 year ago

We were able to reproduce this issue on some of our nRF5340DK boards. While most of them work correctly, some don't. They show the exact same behavior as described in this issue.

jori-nordic commented 1 year ago

@rlubos doesn't the last message from @jmrua mean that it's actually the zephyr network layer that's buggy in this case?

rlubos commented 1 year ago

he host is waiting for the compressed packet to arrive in the format defined in RFC 6282 and the nRF board is sending it as a flat I

Yes, it could indicate some issue with 6lowpan IPHC, although I'm no really expert in this area to comment further.

bamkrs commented 1 year ago

'm currently onto this, too. The UDP packet is correctly routed through 6lo.c:compress_nh_udp which can not compress ports and inlines them (6lo.c:673). The inline_ptr_udp also points to seemingly good looking buffer.

github-actions[bot] commented 1 year ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

github-actions[bot] commented 1 year ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.