Re: MBUF behaviour

[Christopher Collins]

Hi Aditya,

On Sat, Apr 07, 2018 at 07:59:44AM +0530, Aditya Xavier wrote:
> Hi Christopher,
> 
> That is the expected behaviour, however if you try running the sample app I 
> gave you would notice the following 
> After step 11, I.e initialise the os_mbuf by doing a os_mbuf_get from a 
> mempool, the new value is overwritten on the previous value.
> 
> I.e
> 1. Accessing the mbuf after doing a free chain, om_data still holds the value.
> 2. Initialising it again by doing a os_mbuf_get is not getting me a clean 
> mbuf, rather it holds the previous value and om_mbuf_copyinto merely 
> overwrites it. So incase the new string length is smaller, om_data would 
> return wrong value.
> 
> Am sorry if am not able to explain it properly however I would appreciate it 
> if you can test the app once.

I ran your app, and I see nothing unusual in the output.  Here is what I
get:

(gdb) r
Starting program:

/mnt/data2/work/micosa/repos/mynewt-core/bin/targets/blinky-sim/app/apps/blinky/blinky.elf
uart0 at /dev/pts/16
UART MBUF Created 1 to 1
Received Value :- abc
Received Length :- 3
Value after Reinit :- abc
Length after Reinit :- 0
Received Value :- hello
Received Length :- 5
Value after Reinit :- hello
Length after Reinit :- 0
Received Value :- gagao
Received Length :- 4
Value after Reinit :- gagao
Length after Reinit :- 0

To get this output, I typed the following strings into the console:

abc
hello
gaga

If I understand correctly, your concern is the following part of the
output:

Received Value :- gagao
Received Length :- 4
Value after Reinit :- gagao
Length after Reinit :- 0

Specifically, you are unsure why:

* The first line contains "gagao" rather than "gaga".
* The third line contains "gagao" rather than "".

Your program uses the `%s` format specifier to print the contents of an
mbuf.  This is probably not what you want, for a number of reasons:

* Mbuf contents are not typically null-terminated.
* Mbuf contents are not guaranteed to be contiguous (i.e., multiple
  bufers may be chained).

Here is a reliable, if inefficient, way to print an mbuf as a string:

static void
print_mbuf(const struct os_mbuf *om)
{
int i;

for (; om != NULL; om = SLIST_NEXT(om, om_next)) {
for (i = 0; i < om->om_len; i++) {
putchar(om->om_data[i]);
}
}
}

If you are sure the mbuf is not chained, then you don't need the outer
loop.

Chris

Re: MBUF behaviour

[Aditya Xavier]

Hi Christopher,

That is the expected behaviour, however if you try running the sample app I 
gave you would notice the following 
After step 11, I.e initialise the os_mbuf by doing a os_mbuf_get from a 
mempool, the new value is overwritten on the previous value.

I.e
1. Accessing the mbuf after doing a free chain, om_data still holds the value.
2. Initialising it again by doing a os_mbuf_get is not getting me a clean mbuf, 
rather it holds the previous value and om_mbuf_copyinto merely overwrites it. 
So incase the new string length is smaller, om_data would return wrong value.

Am sorry if am not able to explain it properly however I would appreciate it if 
you can test the app once.

Thanks,
Aditya Xavier 

> On 07-Apr-2018, at 7:32 AM, Christopher Collins  wrote:
> 
> Hi Aditya,
> 
>> On Fri, Apr 06, 2018 at 07:36:41PM +0530, Aditya Xavier wrote:
>> Hi Mynewt Team,
>> 
>> Please help me understand the behavior of MBUF.
>> 
>> PFB the steps I did :-
>> 
>> 1.os_mempool_init
>> 2.os_mbuf_pool_init
>> 3.Initialized a os_mbuf by os_mbuf_get
>> 4.Triggered Console Reader.
>> 5.os_mbuf_copyinto the console_buf into the os_mbuf
>> 6.Did a eventq_put to get into a event callback.
>> 7.Read os_mbuf value & os_mbuf len
>> 8.os_mbuf_free_chain
>> 9.Read os_mbuf value & os_mbuf len
>> 10.Initialized a os_mbuf by os_mbuf_get
>> 11.Repeat step 4 onwards.
>> 
>> Problem :-
>> In step 7, I read the previous string, however the length is correct.
>> In step 9, I read the previous string, however the length is 0.
> 
> `os_mbuf_free_chain` frees the mbuf chain back to its source pool.  From
> that point, accessing the mbuf via this pointer is an error.
> 
> This is analogous to the following example:
> 
>int *x = malloc(sizeof(*x));
>*x = 99;
>free(x);
>printf("*x = %d\n", *x);
> 
> In other words, don't access something after you free it! :)  You'll
> need to allocate a new mbuf if you need one after freeing the first.
> 
> Chris

Re: MBUF behaviour

[Christopher Collins]

Hi Aditya,

On Fri, Apr 06, 2018 at 07:36:41PM +0530, Aditya Xavier wrote:
> Hi Mynewt Team,
> 
> Please help me understand the behavior of MBUF.
> 
> PFB the steps I did :-
> 
> 1.os_mempool_init
> 2.os_mbuf_pool_init
> 3.Initialized a os_mbuf by os_mbuf_get
> 4.Triggered Console Reader.
> 5.os_mbuf_copyinto the console_buf into the os_mbuf
> 6.Did a eventq_put to get into a event callback.
> 7.Read os_mbuf value & os_mbuf len
> 8.os_mbuf_free_chain
> 9.Read os_mbuf value & os_mbuf len
> 10.   Initialized a os_mbuf by os_mbuf_get
> 11.   Repeat step 4 onwards.
> 
> Problem :-
> In step 7, I read the previous string, however the length is correct.
> In step 9, I read the previous string, however the length is 0.

`os_mbuf_free_chain` frees the mbuf chain back to its source pool.  From
that point, accessing the mbuf via this pointer is an error.

This is analogous to the following example:

int *x = malloc(sizeof(*x));
*x = 99;
free(x);
printf("*x = %d\n", *x);

In other words, don't access something after you free it! :)  You'll
need to allocate a new mbuf if you need one after freeing the first.

Chris

Re: [RFC] Mesh uses multi advertising instances.

[Michał Narajowski]

Hi Aditya,

Mesh is using Adv extensions under the hood if you have Łukasz's patch
and enable BLE_EXT_ADV and set BLE_MULTI_ADV_INSTANCES to at least 1.
Blemesh_shell has a command "init" which initializes mesh stack and
starts advertising Unprovisioned Mesh Beacon.

I tested this now and I noticed a bug. Here is a patch for that bug:
https://pastebin.com/gbyX8H56
Please apply it on top of Łukasz's branch.

Hope that helps. Let us know how it works for you.

BR,
Michał

2018-04-06 11:09 GMT+02:00 Aditya Xavier :
> Hi Michał / Łukasz,
>
> I have been trying to understand the blemesh_shell, and I fail to understand 
> how / where it is using the Advertisement extensions.
>
> Basically, could you point me towards the difference if I need to implement, 
> in order to use blemesh instead.
>
> From what I gathered / understood after going through the code is that 
> blemesh_shell basically allows various functions to be triggered through 
> shell commands.
>
> Thanks,
> Aditya Xavier.
>
>
>> On 03-Apr-2018, at 3:54 PM, Michał Narajowski 
>>  wrote:
>>
>> Hi Aditya,
>>
>> Please set BLE_MESH: 1 and BLE_MESH_SHELL: 1 and you should be able to
>> use both btshell and mesh shell. Let us know how that works for you.
>>
>> Best regards
>> Michał
>>
>> 2018-04-03 7:56 GMT+02:00 Aditya Xavier :
>>> Hi Łukasz,
>>>
>>> Any pointers, as to what needs to be implemented from the blemesh_shell app 
>>> ?
>>>
>>>
>>> Thanks,
>>> Aditya Xavier.
>>>
 On 02-Apr-2018, at 11:34 PM, Łukasz Rymanowski 
  wrote:

 Second thought

 Aditya,
 Since I did not test it a lot, would it be possible to give us feedback how
 it works for you?

 Best
 Lukasz




 On Mon, Apr 2, 2018, 20:01 Łukasz Rymanowski 
 
 wrote:

> Hi Aditya.
>
> On Mon, Apr 2, 2018, 19:14 Aditya Xavier  wrote:
>
>> Hi Łukasz,
>>
>> Is there anything special required to get this working along with BLE ?
>
>
>> For e.g. would the btshell app code for ADV_EXT work along with mesh with
>> the provided patches ?
>>
>
> In addition to configuration mentioned in PR commit message, the btshell
> app would have to enable ble mesh and ble mesh shell (check blemesh_shell
> app for that)
>
>>
>> Mesh and BLE seems to compile however, am currently unable to get Mesh
>> working.
>>
>> Also, any reason why this was not accepted yet ?
>>
>
> People are busy with other stuff I guess. I think it will be merged
> eventually.
>
>>
>>
>>
>> Thanks,
>> Aditya Xavier.
>>
>
> Best
> Lukasz
>
>
>>
>>> On 20-Mar-2018, at 12:57 AM, Sterling Hughes <
>> sterling.hughes.pub...@gmail.com> wrote:
>>>
>>> +1 - this is great, thanks Lukasz!
>>>
>>> On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote:
>>>
 Hi All,

 I saw people asking around about possibility to advertise with non-mesh
 data while mesh is running on Mynewt.  Well this is possible to do but
>> of
 course it brings a lot of risk for mesh operations and especially for
 friendship scenario. However I went ahead and added support for this in
 Mynewt and I'm interested in how it works for you.

 So here is a PR which makes use of multi instances from BT5 Advertising
 extensions and basically allows you to create additional instances
>> which
 contains non-mesh data.

 https://github.com/apache/mynewt-nimble/pull/8

 Instructions on how to enable it you can find in the commit message.

 Comments are welcome

 Best
 Łukasz
>>
>>
>>>
>

Re: [RFC] Mesh uses multi advertising instances.

[Aditya Xavier]

Hi Michał / Łukasz,

I have been trying to understand the blemesh_shell, and I fail to understand 
how / where it is using the Advertisement extensions.

Basically, could you point me towards the difference if I need to implement, in 
order to use blemesh instead.

From what I gathered / understood after going through the code is that 
blemesh_shell basically allows various functions to be triggered through shell 
commands.

Thanks,
Aditya Xavier.


> On 03-Apr-2018, at 3:54 PM, Michał Narajowski  
> wrote:
> 
> Hi Aditya,
> 
> Please set BLE_MESH: 1 and BLE_MESH_SHELL: 1 and you should be able to
> use both btshell and mesh shell. Let us know how that works for you.
> 
> Best regards
> Michał
> 
> 2018-04-03 7:56 GMT+02:00 Aditya Xavier :
>> Hi Łukasz,
>> 
>> Any pointers, as to what needs to be implemented from the blemesh_shell app ?
>> 
>> 
>> Thanks,
>> Aditya Xavier.
>> 
>>> On 02-Apr-2018, at 11:34 PM, Łukasz Rymanowski 
>>>  wrote:
>>> 
>>> Second thought
>>> 
>>> Aditya,
>>> Since I did not test it a lot, would it be possible to give us feedback how
>>> it works for you?
>>> 
>>> Best
>>> Lukasz
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Apr 2, 2018, 20:01 Łukasz Rymanowski 
>>> wrote:
>>> 
 Hi Aditya.
 
 On Mon, Apr 2, 2018, 19:14 Aditya Xavier  wrote:
 
> Hi Łukasz,
> 
> Is there anything special required to get this working along with BLE ?
 
 
> For e.g. would the btshell app code for ADV_EXT work along with mesh with
> the provided patches ?
> 
 
 In addition to configuration mentioned in PR commit message, the btshell
 app would have to enable ble mesh and ble mesh shell (check blemesh_shell
 app for that)
 
> 
> Mesh and BLE seems to compile however, am currently unable to get Mesh
> working.
> 
> Also, any reason why this was not accepted yet ?
> 
 
 People are busy with other stuff I guess. I think it will be merged
 eventually.
 
> 
> 
> 
> Thanks,
> Aditya Xavier.
> 
 
 Best
 Lukasz
 
 
> 
>> On 20-Mar-2018, at 12:57 AM, Sterling Hughes <
> sterling.hughes.pub...@gmail.com> wrote:
>> 
>> +1 - this is great, thanks Lukasz!
>> 
>> On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote:
>> 
>>> Hi All,
>>> 
>>> I saw people asking around about possibility to advertise with non-mesh
>>> data while mesh is running on Mynewt.  Well this is possible to do but
> of
>>> course it brings a lot of risk for mesh operations and especially for
>>> friendship scenario. However I went ahead and added support for this in
>>> Mynewt and I'm interested in how it works for you.
>>> 
>>> So here is a PR which makes use of multi instances from BT5 Advertising
>>> extensions and basically allows you to create additional instances
> which
>>> contains non-mesh data.
>>> 
>>> https://github.com/apache/mynewt-nimble/pull/8
>>> 
>>> Instructions on how to enable it you can find in the commit message.
>>> 
>>> Comments are welcome
>>> 
>>> Best
>>> Łukasz
> 
> 
>>