Re: Bluetooth mesh - Missing ack for subscription get (8029)

Johan Hedberg
Hi Steve, On Mon, Oct 30, 2017, Steve Brown wrote: According to Mesh Profile 4.3.2.27, this is an acknowledged message.
The implementation in cfg.c:mod_sub_get doesn't seem to send the ack, just the subscription list.
Ditto for subscription get vendor (4.3.2.29)
If somebody familiar with the code can confirm this, I'll put together a PR. Isn't the "ack" in this case precisely the subscription list that's sent as a response? What else could it be? E.g. transport layer acks are separate from anything that happens on the model layer. From section 4.4.1.2.8: "When an element receives a Config SIG Model Subscription Get message that is processed successfully (i.e., it does not result in any error conditions listed in Table 4.113), it shall respond with a Config SIG Model Subscription List message with the current values of the identified Subscription List state, setting the ElementAddress and ModelIdentifier fields as defined by the incoming message and setting the Status field to Success." So I don't see anything missing from the current implementation. Are you getting some PTS test case failures because of this, or your concern is just based on interpreting the spec and current code? Johan
|
|
Bluetooth mesh - Missing ack for subscription get (8029)
According to Mesh Profile 4.3.2.27, this is an acknowledged message.
The implementation in cfg.c:mod_sub_get doesn't seem to send the ack, just the subscription list.
Ditto for subscription get vendor (4.3.2.29)
If somebody familiar with the code can confirm this, I'll put together a PR.
Steve
|
|
Re: Bluetooth Address Type - Fixed (public)
Hi Johan,
Works like a charm. Haha, completely forgot about having to flash the BLE core with hci_uart. My firmware was still at 1.8.0. Thanks Johan and Vinayak, you guys are the best!
Thanks, Jie
toggle quoted message
Show quoted text
On Fri, Oct 27, 2017 at 10:51 PM, Jie Zhou <zhoujie@...> wrote: Hi Johan,
Thanks for the clarification, below is my scan_adv output from the most recent master branch.  MAC address still changes. I can see there are three warnings causing it to default into temporary static random address. The Vendor HCI extension is not available, I'm guessing this is referring to the HCI commands for the curie chip (arduino_101/tinytile) is not available. Is there an vendor HCI extension for the arduino_101 that I can include in zephyr? I'm using make BOARD=arduino_101 flash for the tinyTILE. The other option would be like what Vinayak is doing - running a combine built to read from the registers directly. I would like to not have to erase factory data and risk losing some capabilities of the board. Can't thank you guys enough for the help, Jie
|
|
Re: Bluetooth Address Type - Fixed (public)

Johan Hedberg
Hi Jie, On Fri, Oct 27, 2017, Jie Zhou wrote: Thanks for the clarification, below is my scan_adv output from the most recent master branch. [image: Inline image 1]
MAC address still changes. I can see there are three warnings causing it to default into temporary static random address. The Vendor HCI extension is not available, I'm guessing this is referring to the HCI commands for the curie chip (arduino_101/tinytile) is not available. Is there an vendor HCI extension for the arduino_101 that I can include in zephyr? I'm using make BOARD=arduino_101 flash for the tinyTILE. The other option would be like what Vinayak is doing - running a combine built to read from the registers directly. I would like to not have to erase factory data and risk losing some capabilities of the board. You still need to update the nRF51 on the tinyTILE with a new hci_uart application based on latest master branch. You're now getting errors because the controller-side firmware doesn't yet have the vendor extensions. Johan
|
|
Re: Bluetooth Address Type - Fixed (public)
Hi Johan,
Thanks for the clarification, below is my scan_adv output from the most recent master branch.  MAC address still changes. I can see there are three warnings causing it to default into temporary static random address. The Vendor HCI extension is not available, I'm guessing this is referring to the HCI commands for the curie chip (arduino_101/tinytile) is not available. Is there an vendor HCI extension for the arduino_101 that I can include in zephyr? I'm using make BOARD=arduino_101 flash for the tinyTILE. The other option would be like what Vinayak is doing - running a combine built to read from the registers directly. I would like to not have to erase factory data and risk losing some capabilities of the board. Can't thank you guys enough for the help, Jie
toggle quoted message
Show quoted text
On Fri, Oct 27, 2017 at 9:58 PM, Johan Hedberg <johan.hedberg@...> wrote: Hi Jie,
On Fri, Oct 27, 2017, Jie Zhou wrote:
> Still have the same issue where MAC address changes every time.
> [image: Inline image 1]
> I'm in version zephyr 1.9.1
You need to use the master branch as I suggested. Not 1.9.1. I don't
think the necessary patches are part of any release yet. I think this
worked for Vinayak because with a combined build the host reads the
values directly from the registers instead of using HCI.
Johan
|
|
Re: Bluetooth Address Type - Fixed (public)

Johan Hedberg
Hi Jie, On Fri, Oct 27, 2017, Jie Zhou wrote: Still have the same issue where MAC address changes every time. [image: Inline image 1] I'm in version zephyr 1.9.1 You need to use the master branch as I suggested. Not 1.9.1. I don't think the necessary patches are part of any release yet. I think this worked for Vinayak because with a combined build the host reads the values directly from the registers instead of using HCI. Johan
|
|
Re: Bluetooth Address Type - Fixed (public)
Chettimada, Vinayak Kariappa
Hi Jie,
I have tested both on upstream master and v1.9.1 (on a nRF52 though), and my boards use the same identity address as assigned by the factory and used by the Zephyr Host.
I am afraid you may have erased the factory data on your board, which means the chip will not meet its full functional behaviour.
These factory data are unique for each chip, I advise you not to use such boards that miss factory data.
With the upstream master:
Starting Scanner/Advertiser Demo
[2017-10-28 06:56:23.121] [bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[2017-10-28 06:56:23.127] [bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[2017-10-28 06:56:23.131] [bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.9 Build 99
[2017-10-28 06:56:23.140] [bt] [INF] show_dev_info: Identity: ef:0f:a3:d8:8f:24 (random)
[2017-10-28 06:56:23.145] [bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[2017-10-28 06:56:23.153] [bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[2017-10-28 06:56:23.158] Bluetooth initialized
[2017-10-28 06:56:36.547] Starting Scanner/Advertiser Demo
[2017-10-28 06:56:36.551] [bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[2017-10-28 06:56:36.557] [bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[2017-10-28 06:56:36.561] [bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.9 Build 99
[2017-10-28 06:56:36.570] [bt] [INF] show_dev_info: Identity: ef:0f:a3:d8:8f:24 (random)
[2017-10-28 06:56:36.575] [bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[2017-10-28 06:56:36.583] [bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[2017-10-28 06:56:36.588] Bluetooth initialized
With the v1.9.1 tag:
[2017-10-28 06:59:30.383] Starting Scanner/Advertiser Demo
[2017-10-28 06:59:30.386] [bt] [INF] show_dev_info: Identity: ef:0f:a3:d8:8f:24 (random)
[2017-10-28 06:59:30.391] [bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[2017-10-28 06:59:30.399] [bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[2017-10-28 06:59:30.405] Bluetooth initialized
[2017-10-28 06:59:42.718] Starting Scanner/Advertiser Demo
[2017-10-28 06:59:42.722] [bt] [INF] show_dev_info: Identity: ef:0f:a3:d8:8f:24 (random)
[2017-10-28 06:59:42.727] [bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[2017-10-28 06:59:42.735] [bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[2017-10-28 06:59:42.741] Bluetooth initialized
Regards,
Vinayak
toggle quoted message
Show quoted text
On 28 Oct 2017, at 04:14, Jie Zhou < zhoujie@...> wrote:
Still have the same issue where MAC address changes every time.
<image.png>
I'm in version zephyr 1.9.1
|
|
Re: Bluetooth Address Type - Fixed (public)
Still have the same issue where MAC address changes every time.
I'm in version zephyr 1.9.1
toggle quoted message
Show quoted text
On Thu, Oct 26, 2017 at 8:24 PM, Jie Zhou <zhoujie@...> wrote: I see, I am using zephyr version 1.8.0. I will get back to you guys. Thanks everyone!
|
|
SysTick interrupt priority on ARM
Hi,
Looking at the ARM architecture code it seems that the SysTick interrupt priority is currently the same as the highest priority an application/driver can get. I.e. the same as interrupt priority 0 defined by IRQ_CONNECT macro.
Is this design intentional?
I've always assumed that SysTick has higher IRQ priority than the application and it is the primary reason why we reserve 2 IRQ priority levels for the kernel.
The long version:
In my application I need to measure timing. I do it using k_cycle_get_32() function. Some of the measurements have to be done within an interrupt handler. In my case the interrupt handler is responsible for setting up continuous DMA transfer of audio data and runs at priority 0. I have noticed that some of the timing measurements are - temporarily - off by the duration of one system tick. The reason turned out to be SysTick interrupt priority. To solve the problem it's enough to set the priority of the application/driver interrupt handler to minimum 1. It feels however strange that we need to do it. Also, this SysTick behavior is currently not documented.
Regards, Piotr
|
|
Ad 2.) You might also introduce any compiler option using menuconfig: Compile and Link Features > Compiler Options > Custom compiler options. You can for example put here "-O0" for disabling any optimization (or by CONFIG_COMPILER_OPT="-O0"). If you have CONFIG_DEBUG enabled the "-Og" is already used.
toggle quoted message
Show quoted text
-----Original Message----- From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Piotr Mienkowski Sent: Thursday, October 26, 2017 4:00 PM To: zephyr-devel@... Subject: Re: [Zephyr-devel] Setup In Eclipse Hi JC, On 25.10.2017 16:05, JC wrote: I'm running Ubuntu 16.04 LTS in a Virtualbox VM. I'm using Eclipse Oxygen CDT for development and openOCD for debugging. My target is an NRF52, At this moment, I can build the code and successfully initiate debugging through eclipse.
Here's what I see that I find strange: 1. Only one thread in the debug window. 2. Unpredictable result when stepping through the code. 3. Callstack makes zero sense. 4. Breakpoints don't seem to work correctly outside of application code.
I have to think I've not configured something correctly about my debug environment. Does anyone have any ideas? One obvious thing you need to do, which nevertheless is easy to overlook, is setting Kconfig option CONFIG_DEBUG=y It disables compiler optimizations and adds debug symbols to the bin file. I'm only reminding it since you didn't mention it in your post. Not setting this option would be a typical cause for 2. and 4. Though in case of 4. the behavior shouldn't differ between application and system code. Not enabling CONFIG_DEBUG may also influence 3. Though the changes shouldn't be dramatic, callstack should still make sense. To have thread aware debugging you need to use OpenOCD from the latest Zephyr SDK version. The stock OpenOCD comes without Zephyr extensions. I actually have not tried it out yet and am not sure how well it works. I think you will also need to set CONFIG_OPENOCD_SUPPORT=y Maybe someone else knows more. Let us know how it worked and especially if you were successful enabling thread aware debugging. Regards, Piotr _______________________________________________ Zephyr-devel mailing list Zephyr-devel@... https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
Re: Bluetooth Address Type - Fixed (public)
I see, I am using zephyr version 1.8.0. I will get back to you guys. Thanks everyone!
toggle quoted message
Show quoted text
On Thu, Oct 26, 2017 at 8:14 PM, Johan Hedberg <johan.hedberg@...> wrote: Hi Jie,
On Thu, Oct 26, 2017, Jie Zhou wrote:
> CONFIG_BT_PRIVACY=n is something I already tried, and it seems to still
> advertises with a temporary random static address. Here's the output of the
> scan/advertise the addition to the conf file changes nothing.
>
> [image: Inline image 1]
>
> The MAC address changes with every reset. Thanks for the advise on the
> public MAC address.
Have you built your nRF51 and Quark SE images from the latest master
branch? If not, please do so. It contains code to properly utilize the
factory programmed static random address in the controller.
Johan
|
|
Re: Bluetooth Address Type - Fixed (public)

Johan Hedberg
Hi Jie, On Thu, Oct 26, 2017, Jie Zhou wrote: CONFIG_BT_PRIVACY=n is something I already tried, and it seems to still advertises with a temporary random static address. Here's the output of the scan/advertise the addition to the conf file changes nothing.
[image: Inline image 1]
The MAC address changes with every reset. Thanks for the advise on the public MAC address. Have you built your nRF51 and Quark SE images from the latest master branch? If not, please do so. It contains code to properly utilize the factory programmed static random address in the controller. Johan
|
|
Re: Bluetooth Address Type - Fixed (public)
Hi Vinayak,
CONFIG_BT_PRIVACY=n is something I already tried, and it seems to still advertises with a temporary random static address. Here's the output of the scan/advertise the addition to the conf file changes nothing.
The MAC address changes with every reset. Thanks for the advise on the public MAC address.
Sincerely, Jie
|
|
Re: Bluetooth Address Type - Fixed (public)
Chettimada, Vinayak Kariappa
Hi Jie,
On all supported nRF5 based boards, a constant unique factory assigned random static address will be used across power cycles of the board as the identity address. And to use only random static address on these boards in advertisement and scanning, you disable Bluetooth Privacy feature in your samples/applications prj.conf file.
CONFIG_BT_PRIVACY=n
Please do not use any public addresses, unless your company owns them (Johan has already mentioned before).
Regards, Vinayak
toggle quoted message
Show quoted text
On 27 Oct 2017, at 00:08, Jie Zhou <zhoujie@...> wrote:
Hey Johan,
Thanks for the info! My objective is to have a unique and fixed BT address displayed during advertising. I want to use the manufacturer's BT address as a static address for testing purposes, and we just want to disable the randomization feature. So there is no need for me to set a public address.
Thanks, Jie
On Thu, Oct 26, 2017 at 8:26 AM, Johan Hedberg <johan.hedberg@...> wrote: Hi Jie,
On Thu, Oct 26, 2017, Jie Zhou wrote:
Looking at the bluetooth API and the sample bluetooth code, tt seems that the default advertised address addr->type is random. I think this is because of security reasons, so it is using resolvable private addresses. Is there a way for me to change the address type to public (i.e. fixed) for my curie board? I see it in the API that there is cases for public bluetooth address. However, I just can't seem to find how to change the addr-type to public. I see the #define BT_ADDRLE_PUBLIC 0x00 in include/bluetooth/hci.h, but don't know how to implement it. Does anyone know how to do this? Usually a host stack doesn't have to do anything special with public addresses since controllers that support them come with the address pre-programmed. All you need to say is that you want to use it.
You might want to read up on the Bluetooth address types in the Bluetooth Core specification, since it seems you have the details a bit mixed up. You can find the relevant information in "Vol 6, Part B, section 1.3 Device Address". You'll see that using a random address is not necessarily for security reasons. E.g. if a device doesn't have a public address, then a static random address can act as the Identity Address (which is the case with the current Zephyr controller).
Also note that public addresses are managed by each company that the OUI in the address belongs to, so you shouldn't just go creating arbitrary public addresses and using them.
This all said, we do have an HCI vendor extension that lets the host stack set a public address to the controller (remember, the Zephyr controller starts with no public address at all). However, currently the host-side has no code for using this vendor HCI command. It should be fairly simple to add though, and I might have the time to look at it in the coming weeks.
Johan
_______________________________________________ Zephyr-devel mailing list Zephyr-devel@... https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
Re: Bluetooth Address Type - Fixed (public)
Hey Johan,
Thanks for the info! My objective is to have a unique and fixed BT address displayed during advertising. I want to use the manufacturer's BT address as a static address for testing
purposes, and we just want to disable the randomization feature. So there is no need for me to set a public address. Thanks, Jie
toggle quoted message
Show quoted text
On Thu, Oct 26, 2017 at 8:26 AM, Johan Hedberg <johan.hedberg@...> wrote: Hi Jie,
On Thu, Oct 26, 2017, Jie Zhou wrote:
> Looking at the bluetooth API and the sample bluetooth code, tt seems that
> the default advertised address addr->type is random. I think this is
> because of security reasons, so it is using resolvable private addresses.
> Is there a way for me to change the address type to public (i.e. fixed) for
> my curie board? I see it in the API that there is cases for public
> bluetooth address. However, I just can't seem to find how to change the
> addr-type to public. I see the #define BT_ADDRLE_PUBLIC 0x00 in
> include/bluetooth/hci.h, but don't know how to implement it. Does anyone
> know how to do this?
Usually a host stack doesn't have to do anything special with public
addresses since controllers that support them come with the address
pre-programmed. All you need to say is that you want to use it.
You might want to read up on the Bluetooth address types in the
Bluetooth Core specification, since it seems you have the details a bit
mixed up. You can find the relevant information in "Vol 6, Part B,
section 1.3 Device Address". You'll see that using a random address is
not necessarily for security reasons. E.g. if a device doesn't have a
public address, then a static random address can act as the Identity
Address (which is the case with the current Zephyr controller).
Also note that public addresses are managed by each company that the OUI
in the address belongs to, so you shouldn't just go creating arbitrary
public addresses and using them.
This all said, we do have an HCI vendor extension that lets the host
stack set a public address to the controller (remember, the Zephyr
controller starts with no public address at all). However, currently the
host-side has no code for using this vendor HCI command. It should be
fairly simple to add though, and I might have the time to look at it in
the coming weeks.
Johan
|
|
Re: New Defects reported by Coverity Scan for Zephyr

David Leach
Anas,
If we go into Coverity and items as a “bug” will there be some sort of automation that will generate a bug ticket in the github issues?
David
toggle quoted message
Show quoted text
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...]
On Behalf Of Nashif, Anas
Sent: Thursday, October 26, 2017 8:28 AM
To: devel@...
Subject: [Zephyr-devel] Fwd: New Defects reported by Coverity Scan for Zephyr
Hi,
Please find the latest report on new defect(s) introduced to Zephyr found with Coverity Scan.
17 new defect(s) introduced to Zephyr found with Coverity Scan.
6 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 17 of 17 defect(s)
** CID 178249: Parse warnings (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 44 in ()
________________________________________________________________________________________________________
*** CID 178249: Parse warnings (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 44 in ()
38 &app0_parts0,
39 &app0_parts1
40 };
41
42 K_MEM_PARTITION_DEFINE(app1_parts0, app1_buf, sizeof(app1_buf),
43 K_MEM_PARTITION_P_RW_U_RW);
CID 178249: Parse warnings (PARSE_ERROR)
expression must be an integral constant expression
44 K_MEM_PARTITION_DEFINE(app1_parts1, app0_buf, sizeof(app0_buf),
45 K_MEM_PARTITION_P_RW_U_RO);
46
47 struct k_mem_partition *app1_parts[] = {
48 &app1_parts0,
49 &app1_parts1
** CID 178248: Null pointer dereferences (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()
________________________________________________________________________________________________________
*** CID 178248: Null pointer dereferences (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()
1227 u16_t coap_pkt_len;
1228
1229 frag = NULL;
1230 *offset = 0xffff;
1231 *len = 0;
1232
CID 178248: Null pointer dereferences (REVERSE_INULL)
Null-checking "offset" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1233 if (!cpkt || !cpkt->pkt || !offset || !len) {
1234 return NULL;
1235 }
1236
1237 coap_pkt_len = get_coap_packet_len(cpkt->pkt);
1238
** CID 178247: Error handling issues (CHECKED_RETURN)
/subsys/net/lib/sockets/sockets.c: 111 in zsock_accepted_cb()
________________________________________________________________________________________________________
*** CID 178247: Error handling issues (CHECKED_RETURN)
/subsys/net/lib/sockets/sockets.c: 111 in zsock_accepted_cb()
105
106 static void zsock_accepted_cb(struct net_context *new_ctx,
107 struct sockaddr *addr, socklen_t addrlen,
108 int status, void *user_data) {
109 struct net_context *parent = user_data;
110
CID 178247: Error handling issues (CHECKED_RETURN)
Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
111 net_context_recv(new_ctx, zsock_received_cb, K_NO_WAIT, NULL);
112 k_fifo_init(&new_ctx->recv_q);
113
114 NET_DBG("parent=%p, ctx=%p, st=%d", parent, new_ctx, status);
115
116 k_fifo_put(&parent->accept_q, new_ctx);
** CID 178246: Error handling issues (CHECKED_RETURN)
/subsys/net/lib/app/client.c: 479 in _app_connected()
________________________________________________________________________________________________________
*** CID 178246: Error handling issues (CHECKED_RETURN)
/subsys/net/lib/app/client.c: 479 in _app_connected()
473 #if defined(CONFIG_NET_APP_TLS) || defined(CONFIG_NET_APP_DTLS)
474 if (ctx->is_tls) {
475 k_sem_give(&ctx->client.connect_wait);
476 }
477 #endif
478
CID 178246: Error handling issues (CHECKED_RETURN)
Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
479 net_context_recv(net_ctx, ctx->recv_cb, K_NO_WAIT, ctx);
480
481 #if defined(CONFIG_NET_APP_TLS) || defined(CONFIG_NET_APP_DTLS)
482 if (ctx->is_tls) {
483 /* If we have TLS connection, the connect cb is called
484 * after TLS handshakes are done.
** CID 178245: Parse warnings (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 42 in ()
________________________________________________________________________________________________________
*** CID 178245: Parse warnings (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 42 in ()
36
37 struct k_mem_partition *app0_parts[] = {
38 &app0_parts0,
39 &app0_parts1
40 };
41
CID 178245: Parse warnings (PARSE_ERROR)
expression must be an integral constant expression
42 K_MEM_PARTITION_DEFINE(app1_parts0, app1_buf, sizeof(app1_buf),
43 K_MEM_PARTITION_P_RW_U_RW);
44 K_MEM_PARTITION_DEFINE(app1_parts1, app0_buf, sizeof(app0_buf),
45 K_MEM_PARTITION_P_RW_U_RO);
46
47 struct k_mem_partition *app1_parts[] = {
** CID 178244: Error handling issues (CHECKED_RETURN)
/subsys/net/lib/http/http_server.c: 800 in accept_cb()
________________________________________________________________________________________________________
*** CID 178244: Error handling issues (CHECKED_RETURN)
/subsys/net/lib/http/http_server.c: 800 in accept_cb()
794 }
795
796 http_ctx->req.net_ctx = net_ctx;
797
798 new_client(http_ctx, net_ctx, addr);
799
CID 178244: Error handling issues (CHECKED_RETURN)
Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
800 net_context_recv(net_ctx, http_ctx->recv_cb, K_NO_WAIT, http_ctx);
801 }
802
803 static int set_net_ctx(struct http_server_ctx *http_ctx,
804 struct net_context *ctx,
805 struct sockaddr *addr,
** CID 178243: Error handling issues (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 88 in eth_enc28j60_read_reg()
________________________________________________________________________________________________________
*** CID 178243: Error handling issues (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 88 in eth_enc28j60_read_reg()
82 tx_size = 3;
83 }
84
85 tx_buf[0] = ENC28J60_SPI_RCR | (reg_addr & 0xFF);
86 tx_buf[1] = 0x0;
87
CID 178243: Error handling issues (CHECKED_RETURN)
Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
88 spi_transceive(context->spi, tx_buf, tx_size, tx_buf, tx_size);
89
90 *value = tx_buf[tx_size - 1];
91
92 k_sem_give(&context->spi_sem);
93 }
** CID 178242: Parse warnings (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 34 in ()
________________________________________________________________________________________________________
*** CID 178242: Parse warnings (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 34 in ()
28 /* the start address of the MPU region needs to align with its size */
29 u8_t __aligned(32) app0_buf[32];
30 u8_t __aligned(32) app1_buf[32];
31
32 K_MEM_PARTITION_DEFINE(app0_parts0, app0_buf, sizeof(app0_buf),
33 K_MEM_PARTITION_P_RW_U_RW);
CID 178242: Parse warnings (PARSE_ERROR)
expression must be an integral constant expression
34 K_MEM_PARTITION_DEFINE(app0_parts1, app1_buf, sizeof(app1_buf),
35 K_MEM_PARTITION_P_RW_U_RO);
36
37 struct k_mem_partition *app0_parts[] = {
38 &app0_parts0,
39 &app0_parts1
** CID 178241: (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 174 in eth_enc28j60_read_mem()
/drivers/ethernet/eth_enc28j60.c: 185 in eth_enc28j60_read_mem()
________________________________________________________________________________________________________
*** CID 178241: (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 174 in eth_enc28j60_read_mem()
168
169 k_sem_take(&context->spi_sem, K_FOREVER);
170
171 for (int i = 0; i < num_segments;
172 ++i, data_buffer += MAX_BUFFER_LENGTH) {
173 context->mem_buf[0] = ENC28J60_SPI_RBM;
CID 178241: (CHECKED_RETURN)
Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
174 spi_transceive(context->spi,
175 context->mem_buf, MAX_BUFFER_LENGTH + 1,
176 context->mem_buf, MAX_BUFFER_LENGTH + 1);
177 if (data_buffer) {
178 memcpy(data_buffer, context->mem_buf + 1,
179 MAX_BUFFER_LENGTH);
/drivers/ethernet/eth_enc28j60.c: 185 in eth_enc28j60_read_mem()
179 MAX_BUFFER_LENGTH);
180 }
181 }
182
183 if (num_remaining > 0) {
184 context->mem_buf[0] = ENC28J60_SPI_RBM;
CID 178241: (CHECKED_RETURN)
Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
185 spi_transceive(context->spi,
186 context->mem_buf, num_remaining + 1,
187 context->mem_buf, num_remaining + 1);
188 if (data_buffer) {
189 memcpy(data_buffer, context->mem_buf + 1,
190 num_remaining);
** CID 178240: Error handling issues (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 46 in eth_enc28j60_set_bank()
________________________________________________________________________________________________________
*** CID 178240: Error handling issues (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 46 in eth_enc28j60_set_bank()
40
41 k_sem_take(&context->spi_sem, K_FOREVER);
42
43 tx_buf[0] = ENC28J60_SPI_RCR | ENC28J60_REG_ECON1;
44 tx_buf[1] = 0x0;
45
CID 178240: Error handling issues (CHECKED_RETURN)
Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
46 spi_transceive(context->spi, tx_buf, 2, tx_buf, 2);
47
48 tx_buf[0] = ENC28J60_SPI_WCR | ENC28J60_REG_ECON1;
49 tx_buf[1] = (tx_buf[1] & 0xFC) | ((reg_addr >> 8) & 0x0F);
50
51 spi_write(context->spi, tx_buf, 2);
** CID 178239: (FORWARD_NULL)
/tests/net/app/src/main.c: 192 in iface_setup()
/tests/net/app/src/main.c: 202 in iface_setup()
________________________________________________________________________________________________________
*** CID 178239: (FORWARD_NULL)
/tests/net/app/src/main.c: 192 in iface_setup()
186 DBG("Cannot add IPv6 address %s\n",
187 net_sprint_ipv6_addr(&my_addr1));
188 zassert_not_null(ifaddr, "addr1");
189 }
190
191 /* For testing purposes we need to set the adddresses preferred */
CID 178239: (FORWARD_NULL)
Dereferencing null pointer "ifaddr".
192 ifaddr->addr_state = NET_ADDR_PREFERRED;
193
194 ifaddr = net_if_ipv6_addr_add(iface1, &ll_addr,
195 NET_ADDR_MANUAL, 0);
196 if (!ifaddr) {
197 DBG("Cannot add IPv6 address %s\n",
/tests/net/app/src/main.c: 202 in iface_setup()
196 if (!ifaddr) {
197 DBG("Cannot add IPv6 address %s\n",
198 net_sprint_ipv6_addr(&ll_addr));
199 zassert_not_null(ifaddr, "ll_addr");
200 }
201
CID 178239: (FORWARD_NULL)
Dereferencing null pointer "ifaddr".
202 ifaddr->addr_state = NET_ADDR_PREFERRED;
203
204 net_ipv6_addr_create(&in6addr_mcast, 0xff02, 0, 0, 0, 0, 0, 0, 0x0001);
205
206 maddr = net_if_ipv6_maddr_add(iface1, &in6addr_mcast);
207 if (!maddr) {
** CID 178238: Parse warnings (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 32 in ()
________________________________________________________________________________________________________
*** CID 178238: Parse warnings (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 32 in ()
26 struct k_mem_domain app_domain[2];
27
28 /* the start address of the MPU region needs to align with its size */
29 u8_t __aligned(32) app0_buf[32];
30 u8_t __aligned(32) app1_buf[32];
31
CID 178238: Parse warnings (PARSE_ERROR)
expression must be an integral constant expression
32 K_MEM_PARTITION_DEFINE(app0_parts0, app0_buf, sizeof(app0_buf),
33 K_MEM_PARTITION_P_RW_U_RW);
34 K_MEM_PARTITION_DEFINE(app0_parts1, app1_buf, sizeof(app1_buf),
35 K_MEM_PARTITION_P_RW_U_RO);
36
37 struct k_mem_partition *app0_parts[] = {
** CID 178237: Memory - corruptions (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 218 in _mcr20a_write_burst()
________________________________________________________________________________________________________
*** CID 178237: Memory - corruptions (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 218 in _mcr20a_write_burst()
212 spi->cmd_buf[0] = MCR20A_REG_WRITE | addr;
213 memcpy(&spi->cmd_buf[1], data_buf, len);
214 len += 1;
215 } else {
216 spi->cmd_buf[0] = MCR20A_IAR_INDEX | MCR20A_REG_WRITE;
217 spi->cmd_buf[1] = addr | MCR20A_REG_WRITE;
CID 178237: Memory - corruptions (OVERRUN)
Overrunning buffer pointed to by "&spi->cmd_buf[2]" of 12 bytes by passing it to a function which accesses it at byte offset 12 using argument "len" (which evaluates to 11). [Note: The source code implementation of the function has been
overridden by a builtin model.]
218 memcpy(&spi->cmd_buf[2], data_buf, len);
219 len += 2;
220 }
221
222 spi_slave_select(spi->dev, spi->slave);
223 retval = (spi_write(spi->dev, spi->cmd_buf, len) == 0);
** CID 178236: Memory - corruptions (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 260 in _mcr20a_read_burst()
________________________________________________________________________________________________________
*** CID 178236: Memory - corruptions (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 260 in _mcr20a_read_burst()
254 return 0;
255 }
256
257 if (dreg) {
258 memcpy(data_buf, &spi->cmd_buf[1], len - 1);
259 } else {
CID 178236: Memory - corruptions (OVERRUN)
Overrunning buffer pointed to by "&spi->cmd_buf[2]" of 12 bytes by passing it to a function which accesses it at byte offset 12 using argument "len - 2" (which evaluates to 11). [Note: The source code implementation of the function has
been overridden by a builtin model.]
260 memcpy(data_buf, &spi->cmd_buf[2], len - 2);
261 }
262
263 k_sem_give(&spi->spi_sem);
264
265 return 1;
** CID 178235: Null pointer dereferences (REVERSE_INULL)
/subsys/net/lib/dns/mdns_responder.c: 241 in send_response()
________________________________________________________________________________________________________
*** CID 178235: Null pointer dereferences (REVERSE_INULL)
/subsys/net/lib/dns/mdns_responder.c: 241 in send_response()
235
236 } else {
237 /* TODO: support also service PTRs */
238 return -EINVAL;
239 }
240
CID 178235: Null pointer dereferences (REVERSE_INULL)
Null-checking "reply" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
241 if (!reply) {
242 return -ENOMEM;
243 }
244
245 ret = net_context_sendto(reply, &dst, dst_len, NULL, K_NO_WAIT,
246 NULL, NULL);
** CID 178234: Null pointer dereferences (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()
________________________________________________________________________________________________________
*** CID 178234: Null pointer dereferences (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()
1227 u16_t coap_pkt_len;
1228
1229 frag = NULL;
1230 *offset = 0xffff;
1231 *len = 0;
1232
CID 178234: Null pointer dereferences (REVERSE_INULL)
Null-checking "len" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1233 if (!cpkt || !cpkt->pkt || !offset || !len) {
1234 return NULL;
1235 }
1236
1237 coap_pkt_len = get_coap_packet_len(cpkt->pkt);
1238
** CID 178233: Null pointer dereferences (REVERSE_INULL)
/samples/net/echo_client/src/tcp.c: 194 in compare_tcp_data()
________________________________________________________________________________________________________
*** CID 178233: Null pointer dereferences (REVERSE_INULL)
/samples/net/echo_client/src/tcp.c: 194 in compare_tcp_data()
188 * length is directly the fragment len.
189 */
190 len = frag->len - (ptr - frag->data);
191
192 start = lorem_ipsum + received_len;
193
CID 178233: Null pointer dereferences (REVERSE_INULL)
Null-checking "frag" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
194 while (frag) {
195 if (memcmp(ptr, start + pos, len)) {
196 NET_DBG("Invalid data received");
197 return false;
198 }
199
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit,
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbO5jMuM3qcdgkQ-2B8GeSLDbY-2BGxhHXRVXXhN9J-2FGl-2FrBg-3D-3D_qb0Uj4AheYo18oR3ufs7U2EqDpE-2BCuzW5lXxy9dw9-2BCYGJAjGVBvdMSEIXid9MGVLnYaCxQWNCEO6x0llsKktGNllYqBFTSj2s3BUW8QUrdvl233u8LuFGWpOgSu2rc-2BvqdYiOVm0hPLHncFd4V-2F9JHMSM1BZTFpzNZeXoef3wWEMVzKSvGT6UGq3Ro61uQfOZk28XrY3pDBluqFe6LAeaHu5vYnVkhOARe-2BxPHSkKM-3D
To manage Coverity Scan email notifications for "anas.nashif@...", click
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4QuJ4n4mXbeIpNhS8BGwxNLHj-2BTxeFwdI3SDDdsncH-2Bz9xw1m0wMt3vy-2F0hadYzJBea4I9eUVx23T6CU82-2BIxqn54S4Kugeb6uiTfRhIn290-3D_qb0Uj4AheYo18oR3ufs7U2EqDpE-2BCuzW5lXxy9dw9-2BCYGJAjGVBvdMSEIXid9MGVJ6piO1tzXPVgJVeRiqIumtvn4xp-2FsSSqAXdL4A3zXUPunFRRDa8MYZonXqSTke1mxlt6PHAxaGm6uFhYWiI7GnJ2TrKZIQU-2Bd3wMUQD-2FpCWVJwmYlOLvhtcJ2f-2BhdG03bLQdH57Of3UzdhGrU-2B4hZzPeOMladuanpRCD-2FHbkM-2Bs-3D
|
|
Re: Bluetooth Address Type - Fixed (public)

Johan Hedberg
Hi Jie, On Thu, Oct 26, 2017, Jie Zhou wrote: Looking at the bluetooth API and the sample bluetooth code, tt seems that the default advertised address addr->type is random. I think this is because of security reasons, so it is using resolvable private addresses. Is there a way for me to change the address type to public (i.e. fixed) for my curie board? I see it in the API that there is cases for public bluetooth address. However, I just can't seem to find how to change the addr-type to public. I see the #define BT_ADDRLE_PUBLIC 0x00 in include/bluetooth/hci.h, but don't know how to implement it. Does anyone know how to do this? Usually a host stack doesn't have to do anything special with public addresses since controllers that support them come with the address pre-programmed. All you need to say is that you want to use it. You might want to read up on the Bluetooth address types in the Bluetooth Core specification, since it seems you have the details a bit mixed up. You can find the relevant information in "Vol 6, Part B, section 1.3 Device Address". You'll see that using a random address is not necessarily for security reasons. E.g. if a device doesn't have a public address, then a static random address can act as the Identity Address (which is the case with the current Zephyr controller). Also note that public addresses are managed by each company that the OUI in the address belongs to, so you shouldn't just go creating arbitrary public addresses and using them. This all said, we do have an HCI vendor extension that lets the host stack set a public address to the controller (remember, the Zephyr controller starts with no public address at all). However, currently the host-side has no code for using this vendor HCI command. It should be fairly simple to add though, and I might have the time to look at it in the coming weeks. Johan
|
|
Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)
Hello,
toggle quoted message
Show quoted text
On Wed, 11 Oct 2017 13:06:25 +0300 Jukka Rissanen <jukka.rissanen@...> wrote: [] You are unnecessarily creating this scenario about pro or against solution. I have an example application in https://github.com/zephyrproject-rtos/zephyr/pull/980 that needs to send large (several kb) file to outside world using HTTP, and I am trying so solve it efficiently. The application will not use BSD sockets. So, this thread got backlogged somehow (bumped up by Tomasz yesterday), so I decided to approach it from the other side - to look into your usecase (#980) and see how easy it would be to convert it to rely on https://github.com/zephyrproject-rtos/zephyr/pull/119 instead. Before going to that, I'd like to mention another thing which happened in the meantime: https://github.com/zephyrproject-rtos/zephyr/pull/4402got merged, which actually uses the technique proposed by me to send largish files (more than 1 network packet), and can pass a more or less non-trivial load tests (10000 iterations with Apache Bench). That's an improvement from few months ago, when it was easy to deadlock it with much less iterations. So, the solution can be called "tested and tried" now, in a sense. (There're still deadlocks happening (e.g. #4216) which we need to investigate.) Anyway, back to your https://github.com/zephyrproject-rtos/zephyr/pull/980. Specifically, I reviewed its commit https://github.com/zephyrproject-rtos/zephyr/pull/980/commits/2092924326dc59eea16eb3327a385666431c39e7#diff-1118253502f0844ef016460a07db48df"samples: net: rpl: Simple RPL border router application". Looking thru it, I got an idea why a socket sample is subject to deadlocks (#4216), while other samples maybe not. That's because they have comments like: +#if defined(CONFIG_NET_L2_BLUETOOTH) +#error "TCP connections over Bluetooth need CONFIG_NET_CONTEXT_NET_PKT_POOL "\ + "defined." +#endif /* CONFIG_NET_L2_BLUETOOTH */ Instead of investigating cause of deadlocks, they workaround it with: +#if defined(CONFIG_NET_CONTEXT_NET_PKT_POOL) +NET_PKT_TX_SLAB_DEFINE(http_srv_tx, 64); +NET_PKT_DATA_POOL_DEFINE(http_srv_data, 64); That's 8K with our default fragment size of 128 bytes. But that's actually not what's done by your sample app, it doesn't define CONFIG_NET_CONTEXT_NET_PKT_POOL. Instead it defines: +CONFIG_NET_BUF_RX_COUNT=128 +CONFIG_NET_BUF_TX_COUNT=128 That's 16KB RX and TX buffers each. So, let's summarize: Your application, with 16KB send buffer, and patch https://github.com/zephyrproject-rtos/zephyr/pull/1330, can send files of several kb in size. Few simple questions: 1. What happens if your app needs to send file of 17KB? 2. What happens if there're no 16KB for send buffers, but only 1-2K? The answer is obvious: it won't work. At the same time, my proposal is all about making an API which will allow any app to send 1MB (or more) files with 1KB (or less) buffers. I agree with what you wrote - there're different ways to approach problems and many ways of implementation. But we design an embedded IP stack, and constrained by the hardware resources ("Zephyr runs in 8K"). It doesn't make sense two implement 2 solutions. We should choose the one which allows to cover more usecases with less resources. Now to remind, I started looking with the idea to see how the sample app can be converted to use short-write-and-retry approach. I found that it's not directly possible on the level of the app - due to peculiarities of HTTP API used: https://github.com/zephyrproject-rtos/zephyr/pull/980#pullrequestreview-71843524 I shared my concerns with the existing HTTP API (e.g. https://github.com/zephyrproject-rtos/zephyr/issues/3796), and concerns that its rewrite doesn't solve enough issues. But all this time, I treated matter of HTTP API exactly as "there're different ways to do it, and one way shouldn't be much worse than another". But I'm afraid, we reached a point when design of the HTTP API affects the design of IP stack, and not in the very right direction. I suggest we pause and try to rework it (HTTP API), even if from the basics, and using the ground requirements like "relying on more buffering than absolute bare minimum is a bad thing". I'm also pretty much sad to come out with such suggestion, because you have a pretty cool and useful app on your hands, and I just some useless demo which barely started to work. But I explained the problem with it - your app works, because it requires more resources than needed, and thus it won't work so well on other hardware. And as experience shows, every app so far has various problems, so by taking time to rebase it on a more generic, simpler API, we can solve many yet-to-be-exposed problems. Thanks for your consideration. [] -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Hi JC, On 25.10.2017 16:05, JC wrote: I'm running Ubuntu 16.04 LTS in a Virtualbox VM. I'm using Eclipse Oxygen CDT for development and openOCD for debugging. My target is an NRF52, At this moment, I can build the code and successfully initiate debugging through eclipse.
Here's what I see that I find strange: 1. Only one thread in the debug window. 2. Unpredictable result when stepping through the code. 3. Callstack makes zero sense. 4. Breakpoints don't seem to work correctly outside of application code.
I have to think I've not configured something correctly about my debug environment. Does anyone have any ideas? One obvious thing you need to do, which nevertheless is easy to overlook, is setting Kconfig option CONFIG_DEBUG=y It disables compiler optimizations and adds debug symbols to the bin file. I'm only reminding it since you didn't mention it in your post. Not setting this option would be a typical cause for 2. and 4. Though in case of 4. the behavior shouldn't differ between application and system code. Not enabling CONFIG_DEBUG may also influence 3. Though the changes shouldn't be dramatic, callstack should still make sense. To have thread aware debugging you need to use OpenOCD from the latest Zephyr SDK version. The stock OpenOCD comes without Zephyr extensions. I actually have not tried it out yet and am not sure how well it works. I think you will also need to set CONFIG_OPENOCD_SUPPORT=y Maybe someone else knows more. Let us know how it worked and especially if you were successful enabling thread aware debugging. Regards, Piotr
|
|
Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)
On 26/10/2017 14:37, Paul Sokolovsky wrote: Hello Tomasz,
Thanks for responding and bringing up this discussion - it got backlogged (so I'm doing homework on it in the background).
On Wed, 25 Oct 2017 18:13:18 +0200 Tomasz Bursztyka <tomasz.bursztyka@...> wrote:
Hi guys,
It was posted as https://github.com/zephyrproject-rtos/zephyr/pull/119 . Again, at that time, there was no consensus about way to solve it, so it was implemented only for BSD Sockets API.
Much later, https://github.com/zephyrproject-rtos/zephyr/pull/1330 was posted. It works in following way: it allows an application to create an oversized packet (...)
There're many more details than presented above, and the devil is definitely in details, there's no absolutely "right" solution, it's a compromise. I hope that Jukka and Tomasz, who are proponents of the second (GH-1330) approach can correct me on the benefits of it. Actually I missed the fact PR 1330 was about MTU handling. Does not sound generic enough.
In the end I don't approve both of the proposed solution. That sounds fresh, thanks ;-)
Let me explain why:
First, let's not rush on this MTU handling just yet, though it is much needed. We first need this:
-> https://github.com/zephyrproject-rtos/zephyr/issues/3283 Ack, that's good thing to do...
it will simplify a lot how packet are allocated. I haven't touched MTU stuff since I did the net_pkt move because of this feature we'll use.
I foresee a lot of possible improvements with this issue resolved: certainly MTU handling, better memory management than current frag model, but also better response against low memory ... but I don't see how it directly relates to the topic of this RFC, which is selecting paradigm to deal with the case that we have finite units of buffering, and how that should affect user-facing API design. I was indeed only responding on MTU handling (as both PR do in a way). There're definitely a lot to improve and optimize in our IP stack, and the issue you mention is one of them. But it's going to be just that - the optimization. But what we discuss is how to structure API:
1. Accept that the amount of buffering we can do is very finite, and make applications be aware of that and ready to handle - the POSIX inspired way. If done that way, we can just use a network packet as a buffering unit and further optimize that handling.
2. Keep pretending that we can buffer mini-infinite amount of data. It's mini-infinite because we still won't be able to buffer more than RAM allows (actually, more than TX slab allows), and that's still too little, so won't work for "real" amounts of data, which still will need to fall back to p.1 handling above. Packet buffers are still used for buffering, but looking at Jukka's implementation, they are used as generic data buffers, and require pretty heavy post-processing - first splitting oversized buffers into packet-friendly sizes (#1330), stuffing protocol headers in front (we already do that, and that's pretty awful and not zero-copy at all), etc. Again, all that happens with no free memory available - it was already spent to buffer that "mini-infinite" amount of data.
You also say that you don't like any of these choices. Well, there're only so many ways to do. What do you have in mind? As I am not using at all user APIs, I can't tell what would be the best. But the issue is mostly found in the API usage it seems. On socket you have one opaque type to access the network and read/write on it. The data buffer is then split in two: user has to manage his raw data in his own buffers, (and take to/from it when receiving/sending) where the actual network data (encapsulated raw data) is handled behind by socket on send/recv. Both sending/receiving logic is easy, as long as you have enough memory for user's buffer. In zephyr, both are directly found at once in net_pkt. The user does not have to create its own buffers: he just has to pick from net slabs, populate it, finalize and done. From a memory usage point of view, the later is easier and more efficient as long as the net stack is doing it well, obviously, like properly handling MTU, etc... but mostly on _tx_ only. On rx, as the data is scattered around buffer fragments, it requires the user do add logic on his side to parse the received data (the encapsulated one). Thus the net_frag_read() and derived functions. Which can be a bit complicated to grasp I guess. About the "mini-inifinite", that's up to the user to handle net_pkt_append() returned amount. A bit like send() in socket. Though the difference here if of course data still needs to be send. As I did change net_nbuf to net_pkt, my point doing it was exactly that net_pkt should represent one unique IP packet. So from that, I would say net_pkt_append() must not go over MTU. Note however that this MTU can be either HW MTU or IP based one. For instance on 15.4/6lo you don't want to limit IPv6 packets on HW MTU, but you use this IPv6 (minimum) size of 1280 bytes which in turn is fragmented through 6lo to fit in as many as necessary 15.4 frames. But if not using 6lo, it would need to use HW MTU only. (There is a possibility to handle bigger IPv6 packets through IPv6 fragmentation, I can't remember is that generates as many net_pkt as necessary, or if it does all on one which would go against net_pkt usage) As I am not working against user API, I don't have good overview on how it's supposed to work. Well, maybe my blabbering can help you guys to decide which way should be the best. Tomasz
|
|