Date   

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)

Steve Brown
 

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)

Jie Zhou <zhoujie@...>
 

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 

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.
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.

Can't thank you guys enough for the help,
Jie

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:
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)

Jie Zhou <zhoujie@...>
 

Hi Johan,

Thanks for the clarification, below is my scan_adv output from the most recent master branch.
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.

Can't thank you guys enough for the help,
Jie

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

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

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!

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)

Jie Zhou <zhoujie@...>
 

Still have the same issue where MAC address changes every time.
Inline image 1
I'm in version zephyr 1.9.1

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!

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



SysTick interrupt priority on ARM

Piotr Mienkowski
 

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


Re: Setup In Eclipse

Puzdrowski, Andrzej
 

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.

-----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)

Jie Zhou <zhoujie@...>
 

I see, I am using zephyr version 1.8.0. I will get back to you guys. Thanks everyone!

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)

Jie Zhou <zhoujie@...>
 

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.

Inline image 1

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

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)

Jie Zhou <zhoujie@...>
 

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


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

 

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

 



Regards,

Anas Nashif 


Begin forwarded message:

From: <scan-admin@...>
Date: October 26, 2017 at 14:29:08 GMT+2
To: <anas.nashif@...>
Subject: 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)

Paul Sokolovsky
 

Hello,

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/4402
got 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/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Setup In Eclipse

Piotr Mienkowski
 

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)

Tomasz Bursztyka
 

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