Wi-Fi Fundamentals Lesson 3 Exercise 2 - net_zperf: setsockopt SO_BINDTODEVICE error (-2)

Hello,

After successfully building Wi-Fi Fundamentals Lesson 3, Exercise 2 under nRF Connect SDK v2.9.1 & using nRF5340-DK with nRF7002-EK, I get the net_zperf: setsockopt SO_BINDTODEVICE error (-2).

I've also repeated by building and then running the provided l3_e2_sol. I ran the perf test on two completely different networks and got the same error. 

In both cases, nRF5340DK / nRF7002-EK connected successfully to the iperf server running on the same network as the nRF device. However, the nRF device was unable to receive any packets. I suspect because of the setsockopt SO_BINDTODEVICE error.

Please review the outputs below.

[00:00:00.305,877] <inf> wifi_nrf_bus: SPIM spi@a000: freq = 8 MHz
[00:00:00.305,908] <inf> wifi_nrf_bus: SPIM spi@a000: latency = 0
[00:00:00.425,659] <inf> wifi_nrf: Management buffer offload enabled

[00:00:00.557,586] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.557,586] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:00.557,586] <inf> fs_nvs: data wra: 0, f4
*** Booting nRF Connect SDK v2.9.1-60d0d6c8d42d ***
*** Using Zephyr OS v3.7.99-ca954a6216c9 ***
[00:00:00.557,952] <inf> net_config: Initializing network
[00:00:00.557,983] <inf> net_config: Waiting interface 1 (0x20001e08) to be up...
[00:00:00.558,013] <inf> net_config: Running dhcpv4 client...
[00:00:00.558,288] <inf> Lesson3_Exercise2: Starting nrf5340dk with CPU frequency: 128 MHz
[00:00:00.558,471] <inf> wifi_supplicant: wpa_supplicant initialized
[00:00:01.533,355] <inf> wifi_mgmt_ext: Connection requested
[00:00:01.558,349] <inf> Lesson3_Exercise2: Waiting to connect to Wi-Fi
Connected
[00:00:07.383,575] <inf> net_dhcpv4: Received: 192.168.1.155
[00:00:07.383,636] <inf> net_config: IPv4 address: 192.168.1.155
[00:00:07.383,636] <inf> net_config: Lease time: 2592000 seconds
[00:00:07.383,666] <inf> net_config: Subnet: 255.255.255.0
[00:00:07.383,697] <inf> net_config: Router: 192.168.1.1
[00:00:07.383,758] <inf> Lesson3_Exercise2: Network connected
[00:00:10.383,880] <inf> Lesson3_Exercise2: IPv4 address 192.168.1.29
[00:00:10.383,880] <inf> Lesson3_Exercise2: Starting Wi-Fi throughput test: Zperf client
[00:00:10.383,911] <inf> Lesson3_Exercise2: New UDP session started
[00:00:10.384,063] <wrn> net_zperf: setsockopt SO_BINDTODEVICE error (-2)

[00:00:32.863,922] <inf> Lesson3_Exercise2: Wi-Fi throughput test: Upload completed!
[00:00:32.863,922] <inf> Lesson3_Exercise2: Upload results:
[00:00:32.863,922] <inf> Lesson3_Exercise2: 23536640 bytes in 20001 ms
[00:00:32.863,952] <inf> Lesson3_Exercise2: 22985 packets sent
[00:00:32.863,952] <inf> Lesson3_Exercise2: 82781 packets lost
[00:00:32.863,952] <inf> Lesson3_Exercise2: 0 packets received
[00:00:32.863,952] <inf> Lesson3_Exercise2: 9193 kbps throughput

iPerf server:

[ 2] local 192.168.1.29 port 5001 connected with 192.168.1.155 port 56794
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 2] 0.00-1.00 sec 577 KBytes 4.73 Mbits/sec 2.557 ms 544/1121 (49%)
[ 2] 1.00-2.00 sec 512 KBytes 4.19 Mbits/sec 2.488 ms 660/1172 (56%)
[ 2] 2.00-3.00 sec 612 KBytes 5.01 Mbits/sec 2.540 ms 536/1148 (47%)
[ 2] 3.00-4.00 sec 540 KBytes 4.42 Mbits/sec 3.276 ms 553/1093 (51%)
[ 2] 4.00-5.00 sec 620 KBytes 5.08 Mbits/sec 2.566 ms 602/1222 (49%)
[ 2] 5.00-6.00 sec 600 KBytes 4.92 Mbits/sec 2.505 ms 516/1116 (46%)
[ 2] 6.00-7.00 sec 604 KBytes 4.95 Mbits/sec 2.699 ms 559/1163 (48%)
[ 2] 7.00-8.00 sec 604 KBytes 4.95 Mbits/sec 2.481 ms 533/1137 (47%)
[ 2] 8.00-9.00 sec 597 KBytes 4.89 Mbits/sec 2.765 ms 564/1161 (49%)
[ 2] 9.00-10.00 sec 547 KBytes 4.48 Mbits/sec 2.528 ms 615/1162 (53%)
[ 2] 10.00-11.00 sec 608 KBytes 4.98 Mbits/sec 2.529 ms 554/1162 (48%)
[ 2] 11.00-12.00 sec 596 KBytes 4.88 Mbits/sec 2.671 ms 544/1140 (48%)
[ 2] 12.00-13.00 sec 596 KBytes 4.88 Mbits/sec 2.864 ms 527/1123 (47%)
[ 2] 13.00-14.00 sec 568 KBytes 4.65 Mbits/sec 2.673 ms 628/1196 (53%)
[ 2] 14.00-15.00 sec 608 KBytes 4.98 Mbits/sec 2.726 ms 534/1142 (47%)
[ 2] 15.00-16.00 sec 612 KBytes 5.01 Mbits/sec 2.562 ms 529/1141 (46%)
[ 2] 16.00-17.00 sec 512 KBytes 4.19 Mbits/sec 2.564 ms 650/1162 (56%)
[ 2] 17.00-18.00 sec 560 KBytes 4.59 Mbits/sec 2.566 ms 596/1156 (52%)
[ 2] 18.00-19.00 sec 560 KBytes 4.59 Mbits/sec 2.504 ms 589/1149 (51%)
[ 2] 19.00-20.00 sec 574 KBytes 4.70 Mbits/sec 3.580 ms 524/1098 (48%)
[ 2] 20.00-21.00 sec 0.000 Bytes 0.000 bits/sec 0.000 ms 0/0 (0%)
[ 2] 21.00-22.00 sec 0.000 Bytes 0.000 bits/sec 0.000 ms 0/0 (0%)
[ 2] 0.00-22.08 sec 11.3 MBytes 4.31 Mbits/sec 2.836 ms 11377/22985 (49%)

What would be the reason for the setsockopt error? Thank you.


Regards,
Ravi

  • Hi Ravi,

    The warning occurs when zperf tries to bind the socket to a particular network interface based on the interface name. However, it does not affect the functionality or performance and can safely be ignored. The same warning appears in the ble_coex sample as well.

    When testing with v2.9.0, I did get an error when the device tried to connect to the server before the DHCP address was bound. This will be fixed in the course code, but in the meantime, if you experience the same problem, you can add a semaphore for this that is released when the DHCP address is bound. Here is the git diff showing an example of how to implement this:

    diff --git a/v2.9.0-v2.8.0/l3/l3_e2_sol/src/main.c b/v2.9.0-v2.8.0/l3/l3_e2_sol/src/main.c
    index 1d7ce40..f1b943b 100644
    --- a/v2.9.0-v2.8.0/l3/l3_e2_sol/src/main.c
    +++ b/v2.9.0-v2.8.0/l3/l3_e2_sol/src/main.c
    @@ -25,7 +25,7 @@
     
     LOG_MODULE_REGISTER(Lesson3_Exercise2, LOG_LEVEL_INF);
     
    -#define EVENT_MASK (NET_EVENT_L4_CONNECTED | NET_EVENT_L4_DISCONNECTED)
    +#define EVENT_MASK (NET_EVENT_L4_CONNECTED | NET_EVENT_L4_DISCONNECTED | NET_EVENT_IPV4_DHCP_BOUND)
     
     /* STEP 3.1 - Define port for the zperf server */
     #define PEER_PORT 5001
    @@ -44,6 +44,20 @@ static struct sockaddr_in in4_addr_my = {
     static struct net_mgmt_event_callback mgmt_cb;
     static bool connected;
     static K_SEM_DEFINE(run_app, 0, 1);
    +static K_SEM_DEFINE(dhcp_bound, 0, 1);
    +
    +static void print_dhcp_ip(struct net_mgmt_event_callback *cb)
    +{
    +       /* Get DHCP info from struct net_if_dhcpv4 and print */
    +       const struct net_if_dhcpv4 *dhcpv4 = cb->info;
    +       const struct in_addr *addr = &dhcpv4->requested_ip;
    +       char dhcp_info[128];
    +
    +       net_addr_ntop(AF_INET, addr, dhcp_info, sizeof(dhcp_info));
    +
    +       LOG_INF("IP address: %s", dhcp_info);
    +       k_sem_give(&dhcp_bound);
    +}
     
     static void net_mgmt_event_handler(struct net_mgmt_event_callback *cb, uint32_t mgmt_event,
                                       struct net_if *iface)
    @@ -69,6 +83,10 @@ static void net_mgmt_event_handler(struct net_mgmt_event_callback *cb, uint32_t
                    k_sem_reset(&run_app);
                    return;
            }
    +       if (mgmt_event == NET_EVENT_IPV4_DHCP_BOUND) {
    +               print_dhcp_ip(cb);
    +               return;
    +       }
     }
     
     static void udp_upload_results_cb(enum zperf_status status,
    @@ -133,8 +151,8 @@ int main(void)
     
            LOG_INF("Waiting to connect to Wi-Fi");
            k_sem_take(&run_app, K_FOREVER);
    -
    -       k_sleep(K_SECONDS(3));
    +       LOG_INF("Waiting for Wi-Fi DHCP");
    +       k_sem_take(&dhcp_bound, K_SECONDS(10));
     
            /* STEP 5.1 - Initialize a struct for storing the zperf upload parameters */
            struct zperf_upload_params params;

    Regarding the reset issue, I will investigate this and get back to you early next week.

    Best regards,
    Marte

  • Hello Marte,

    Thank you for investigating the zperf issue to do with the setsockopt SO_BINDTODEVICE error.. It looks like, as per your suggestion, the addition of a semaphore that gets released when the DHCP address is bound should fix this issue. 

    Thank you for investigating the reset issue as well. Let me know if you’re able to reproduce it. I plan to look into it more tomorrow.


    Kind Regards,
    Ravi

  • Hi Ravi,

    Have you been able to reproduce the reset issue in samples in the nRF Connect SDK or only in the DevAcademy exercise? I can reproduce it in lesson 6, exercise 1, as you did, but so far, I have not been able to reproduce it in any of the SDK samples.

    Best regards,
    Marte

  • Hi Marte,

    I haven’t tried reproducing the reset issue in the other Wi-Fi  nRF Connect SDK samples but will try and let you know.



    Best Regards,
    Ravi

  • Hi Ravi,

    It seems like the RPU error is caused by the following Kconfig options set in nrf5340dk_nrf5340_cpuapp_ns.conf:

    CONFIG_TFM_SECURE_UART=n
    CONFIG_TFM_LOG_LEVEL_SILENCE=y

    If you remove them, it should work. Please try this and let me know if you are still having issues.

    I will make sure the exercises are updated to fix this issue.

    Best regards,
    Marte

Related