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

[zpm1066]

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

[zpm1066]

Hello,

By dropping the WIFI_ZPERF_RATE I was able to get dropped packets down to zero percentage on the iperf server side and no longer got the setsockopt SO_BINDTODEVICE error.

I ran some additional tests using zperf on the nRF5340DK with nRF7002EK and iperf on the peer. It looks the best I can do before the packet drop rate gets above 10%, is ~1.5-2 Mbps.

I also built & ran the "throughput" Wi-Fi sample with the "High Performance" overlay. The maximum data rate I achieved was ~2.5 Mbps. This is significantly lower than those posted using the nRF7002DK at here.

In addition to other network conditions and router, I wonder how much a factor is the QSPI (24Mhz) on the nRF7002DK compared to the 8MHz SPI on the nRF7002EK.

Does Nordic Support have any throughput results for nRF5340DK with nRF7002EK?

Running zperf on the nRF5340-DK,

uart:~$ zperf udp download 5001
UDP server started on port 5001
New session started.
End of session!
duration: 9.92 s
received packets: 1248
nb packets lost: 59
nb packets outorder: 0
jitter: 1.08 ms
rate: 1.47 Mbps
New session started.

uart:~$ 
End of session!
duration: 9.77 s
received packets: 1393
nb packets lost: 350
nb packets outorder: 0
jitter: 1.23 ms
rate: 1.67 Mbps

Above corresponded to running iperf on peer 192.168.1.29,

quark14@quark14 bgnet_source % iperf -c 192.168.1.155 -i 1 -t 10 -u -b 1500K
------------------------------------------------------------
Client connecting to 192.168.1.155, UDP port 5001
Sending 1470 byte datagrams, IPG target: 0.00 us (kalman adjust)
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.29 port 61559 connected with 192.168.1.155 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-1.00 sec 188 KBytes 1.54 Mbits/sec
[ 1] 1.00-2.00 sec 187 KBytes 1.53 Mbits/sec
[ 1] 2.00-3.00 sec 188 KBytes 1.54 Mbits/sec
[ 1] 3.00-4.00 sec 188 KBytes 1.54 Mbits/sec
[ 1] 4.00-5.00 sec 187 KBytes 1.53 Mbits/sec
[ 1] 5.00-6.00 sec 188 KBytes 1.54 Mbits/sec
[ 1] 6.00-7.00 sec 187 KBytes 1.53 Mbits/sec
[ 1] 7.00-8.00 sec 188 KBytes 1.54 Mbits/sec
[ 1] 8.00-9.00 sec 188 KBytes 1.54 Mbits/sec
[ 1] 9.00-10.00 sec 187 KBytes 1.53 Mbits/sec
[ 1] 0.00-10.01 sec 1.83 MBytes 1.54 Mbits/sec
[ 1] Sent 1309 datagrams
[ 1] Server Report:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 1] 0.00-922120.00 sec 7.00 PBytes 68.4 Gbits/sec 0.000 ms 0/0 (0%)
[ 1] 0.00-922120.00 sec 1248 datagrams received out-of-order


quark14@quark14 bgnet_source % iperf -c 192.168.1.155 -i 1 -t 10 -u -b 2000K
------------------------------------------------------------
Client connecting to 192.168.1.155, UDP port 5001
Sending 1470 byte datagrams, IPG target: 0.00 us (kalman adjust)
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.29 port 55605 connected with 192.168.1.155 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-1.00 sec 250 KBytes 2.05 Mbits/sec
[ 1] 1.00-2.00 sec 251 KBytes 2.06 Mbits/sec
[ 1] 2.00-3.00 sec 250 KBytes 2.05 Mbits/sec
[ 1] 3.00-4.00 sec 250 KBytes 2.05 Mbits/sec
[ 1] 4.00-5.00 sec 250 KBytes 2.05 Mbits/sec
[ 1] 5.00-6.00 sec 250 KBytes 2.05 Mbits/sec
[ 1] 6.00-7.00 sec 250 KBytes 2.05 Mbits/sec
[ 1] 7.00-8.00 sec 250 KBytes 2.05 Mbits/sec
[ 1] 8.00-9.00 sec 251 KBytes 2.06 Mbits/sec
[ 1] 9.00-10.00 sec 250 KBytes 2.05 Mbits/sec
[ 1] 0.00-10.01 sec 2.44 MBytes 2.05 Mbits/sec
[ 1] Sent 1745 datagrams
[ 1] Server Report:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 1] 0.00-776825.00 sec 7.81 PBytes 90.6 Gbits/sec 0.000 ms 0/0 (0%)
[ 1] 0.00-776825.00 sec 1393 datagrams received out-of-order

Regards,
Ravi

[Marte Myrvold]

Hi Ravi,

When using the nRF5340 DK with the nRF7002 EK, communication between the nRF5340 and the nRF7002 goes through SPI, while on the nRF7002 DK it is QSPI. If you look at nRF7002 product specification - Throughput, you can see that there is a big difference in throughput between QSPI and SPI.
I did a quick test on my desk to compare the nRF7002 DK with the nRF5340 DK + nRF7002 EK, and I got a throughput of 18.26 Mbps for the nRF7002 DK and 8.64 Mbps (average of 4 tests) for the nRF5340 DK + nRF7002 EK. These tests were done in the exact same test environment.

Additionally, the throughput will depend on the test environment, such as the distance between the computer running iPerf and the DK, noise from other devices, etc. As is stated in the documentation of the Throughput sample, the results listed there were obtained with a good RSSI signal in a clean environment.

Best regards,
Marte

[zpm1066]

Hi Marte,

Thank you for the additional testing with the nRF5340-DK + nRF7002-EK. I guess, I have a slow network connectivity. Anyway, I'll try again closer to the router to see what difference, if any, it makes.

Any ideas on what may be the cause of the net_zperf: setsockopt SO_BINDTODEVICE error (-2)?

Have you seen this error before? Thanks.

Kind Regards,
Ravi

[Marte Myrvold]

Hi Ravi,

I got the same error when running the DevAcademy example. I will investigate the issue and get back to you by Monday at the latest.

Best regards,
Marte

[zpm1066]

Hi Marte,

Thank you for following up on the net_zperf: setsockopt SO_BINDTODEVICE error. It's much appreciated.

There's also something else that I've observed with nRF5340-DK + nRF7002-EK when target is nrf5340dk/nrf5340/cpuapp/ns. I have not observed the issue with target cpuapp.

I got the errors below. However, if I physically disconnect the USB connection and re-connect, all is fine (as you can see below after a cold reboot). Using the RESET button on the nRF5340-DK doesn't have the same effect.

I'm looking into this issue further before I submit a separate ticket on it. In one of the tickets from last year, Support suggested it may be due to nRF7002 being a REVISION A board but I'm not sure if it applies to the nRF7002-EK PCA63556 1.0.0 shield.

Anyway, I'll investigate further. I just wanted to bring the issue to your attention in case you or your colleagues have also observed it.

After nRF5340-DK reboot using the board's RESET button: These errors occur only with  target  nrf5340dk/nrf5340/cpuapp/ns.

uart:~$ 
[00:00:00.376,831] <inf> wifi_nrf_bus: SPIM spi@a000: freq = 8 MHz
[00:00:00.376,861] <inf> wifi_nrf_bus: SPIM spi@a000: latency = 0
[00:00:00.377,227] <err> wifi_nrf_bus: Error: RPU comms test: sig failed: expected 0x42000020, got 0x0

[00:00:00.377,258] <err> wifi_nrf: zep_shim_bus_qspi_dev_add: RPU enable failed with error -1
[00:00:00.377,319] <err> wifi_nrf: nrf_wifi_bus_qspi_dev_add: nrf_wifi_osal_bus_qspi_dev_add failed
[00:00:00.377,380] <err> wifi_nrf: nrf_wifi_bal_dev_add: Bus dev_add failed
[00:00:00.377,441] <err> wifi_nrf: nrf_wifi_hal_dev_add: nrf_wifi_bal_dev_add failed
[00:00:00.377,532] <err> wifi_nrf: nrf_wifi_fmac_dev_add: nrf_wifi_hal_dev_add failed
[00:00:00.377,563] <err> wifi_nrf: nrf_wifi_fmac_dev_add_zep: nrf_wifi_fmac_dev_add failed
[00:00:00.377,563] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_dev_add_zep failed
*** Booting nRF Connect SDK v2.9.1-60d0d6c8d42d ***
*** Using Zephyr OS v3.7.99-ca954a6216c9 ***
[00:00:00.378,814] <inf> Lesson6_Exercise1: Device target: nrf5340dk/nrf5340/cpuapp/ns
[00:00:00.379,302] <inf> wifi_supplicant: wpa_supplicant initialized
[00:00:00.380,310] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:00.380,340] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:00.380,340] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:00.380,371] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:00.380,401] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:00.380,432] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:11.885,314] <inf> wifi_mgmt_ext: Connection requested
[00:00:11.885,559] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:11.886,108] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:11.886,322] <inf> Lesson6_Exercise1: Waiting to connect to Wi-Fi
[00:00:12.886,718] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:13.887,390] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:14.888,092] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:15.888,763] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:16.889,404] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:17.890,106] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:18.890,808] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:19.891,479] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:20.892,181] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:21.892,822] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:22.893,524] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:23.894,195] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:24.894,897] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:25.895,599] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:26.896,301] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:27.897,003] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:28.897,644] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:29.898,315] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:30.899,017] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
[00:00:31.899,719] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
uart:~$

After a "cold reboot", i.e. USB disconnect/re-connect: No errors and firmware works fine.

[Disconnected]
[Connected]
[00:00:00.457,183] <inf> wifi_nrf_bus: SPIM spi@a000: freq = 8 MHz
[00:00:00.457,214] <inf> wifi_nrf_bus: SPIM spi@a000: latency = 0
[00:00:00.577,178] <inf> wifi_nrf: Management buffer offload enabled

*** Booting nRF Connect SDK v2.9.1-60d0d6c8d42d ***
*** Using Zephyr OS v3.7.99-ca954a6216c9 ***
[00:00:00.704,742] <inf> Lesson6_Exercise1: Device target: nrf5340dk/nrf5340/cpuapp/ns
[00:00:00.705,261] <inf> wifi_supplicant: wpa_supplicant initialized
[00:00:12.242,950] <inf> wifi_mgmt_ext: Connection requested
[00:00:12.243,469] <inf> Lesson6_Exercise1: Waiting to connect to Wi-Fi
Connected
[00:00:17.889,129] <inf> Lesson6_Exercise1: Network connected
[00:00:17.941,741] <inf> Lesson6_Exercise1: IPv4 address of HTTP server found 18.67.39.113
[00:00:17.941,772] <inf> Lesson6_Exercise1: Connecting to rest.nordicsemi.academy:80
[00:00:17.962,707] <inf> Lesson6_Exercise1: Successfully connected to HTTP server
[00:00:17.962,707] <inf> Lesson6_Exercise1: HTTP POST request
[00:00:19.104,858] <inf> Lesson6_Exercise1: Response status: Created
[00:00:19.104,919] <inf> Lesson6_Exercise1: Successfully acquired client ID: /0c3fa436-7375-44be-b975-ea0bd57b5143
[00:00:34.036,743] <inf> Lesson6_Exercise1: Set power save: disable
[00:00:37.775,970] <inf> Lesson6_Exercise1: HTTP PUT request: 0
[00:00:38.442,871] <inf> Lesson6_Exercise1: Response status: Accepted
uart:~$ 
[Disconnected]

Thank you.


KInd Regards,
Ravi

[Marte Myrvold]

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

[zpm1066]

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

[Marte Myrvold]

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