Date   

Re: cmake error when I tried to build "mesh_shell"

Kai Ren
 

Hi Sebastian,
You're correct, after add ZEPHYR_BASE, GCCARMEMB_TOOLCHAIN_PATH and ZEPHYR_GCC_VARIANT into ~/.bash_profile, it can work on MacBook.
Thanks!

Hi Timothy,
Thank you for your help!

Regards,
Kai

-----Original Message-----
From: Bøe, Sebastian [mailto:Sebastian.Boe@nordicsemi.no]
Sent: Wednesday, November 29, 2017 5:09 PM
To: Timothy <tymoteusz.kielan@gmail.com>; Kai Ren <kren@bluetooth.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] cmake error when I tried to build "mesh_shell"

Hi Kai,

the first few lines in your error message means you are affected by this issue:

https://stackoverflow.com/questions/47081317/zephyr-cmake-error
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Timothy <tymoteusz.kielan@gmail.com>
Sent: Wednesday, 29 November 2017 9:41:29 AM
To: Kai Ren
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] cmake error when I tried to build "mesh_shell"

Hi Kai,

It looks like there are no errors on your 2nd pass.
Those are just warnings caused by CMake not finding Qt (in suitable version) and GTK libraries.
If you are not planning to build xconfig or gconfig target you can simply skip them.

This step has produced you a project build folder (called build) Now you have to do an additional step and actually build the project.

To do that use one of the following commands:
- cmake --build build
- ninja -C build
- make -C build

Tim

On 29 November 2017 at 08:36, Kai Ren <kren@bluetooth.com<mailto:kren@bluetooth.com>> wrote:
Hi there,
I had ever cmake and make "sample/Bluetooth/mesh" application today, get the corresponding hex file, I just make my MacBook laptop sleep for a while and didn't change anything, I can't build again.


MacBook-Pro-2:pca10040 renkai$ cmake -DBOARD=nrf52_pca10040 ..

CMake Error at CMakeLists.txt:1 (include):

include could not find load file:



/cmake/app/boilerplate.cmake





CMake Error at CMakeLists.txt:5 (target_sources):

Cannot specify sources for target "app" which is not built by this project.





CMake Warning (dev) in CMakeLists.txt:

No cmake_minimum_required command is present. A line of code such as



cmake_minimum_required(VERSION 3.10)



should be added at the top of the file. The version specified may be lower

if you wish to support older CMake versions for this project. For more

information run "cmake --help-policy CMP0000".

This warning is for project developers. Use -Wno-dev to suppress it.



-- Configuring incomplete, errors occurred!

See also "/Users/renkai/Documents/Work/git/zephyr/tests/bluetooth/mesh_shell/pca10040/CMakeFiles/CMakeOutput.log".

I thought there may be some errors in ./cmake folder, so I tried to rebuild it, then:
$ cd $ZEPHYR_BASE
$ cd build
$ cmake $ZEPHYR_BASE/scripts
but there are still some errors, it seems like some packages missing.

MacBook-Pro-2:zephyr renkai$ cd build/

MacBook-Pro-2:build renkai$ cmake ../scripts/

-- Checking for modules 'gtk+-2.0;libglade-2.0'

-- No package 'gtk+-2.0' found

-- No package 'libglade-2.0' found

-- Skipped building gconf since GTK dependencies were not met.

-- Found unsuitable Qt version "" from NOTFOUND

-- Skipped building qconf since QT dependencies were not found.

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/renkai/Documents/Work/git/zephyr/build

so, I want to know, what wrong with it? And this phenomenon had ever been my Windows laptop before.

Regards,
Kai




_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org<mailto:Zephyr-devel@lists.zephyrproject.org>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality


uart_pipe spinning problem for stm32

Dmitry Shmidt
 

Hello,

In uart_pipe.c code:
static void uart_pipe_isr(struct device *unused)
{
ARG_UNUSED(unused);

while (uart_irq_update(uart_pipe_dev)
&& uart_irq_is_pending(uart_pipe_dev)) {
...
}

uart_irq_update() is returning 1 and
uart_irq_is_pending() is always TRUE for stm32, because
despite RXNE is cleared, TXE is always 1.
static int uart_stm32_irq_is_pending(struct device *dev)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);

return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
LL_USART_IsActiveFlag_TXE(UartInstance));

TXE is always 1 probably by design because poll_out is working
properly:
static unsigned char uart_stm32_poll_out(struct device *dev,

unsigned char c)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);

/* Wait for TXE flag to be raised */
while (!LL_USART_IsActiveFlag_TXE(UartInstance))
;

Please advise what is the right way to fix this issue:
1) Use uart_irq_rx_ready() instead of uart_irq_is_pending() in
while() in uart_pipe.c
2) Change uart_stm32_irq_is_pending() to return only RNXE -
however other drivers also return RXE || TXE
3) Clear TXE during input processing

Thanks,
Dmitry


STM32L4+ Series Support

Pushpal Sidhu
 

Hi,

I'm considering adding support for the NUCLEO-L4R5ZI or NUCLEO-L476RG
boards, but they use the 'newer' STM32L4+ series processors. I was
wondering whether or not it constitutes a new soc/st_stm32/stm32l4+
directory, or if I could just reuse the stm32l4.

Looking through it, it seems that keeping them merged makes the most
sense. It's what's currently done in the HAL drivers.

Thoughts?

- Pushpal


Re: RPL Tests

Pedro
 

As you requested,


Thank you.

2017-11-29 10:02 GMT-02:00 Pedro Paulo Canto Martucci <pedrom@...>:

Hi Ravi,

I will send a WIP PR, with my setup and README which allows you to reproduce.

Thanks!

2017-11-29 9:40 GMT-02:00 Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>:
Hi Pedro,

On 11/28/2017 10:12 PM, Pedro Paulo Canto Martucci wrote:
Hi,

I'm trying to validate some RPL features using QEMU. I know it's not the best approach but here we go.
   Yep, we can not completely validate RPL using QEMU. But at-least you started to check some features,
  thanks for that.


For this tests, I'm using 83cf82b7a tag from zephyr git project.

I created a root node to build the RPL network using the code bellow:

'''
#define CURRENT_VERSION 0

void main(void) {
u8_t init_version = CURRENT_VERSION;

char prefix_str[NET_IPV6_ADDR_LEN + 1];
struct in6_addr prefix;
u8_t prefix_len;

printk("RPL root node starting\n");

struct net_if *iface = net_if_get_default();
if (!iface) {
printk("Interface is NULL\n");
printk("Failed to setup RPL root node\n");
return;
}

// Read prefix from KConfig and parse it
memset(prefix_str, 0, sizeof(prefix_str));
memcpy(prefix_str, CONFIG_NET_RPL_PREFIX, min(strlen(CONFIG_NET_RPL_PREFIX), NET_IPV6_ADDR_LEN));

char *slash = strstr(prefix_str, "/");
if (!slash) {
prefix_len = 64;
} else {
*slash = '\0';
prefix_len = atoi(slash + 1);
}

if (prefix_len == 0) {
printk("Invalid prefix length %s", slash + 1);
return;
}

if (net_addr_pton(AF_INET6, prefix_str, &prefix) < 0) {
printk("Invalid IPv6 prefix %s", prefix_str);
return;
}

// Check the current version
if (CURRENT_VERSION == 0) {
// case 0 - call init
init_version = net_rpl_lollipop_init();
} else if (CURRENT_VERSION > 0) {
// case > 0 - increment
net_rpl_lollipop_increment(&init_version);
} else {
printk("CURRENT_VERSION should be greater or eqaul to 0");
return;
}

// Setup the root node
struct net_rpl_dag *dag = net_rpl_set_root_with_version(iface, CONFIG_NET_RPL_DEFAULT_INSTANCE, &prefix, init_version);

if (!dag) {
printk("Cannot set root node");
return;
}

bool ret = net_rpl_set_prefix(iface, dag, &prefix, prefix_len);
if (!ret) {
printk("Cannot set prefix %s/%d", prefix_str, prefix_len);
return;
}
}
'''

Most part of the code are based in pull request #980 and #5035, except version update handling, which I do manually.
   Those PR's are work in progress. It's taking some time test with different topologies and scenarios. Net subsystem
    needs to support some kind flash memory, so I haven't verified 'global repair' scenario.

The leaf node will run an empty main, I'll do the validation just pinging between the nodes using net shell.

On KConfig definitions for root node I setup RPL, 6LoWPAN and uart_pipe driver for 802.15.4:
'''
CONFIG_NET_RPL=y
CONFIG_NET_DEBUG_RPL=y
CONFIG_NET_RPL_GROUNDED=y
CONFIG_NET_RPL_MAX_DAG_PER_INSTANCE=1
CONFIG_NET_RPL_PREFIX="2001:db8::1/64"

# IPv6 (L3)
CONFIG_NET_IPV6=y

# 6LoWPAN (L2 - Adaptation Layer)
CONFIG_NET_6LO=y

# 802.15.4 (L2)
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_FRAGMENT=y

# 802.15.4 (L1)
CONFIG_IEEE802154_UPIPE=y

# Enabled Shell Extensions
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154_SHELL=y

# Disable default Ethernet interface
CONFIG_NET_SLIP_TAP=n

# Application Settings
CONFIG_NET_APP_SETTINGS=y
CONFIG_NET_APP_MY_IPV6_ADDR="2001:db8::1"
'''

In leaf node:
'''
CONFIG_NET_RPL=y
CONFIG_NET_DEBUG_RPL=y
CONFIG_NET_RPL_MAX_DAG_PER_INSTANCE=1

# IPv6 (L3)
CONFIG_NET_IPV6=y

# 6LoWPAN (L2 - Adaptation Layer)
CONFIG_NET_6LO=y

# 802.15.4 (L2)
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_FRAGMENT=y

# 802.15.4 (L1)
CONFIG_IEEE802154_UPIPE=y

# Enabled Shell Extensions
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154_SHELL=y

# Disable default Ethernet interface
CONFIG_NET_SLIP_TAP=n
'''

This way, I was able to run the example fine. The root published the prefix in DIO messages, the leaf node joined the DAG with DAO and I managed to ping between hosts using net shell.

My problems started when I tried to simulate a global repair scenario, rebooting the root node. To achieve this, it was necessary to modify some environments configurations.

To setup the QEMU environment I created the pipes manually and disabled removing/creation commands from zephyr/cmake/qemu/CMakeLists.txt in QEMU_NET_STACK session. This way when the 'server' node is rebooted the connection is not lost in the 'client' caused by the pipes recreation.
 
     It would be good to send a WIP PR with your setup and some readme file also. So that I can reproduce the issue and investigate purpose.
 
Also needed to modify get_mac() function from ieee802154_uart_pipe driver to assure that the MAC address assigned to the root node will be always the same:
'''
static inline u8_t *get_mac(struct device *dev)
{
struct upipe_context *upipe = dev->driver_data;


upipe->mac_addr[0] = 0x00;
upipe->mac_addr[1] = 0x10;
upipe->mac_addr[2] = 0x20;
upipe->mac_addr[3] = 0x30;

#if defined(CONFIG_NET_RPL_GROUNDED)
upipe->mac_addr[4] = 0xAA;
upipe->mac_addr[5] = 0xAA;
upipe->mac_addr[6] = 0xAA;
upipe->mac_addr[7] = 0xAA;
#else
UNALIGNED_PUT(sys_cpu_to_be32(sys_rand32_get()),
      (u32_t *) ((void *)upipe->mac_addr+4));
#endif

return upipe->mac_addr;
}
'''

Can you try with these Kconfig options.
 CONFIG_IEEE802154_CC2520_RANDOM_MAC=n
CONFIG_IEEE802154_CC2520_MAC4=0x00
CONFIG_IEEE802154_CC2520_MAC5=0x10
CONFIG_IEEE802154_CC2520_MAC6=0x20
CONFIG_IEEE802154_CC2520_MAC7=0x30


Now I run both applications and wait the network to be configured. After that, I kill the root node, update the constant CURRENT_VERSION in main.c to 240, recompile and rerun it.

The leaf node receives the DIO messages from the root with the new version and and trigger the global repair. During this process it removes the old neighbors/parents and try to setup the new one.

'''
[net/rpl] [DBG] handle_dio: (0x20000558): Received DODAG Information Object from fe80::210:2030:aaaa:aaaa to ff02::1a
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO len 72 id 30 ver 241 rank 256
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO dag_id 2001:db8::1 pref 0
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 4 length 14
[net/rpl] [DBG] handle_dio: (0x20000558): DAG conf dbl 8 min 12 red 10 maxinc 1792 mininc 256 ocp 1 d_l 255 l_u 65535
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 8 length 30
[net/rpl] [DBG] handle_dio: (0x20000558): Prefix 2001:db8::/64
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Global repair
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Prefix announced in DIO
[net/rpl] [DBG] net_rpl_set_prefix: (0x20000558): Prefix is non-NULL, will announce this in DIOs
[net/rpl] [DBG] check_prefix: (0x20000558): Same prefix 2001:db8::/64 flags 0x40
[net/rpl] [DBG] remove_parents: (0x20000558): Removing parents minimum rank 0
[net/rpl] [DBG] net_rpl_remove_parent: (0x20000558): Removing parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Removing default route fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_dao_send: (0x20000558): Send DAO with prefix 2001:db8::210:2030:9b:9856 from fe80::210:2030:9b:9856 to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent not set
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Nullifying parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_mrhof_reset: (0x20000558): Reset MRHOF
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Add parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] nbr_add: (0x20000558): nbr linking failure (-69)
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Cannot add RPL neighbor
[net/rpl] [DBG] global_repair: (0x20000558): Failed to add a parent during the global repair
[net/rpl] [DBG] global_repair: (0x20000558): Participating in a global repair version 241 rank 65535
'''

I think it should send a DAO message to the root to rejoin the network if everything is ok, but as we can see in the log it doesn't went right.

I tried to discover the reason why it was unable to add the parent, starting from nbr_add(). I reached to net_nbr_link() function from nbr.c and clearly it failed because of idx check (-EALREADY = -69):
'''
if (nbr->idx != NET_NBR_LLADDR_UNKNOWN) {
return -EALREADY;
}
'''

I don't understand properly the neighbor structures and organization from zephyr to reach any conclusion here, but seems the neighbor passed as argument to net_nbr_link() is not properly cleared as the function expects.

After expending some time on gdb, I verified that the neighbor passed as an argument is the same which was removed right before global repair process. This brings me to net_rpl_neighbor_data_remove() function from rpl.c, which just prints a message and doesn't clear nbr.

Based on this I did a stupid test adding a line to net_rpl_neighbor_data_remove(), just to check what would happen: 
'''
nbr->idx = 0xff;
'''

After rerunning the case I got the RPL network restablished.

'''
[net/rpl] [DBG] handle_dio: (0x20000558): Received DODAG Information Object from fe80::210:2030:aaaa:aaaa to ff02::1a
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO len 72 id 30 ver 241 rank 256
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO dag_id 2001:db8::1 pref 0
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 4 length 14
[net/rpl] [DBG] handle_dio: (0x20000558): DAG conf dbl 8 min 12 red 10 maxinc 1792 mininc 256 ocp 1 d_l 255 l_u 65535
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 8 length 30
[net/rpl] [DBG] handle_dio: (0x20000558): Prefix 2001:db8::/64
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Global repair
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Prefix announced in DIO
[net/rpl] [DBG] net_rpl_set_prefix: (0x20000558): Prefix is non-NULL, will announce this in DIOs
[net/rpl] [DBG] check_prefix: (0x20000558): Same prefix 2001:db8::/64 flags 0x40
[net/rpl] [DBG] remove_parents: (0x20000558): Removing parents minimum rank 0
[net/rpl] [DBG] net_rpl_remove_parent: (0x20000558): Removing parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Removing default route fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_dao_send: (0x20000558): Send DAO with prefix 2001:db8::210:2030:9c:475a from fe80::210:2030:9c:475a to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent not set
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Nullifying parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_mrhof_reset: (0x20000558): Reset MRHOF
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Add parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] nbr_add: (0x20000558): [0] nbr 0x200062b0 IPv6 fe80::210:2030:aaaa:aaaa ll 00:10:20:30:AA:AA:AA:AA iface 0x200067a0
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): [0] nbr 0x200062b0 parent 0x200062c4
[net/rpl] [DBG] global_repair: (0x20000558): Starting global repair
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be not set
[net/rpl] [DBG] net_rpl_set_default_route: (0x20000558): Adding default route through fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_select_dag: (0x20000558): Changed preferred parent, rank changed from 768 to 768
[net/rpl] [DBG] schedule_dao: (0x20000558): Scheduling DAO timer 4800 ms in the future
[net/rpl] [DBG] dao_timer: (0x20000cb0): Sending DAO iface 0x200067a0
[net/rpl] [DBG] net_rpl_dao_send: (0x20000cb0): Send DAO with prefix 2001:db8::210:2030:9c:475a from fe80::210:2030:9c:475a to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_link_neighbor_callback: (0x2000060c): Neighbor link callback triggering update
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Received Destination Advertisement Object Ack from fe80::210:2030:aaaa:aaaa to fe80::210:2030:9c:475a
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Received a DAO ACK with seq number 244(244) status 0 from fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Status ACK
'''

Clearly my approach wasn't correct, I don't even understand properly the neighbor dynamics. Did I miss something in my setup which might have caused this behavior? Or there are something wrong on neighbor management?

At-least now I will investigate with above logs, it would be good if you can send your patches and steps to reproduce.

Thanks,
Ravi.
Thank you!

--
Att,
Pedro Martucci
---
Gerência de Tecnologias de Controle e Inteligência de Sistemas
CPqD - Diretoria de Tecnologias de Comunicação
Tel.: +55 19 3705-5995


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




--
Att,
Pedro Martucci
---
Gerência de Tecnologias de Controle e Inteligência de Sistemas
CPqD - Diretoria de Tecnologias de Comunicação
Tel.: +55 19 3705-5995



--
Att,
Pedro Martucci
---
Gerência de Tecnologias de Controle e Inteligência de Sistemas
CPqD - Diretoria de Tecnologias de Comunicação
Tel.: +55 19 3705-5995


Re: RPL Tests

Pedro
 

Hi Ravi,

I will send a WIP PR, with my setup and README which allows you to reproduce.

Thanks!

2017-11-29 9:40 GMT-02:00 Ravi kumar Veeramally <ravikumar.veeramally@...>:

Hi Pedro,

On 11/28/2017 10:12 PM, Pedro Paulo Canto Martucci wrote:
Hi,

I'm trying to validate some RPL features using QEMU. I know it's not the best approach but here we go.
   Yep, we can not completely validate RPL using QEMU. But at-least you started to check some features,
  thanks for that.


For this tests, I'm using 83cf82b7a tag from zephyr git project.

I created a root node to build the RPL network using the code bellow:

'''
#define CURRENT_VERSION 0

void main(void) {
u8_t init_version = CURRENT_VERSION;

char prefix_str[NET_IPV6_ADDR_LEN + 1];
struct in6_addr prefix;
u8_t prefix_len;

printk("RPL root node starting\n");

struct net_if *iface = net_if_get_default();
if (!iface) {
printk("Interface is NULL\n");
printk("Failed to setup RPL root node\n");
return;
}

// Read prefix from KConfig and parse it
memset(prefix_str, 0, sizeof(prefix_str));
memcpy(prefix_str, CONFIG_NET_RPL_PREFIX, min(strlen(CONFIG_NET_RPL_PREFIX), NET_IPV6_ADDR_LEN));

char *slash = strstr(prefix_str, "/");
if (!slash) {
prefix_len = 64;
} else {
*slash = '\0';
prefix_len = atoi(slash + 1);
}

if (prefix_len == 0) {
printk("Invalid prefix length %s", slash + 1);
return;
}

if (net_addr_pton(AF_INET6, prefix_str, &prefix) < 0) {
printk("Invalid IPv6 prefix %s", prefix_str);
return;
}

// Check the current version
if (CURRENT_VERSION == 0) {
// case 0 - call init
init_version = net_rpl_lollipop_init();
} else if (CURRENT_VERSION > 0) {
// case > 0 - increment
net_rpl_lollipop_increment(&init_version);
} else {
printk("CURRENT_VERSION should be greater or eqaul to 0");
return;
}

// Setup the root node
struct net_rpl_dag *dag = net_rpl_set_root_with_version(iface, CONFIG_NET_RPL_DEFAULT_INSTANCE, &prefix, init_version);

if (!dag) {
printk("Cannot set root node");
return;
}

bool ret = net_rpl_set_prefix(iface, dag, &prefix, prefix_len);
if (!ret) {
printk("Cannot set prefix %s/%d", prefix_str, prefix_len);
return;
}
}
'''

Most part of the code are based in pull request #980 and #5035, except version update handling, which I do manually.
   Those PR's are work in progress. It's taking some time test with different topologies and scenarios. Net subsystem
    needs to support some kind flash memory, so I haven't verified 'global repair' scenario.

The leaf node will run an empty main, I'll do the validation just pinging between the nodes using net shell.

On KConfig definitions for root node I setup RPL, 6LoWPAN and uart_pipe driver for 802.15.4:
'''
CONFIG_NET_RPL=y
CONFIG_NET_DEBUG_RPL=y
CONFIG_NET_RPL_GROUNDED=y
CONFIG_NET_RPL_MAX_DAG_PER_INSTANCE=1
CONFIG_NET_RPL_PREFIX="2001:db8::1/64"

# IPv6 (L3)
CONFIG_NET_IPV6=y

# 6LoWPAN (L2 - Adaptation Layer)
CONFIG_NET_6LO=y

# 802.15.4 (L2)
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_FRAGMENT=y

# 802.15.4 (L1)
CONFIG_IEEE802154_UPIPE=y

# Enabled Shell Extensions
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154_SHELL=y

# Disable default Ethernet interface
CONFIG_NET_SLIP_TAP=n

# Application Settings
CONFIG_NET_APP_SETTINGS=y
CONFIG_NET_APP_MY_IPV6_ADDR="2001:db8::1"
'''

In leaf node:
'''
CONFIG_NET_RPL=y
CONFIG_NET_DEBUG_RPL=y
CONFIG_NET_RPL_MAX_DAG_PER_INSTANCE=1

# IPv6 (L3)
CONFIG_NET_IPV6=y

# 6LoWPAN (L2 - Adaptation Layer)
CONFIG_NET_6LO=y

# 802.15.4 (L2)
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_FRAGMENT=y

# 802.15.4 (L1)
CONFIG_IEEE802154_UPIPE=y

# Enabled Shell Extensions
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154_SHELL=y

# Disable default Ethernet interface
CONFIG_NET_SLIP_TAP=n
'''

This way, I was able to run the example fine. The root published the prefix in DIO messages, the leaf node joined the DAG with DAO and I managed to ping between hosts using net shell.

My problems started when I tried to simulate a global repair scenario, rebooting the root node. To achieve this, it was necessary to modify some environments configurations.

To setup the QEMU environment I created the pipes manually and disabled removing/creation commands from zephyr/cmake/qemu/CMakeLists.txt in QEMU_NET_STACK session. This way when the 'server' node is rebooted the connection is not lost in the 'client' caused by the pipes recreation.
 
     It would be good to send a WIP PR with your setup and some readme file also. So that I can reproduce the issue and investigate purpose.
 
Also needed to modify get_mac() function from ieee802154_uart_pipe driver to assure that the MAC address assigned to the root node will be always the same:
'''
static inline u8_t *get_mac(struct device *dev)
{
struct upipe_context *upipe = dev->driver_data;


upipe->mac_addr[0] = 0x00;
upipe->mac_addr[1] = 0x10;
upipe->mac_addr[2] = 0x20;
upipe->mac_addr[3] = 0x30;

#if defined(CONFIG_NET_RPL_GROUNDED)
upipe->mac_addr[4] = 0xAA;
upipe->mac_addr[5] = 0xAA;
upipe->mac_addr[6] = 0xAA;
upipe->mac_addr[7] = 0xAA;
#else
UNALIGNED_PUT(sys_cpu_to_be32(sys_rand32_get()),
      (u32_t *) ((void *)upipe->mac_addr+4));
#endif

return upipe->mac_addr;
}
'''

Can you try with these Kconfig options.
 CONFIG_IEEE802154_CC2520_RANDOM_MAC=n
CONFIG_IEEE802154_CC2520_MAC4=0x00
CONFIG_IEEE802154_CC2520_MAC5=0x10
CONFIG_IEEE802154_CC2520_MAC6=0x20
CONFIG_IEEE802154_CC2520_MAC7=0x30


Now I run both applications and wait the network to be configured. After that, I kill the root node, update the constant CURRENT_VERSION in main.c to 240, recompile and rerun it.

The leaf node receives the DIO messages from the root with the new version and and trigger the global repair. During this process it removes the old neighbors/parents and try to setup the new one.

'''
[net/rpl] [DBG] handle_dio: (0x20000558): Received DODAG Information Object from fe80::210:2030:aaaa:aaaa to ff02::1a
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO len 72 id 30 ver 241 rank 256
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO dag_id 2001:db8::1 pref 0
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 4 length 14
[net/rpl] [DBG] handle_dio: (0x20000558): DAG conf dbl 8 min 12 red 10 maxinc 1792 mininc 256 ocp 1 d_l 255 l_u 65535
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 8 length 30
[net/rpl] [DBG] handle_dio: (0x20000558): Prefix 2001:db8::/64
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Global repair
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Prefix announced in DIO
[net/rpl] [DBG] net_rpl_set_prefix: (0x20000558): Prefix is non-NULL, will announce this in DIOs
[net/rpl] [DBG] check_prefix: (0x20000558): Same prefix 2001:db8::/64 flags 0x40
[net/rpl] [DBG] remove_parents: (0x20000558): Removing parents minimum rank 0
[net/rpl] [DBG] net_rpl_remove_parent: (0x20000558): Removing parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Removing default route fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_dao_send: (0x20000558): Send DAO with prefix 2001:db8::210:2030:9b:9856 from fe80::210:2030:9b:9856 to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent not set
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Nullifying parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_mrhof_reset: (0x20000558): Reset MRHOF
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Add parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] nbr_add: (0x20000558): nbr linking failure (-69)
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Cannot add RPL neighbor
[net/rpl] [DBG] global_repair: (0x20000558): Failed to add a parent during the global repair
[net/rpl] [DBG] global_repair: (0x20000558): Participating in a global repair version 241 rank 65535
'''

I think it should send a DAO message to the root to rejoin the network if everything is ok, but as we can see in the log it doesn't went right.

I tried to discover the reason why it was unable to add the parent, starting from nbr_add(). I reached to net_nbr_link() function from nbr.c and clearly it failed because of idx check (-EALREADY = -69):
'''
if (nbr->idx != NET_NBR_LLADDR_UNKNOWN) {
return -EALREADY;
}
'''

I don't understand properly the neighbor structures and organization from zephyr to reach any conclusion here, but seems the neighbor passed as argument to net_nbr_link() is not properly cleared as the function expects.

After expending some time on gdb, I verified that the neighbor passed as an argument is the same which was removed right before global repair process. This brings me to net_rpl_neighbor_data_remove() function from rpl.c, which just prints a message and doesn't clear nbr.

Based on this I did a stupid test adding a line to net_rpl_neighbor_data_remove(), just to check what would happen: 
'''
nbr->idx = 0xff;
'''

After rerunning the case I got the RPL network restablished.

'''
[net/rpl] [DBG] handle_dio: (0x20000558): Received DODAG Information Object from fe80::210:2030:aaaa:aaaa to ff02::1a
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO len 72 id 30 ver 241 rank 256
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO dag_id 2001:db8::1 pref 0
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 4 length 14
[net/rpl] [DBG] handle_dio: (0x20000558): DAG conf dbl 8 min 12 red 10 maxinc 1792 mininc 256 ocp 1 d_l 255 l_u 65535
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 8 length 30
[net/rpl] [DBG] handle_dio: (0x20000558): Prefix 2001:db8::/64
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Global repair
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Prefix announced in DIO
[net/rpl] [DBG] net_rpl_set_prefix: (0x20000558): Prefix is non-NULL, will announce this in DIOs
[net/rpl] [DBG] check_prefix: (0x20000558): Same prefix 2001:db8::/64 flags 0x40
[net/rpl] [DBG] remove_parents: (0x20000558): Removing parents minimum rank 0
[net/rpl] [DBG] net_rpl_remove_parent: (0x20000558): Removing parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Removing default route fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_dao_send: (0x20000558): Send DAO with prefix 2001:db8::210:2030:9c:475a from fe80::210:2030:9c:475a to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent not set
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Nullifying parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_mrhof_reset: (0x20000558): Reset MRHOF
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Add parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] nbr_add: (0x20000558): [0] nbr 0x200062b0 IPv6 fe80::210:2030:aaaa:aaaa ll 00:10:20:30:AA:AA:AA:AA iface 0x200067a0
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): [0] nbr 0x200062b0 parent 0x200062c4
[net/rpl] [DBG] global_repair: (0x20000558): Starting global repair
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be not set
[net/rpl] [DBG] net_rpl_set_default_route: (0x20000558): Adding default route through fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_select_dag: (0x20000558): Changed preferred parent, rank changed from 768 to 768
[net/rpl] [DBG] schedule_dao: (0x20000558): Scheduling DAO timer 4800 ms in the future
[net/rpl] [DBG] dao_timer: (0x20000cb0): Sending DAO iface 0x200067a0
[net/rpl] [DBG] net_rpl_dao_send: (0x20000cb0): Send DAO with prefix 2001:db8::210:2030:9c:475a from fe80::210:2030:9c:475a to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_link_neighbor_callback: (0x2000060c): Neighbor link callback triggering update
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Received Destination Advertisement Object Ack from fe80::210:2030:aaaa:aaaa to fe80::210:2030:9c:475a
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Received a DAO ACK with seq number 244(244) status 0 from fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Status ACK
'''

Clearly my approach wasn't correct, I don't even understand properly the neighbor dynamics. Did I miss something in my setup which might have caused this behavior? Or there are something wrong on neighbor management?

At-least now I will investigate with above logs, it would be good if you can send your patches and steps to reproduce.

Thanks,
Ravi.
Thank you!

--
Att,
Pedro Martucci
---
Gerência de Tecnologias de Controle e Inteligência de Sistemas
CPqD - Diretoria de Tecnologias de Comunicação
Tel.: +55 19 3705-5995


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




--
Att,
Pedro Martucci
---
Gerência de Tecnologias de Controle e Inteligência de Sistemas
CPqD - Diretoria de Tecnologias de Comunicação
Tel.: +55 19 3705-5995


Re: RPL Tests

Ravi kumar Veeramally
 

Hi Pedro,

On 11/28/2017 10:12 PM, Pedro Paulo Canto Martucci wrote:
Hi,

I'm trying to validate some RPL features using QEMU. I know it's not the best approach but here we go.
   Yep, we can not completely validate RPL using QEMU. But at-least you started to check some features,
  thanks for that.

For this tests, I'm using 83cf82b7a tag from zephyr git project.

I created a root node to build the RPL network using the code bellow:

'''
#define CURRENT_VERSION 0

void main(void) {
u8_t init_version = CURRENT_VERSION;

char prefix_str[NET_IPV6_ADDR_LEN + 1];
struct in6_addr prefix;
u8_t prefix_len;

printk("RPL root node starting\n");

struct net_if *iface = net_if_get_default();
if (!iface) {
printk("Interface is NULL\n");
printk("Failed to setup RPL root node\n");
return;
}

// Read prefix from KConfig and parse it
memset(prefix_str, 0, sizeof(prefix_str));
memcpy(prefix_str, CONFIG_NET_RPL_PREFIX, min(strlen(CONFIG_NET_RPL_PREFIX), NET_IPV6_ADDR_LEN));

char *slash = strstr(prefix_str, "/");
if (!slash) {
prefix_len = 64;
} else {
*slash = '\0';
prefix_len = atoi(slash + 1);
}

if (prefix_len == 0) {
printk("Invalid prefix length %s", slash + 1);
return;
}

if (net_addr_pton(AF_INET6, prefix_str, &prefix) < 0) {
printk("Invalid IPv6 prefix %s", prefix_str);
return;
}

// Check the current version
if (CURRENT_VERSION == 0) {
// case 0 - call init
init_version = net_rpl_lollipop_init();
} else if (CURRENT_VERSION > 0) {
// case > 0 - increment
net_rpl_lollipop_increment(&init_version);
} else {
printk("CURRENT_VERSION should be greater or eqaul to 0");
return;
}

// Setup the root node
struct net_rpl_dag *dag = net_rpl_set_root_with_version(iface, CONFIG_NET_RPL_DEFAULT_INSTANCE, &prefix, init_version);

if (!dag) {
printk("Cannot set root node");
return;
}

bool ret = net_rpl_set_prefix(iface, dag, &prefix, prefix_len);
if (!ret) {
printk("Cannot set prefix %s/%d", prefix_str, prefix_len);
return;
}
}
'''

Most part of the code are based in pull request #980 and #5035, except version update handling, which I do manually.
   Those PR's are work in progress. It's taking some time test with different topologies and scenarios. Net subsystem
    needs to support some kind flash memory, so I haven't verified 'global repair' scenario.

The leaf node will run an empty main, I'll do the validation just pinging between the nodes using net shell.

On KConfig definitions for root node I setup RPL, 6LoWPAN and uart_pipe driver for 802.15.4:
'''
CONFIG_NET_RPL=y
CONFIG_NET_DEBUG_RPL=y
CONFIG_NET_RPL_GROUNDED=y
CONFIG_NET_RPL_MAX_DAG_PER_INSTANCE=1
CONFIG_NET_RPL_PREFIX="2001:db8::1/64"

# IPv6 (L3)
CONFIG_NET_IPV6=y

# 6LoWPAN (L2 - Adaptation Layer)
CONFIG_NET_6LO=y

# 802.15.4 (L2)
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_FRAGMENT=y

# 802.15.4 (L1)
CONFIG_IEEE802154_UPIPE=y

# Enabled Shell Extensions
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154_SHELL=y

# Disable default Ethernet interface
CONFIG_NET_SLIP_TAP=n

# Application Settings
CONFIG_NET_APP_SETTINGS=y
CONFIG_NET_APP_MY_IPV6_ADDR="2001:db8::1"
'''

In leaf node:
'''
CONFIG_NET_RPL=y
CONFIG_NET_DEBUG_RPL=y
CONFIG_NET_RPL_MAX_DAG_PER_INSTANCE=1

# IPv6 (L3)
CONFIG_NET_IPV6=y

# 6LoWPAN (L2 - Adaptation Layer)
CONFIG_NET_6LO=y

# 802.15.4 (L2)
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_FRAGMENT=y

# 802.15.4 (L1)
CONFIG_IEEE802154_UPIPE=y

# Enabled Shell Extensions
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154_SHELL=y

# Disable default Ethernet interface
CONFIG_NET_SLIP_TAP=n
'''

This way, I was able to run the example fine. The root published the prefix in DIO messages, the leaf node joined the DAG with DAO and I managed to ping between hosts using net shell.

My problems started when I tried to simulate a global repair scenario, rebooting the root node. To achieve this, it was necessary to modify some environments configurations.

To setup the QEMU environment I created the pipes manually and disabled removing/creation commands from zephyr/cmake/qemu/CMakeLists.txt in QEMU_NET_STACK session. This way when the 'server' node is rebooted the connection is not lost in the 'client' caused by the pipes recreation.
 
     It would be good to send a WIP PR with your setup and some readme file also. So that I can reproduce the issue and investigate purpose.
 
Also needed to modify get_mac() function from ieee802154_uart_pipe driver to assure that the MAC address assigned to the root node will be always the same:
'''
static inline u8_t *get_mac(struct device *dev)
{
struct upipe_context *upipe = dev->driver_data;


upipe->mac_addr[0] = 0x00;
upipe->mac_addr[1] = 0x10;
upipe->mac_addr[2] = 0x20;
upipe->mac_addr[3] = 0x30;

#if defined(CONFIG_NET_RPL_GROUNDED)
upipe->mac_addr[4] = 0xAA;
upipe->mac_addr[5] = 0xAA;
upipe->mac_addr[6] = 0xAA;
upipe->mac_addr[7] = 0xAA;
#else
UNALIGNED_PUT(sys_cpu_to_be32(sys_rand32_get()),
      (u32_t *) ((void *)upipe->mac_addr+4));
#endif

return upipe->mac_addr;
}
'''

Can you try with these Kconfig options.
 CONFIG_IEEE802154_CC2520_RANDOM_MAC=n
CONFIG_IEEE802154_CC2520_MAC4=0x00
CONFIG_IEEE802154_CC2520_MAC5=0x10
CONFIG_IEEE802154_CC2520_MAC6=0x20
CONFIG_IEEE802154_CC2520_MAC7=0x30

Now I run both applications and wait the network to be configured. After that, I kill the root node, update the constant CURRENT_VERSION in main.c to 240, recompile and rerun it.

The leaf node receives the DIO messages from the root with the new version and and trigger the global repair. During this process it removes the old neighbors/parents and try to setup the new one.

'''
[net/rpl] [DBG] handle_dio: (0x20000558): Received DODAG Information Object from fe80::210:2030:aaaa:aaaa to ff02::1a
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO len 72 id 30 ver 241 rank 256
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO dag_id 2001:db8::1 pref 0
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 4 length 14
[net/rpl] [DBG] handle_dio: (0x20000558): DAG conf dbl 8 min 12 red 10 maxinc 1792 mininc 256 ocp 1 d_l 255 l_u 65535
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 8 length 30
[net/rpl] [DBG] handle_dio: (0x20000558): Prefix 2001:db8::/64
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Global repair
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Prefix announced in DIO
[net/rpl] [DBG] net_rpl_set_prefix: (0x20000558): Prefix is non-NULL, will announce this in DIOs
[net/rpl] [DBG] check_prefix: (0x20000558): Same prefix 2001:db8::/64 flags 0x40
[net/rpl] [DBG] remove_parents: (0x20000558): Removing parents minimum rank 0
[net/rpl] [DBG] net_rpl_remove_parent: (0x20000558): Removing parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Removing default route fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_dao_send: (0x20000558): Send DAO with prefix 2001:db8::210:2030:9b:9856 from fe80::210:2030:9b:9856 to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent not set
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Nullifying parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_mrhof_reset: (0x20000558): Reset MRHOF
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Add parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] nbr_add: (0x20000558): nbr linking failure (-69)
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Cannot add RPL neighbor
[net/rpl] [DBG] global_repair: (0x20000558): Failed to add a parent during the global repair
[net/rpl] [DBG] global_repair: (0x20000558): Participating in a global repair version 241 rank 65535
'''

I think it should send a DAO message to the root to rejoin the network if everything is ok, but as we can see in the log it doesn't went right.

I tried to discover the reason why it was unable to add the parent, starting from nbr_add(). I reached to net_nbr_link() function from nbr.c and clearly it failed because of idx check (-EALREADY = -69):
'''
if (nbr->idx != NET_NBR_LLADDR_UNKNOWN) {
return -EALREADY;
}
'''

I don't understand properly the neighbor structures and organization from zephyr to reach any conclusion here, but seems the neighbor passed as argument to net_nbr_link() is not properly cleared as the function expects.

After expending some time on gdb, I verified that the neighbor passed as an argument is the same which was removed right before global repair process. This brings me to net_rpl_neighbor_data_remove() function from rpl.c, which just prints a message and doesn't clear nbr.

Based on this I did a stupid test adding a line to net_rpl_neighbor_data_remove(), just to check what would happen: 
'''
nbr->idx = 0xff;
'''

After rerunning the case I got the RPL network restablished.

'''
[net/rpl] [DBG] handle_dio: (0x20000558): Received DODAG Information Object from fe80::210:2030:aaaa:aaaa to ff02::1a
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO len 72 id 30 ver 241 rank 256
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO dag_id 2001:db8::1 pref 0
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 4 length 14
[net/rpl] [DBG] handle_dio: (0x20000558): DAG conf dbl 8 min 12 red 10 maxinc 1792 mininc 256 ocp 1 d_l 255 l_u 65535
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 8 length 30
[net/rpl] [DBG] handle_dio: (0x20000558): Prefix 2001:db8::/64
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Global repair
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Prefix announced in DIO
[net/rpl] [DBG] net_rpl_set_prefix: (0x20000558): Prefix is non-NULL, will announce this in DIOs
[net/rpl] [DBG] check_prefix: (0x20000558): Same prefix 2001:db8::/64 flags 0x40
[net/rpl] [DBG] remove_parents: (0x20000558): Removing parents minimum rank 0
[net/rpl] [DBG] net_rpl_remove_parent: (0x20000558): Removing parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Removing default route fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_dao_send: (0x20000558): Send DAO with prefix 2001:db8::210:2030:9c:475a from fe80::210:2030:9c:475a to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent not set
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Nullifying parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_mrhof_reset: (0x20000558): Reset MRHOF
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Add parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] nbr_add: (0x20000558): [0] nbr 0x200062b0 IPv6 fe80::210:2030:aaaa:aaaa ll 00:10:20:30:AA:AA:AA:AA iface 0x200067a0
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): [0] nbr 0x200062b0 parent 0x200062c4
[net/rpl] [DBG] global_repair: (0x20000558): Starting global repair
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be not set
[net/rpl] [DBG] net_rpl_set_default_route: (0x20000558): Adding default route through fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_select_dag: (0x20000558): Changed preferred parent, rank changed from 768 to 768
[net/rpl] [DBG] schedule_dao: (0x20000558): Scheduling DAO timer 4800 ms in the future
[net/rpl] [DBG] dao_timer: (0x20000cb0): Sending DAO iface 0x200067a0
[net/rpl] [DBG] net_rpl_dao_send: (0x20000cb0): Send DAO with prefix 2001:db8::210:2030:9c:475a from fe80::210:2030:9c:475a to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_link_neighbor_callback: (0x2000060c): Neighbor link callback triggering update
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Received Destination Advertisement Object Ack from fe80::210:2030:aaaa:aaaa to fe80::210:2030:9c:475a
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Received a DAO ACK with seq number 244(244) status 0 from fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Status ACK
'''

Clearly my approach wasn't correct, I don't even understand properly the neighbor dynamics. Did I miss something in my setup which might have caused this behavior? Or there are something wrong on neighbor management?

At-least now I will investigate with above logs, it would be good if you can send your patches and steps to reproduce.

Thanks,
Ravi.
Thank you!

--
Att,
Pedro Martucci
---
Gerência de Tecnologias de Controle e Inteligência de Sistemas
CPqD - Diretoria de Tecnologias de Comunicação
Tel.: +55 19 3705-5995


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: cmake error when I tried to build "mesh_shell"

Sebastian Boe
 

Hi Kai,

the first few lines in your error message means you are affected
by this issue:

https://stackoverflow.com/questions/47081317/zephyr-cmake-error
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Timothy <tymoteusz.kielan@gmail.com>
Sent: Wednesday, 29 November 2017 9:41:29 AM
To: Kai Ren
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] cmake error when I tried to build "mesh_shell"

Hi Kai,

It looks like there are no errors on your 2nd pass.
Those are just warnings caused by CMake not finding Qt (in suitable version) and GTK libraries.
If you are not planning to build xconfig or gconfig target you can simply skip them.

This step has produced you a project build folder (called build)
Now you have to do an additional step and actually build the project.

To do that use one of the following commands:
- cmake --build build
- ninja -C build
- make -C build

Tim

On 29 November 2017 at 08:36, Kai Ren <kren@bluetooth.com<mailto:kren@bluetooth.com>> wrote:
Hi there,
I had ever cmake and make “sample/Bluetooth/mesh” application today, get the corresponding hex file, I just make my MacBook laptop sleep for a while and didn’t change anything, I can’t build again.


MacBook-Pro-2:pca10040 renkai$ cmake -DBOARD=nrf52_pca10040 ..

CMake Error at CMakeLists.txt:1 (include):

include could not find load file:



/cmake/app/boilerplate.cmake





CMake Error at CMakeLists.txt:5 (target_sources):

Cannot specify sources for target "app" which is not built by this project.





CMake Warning (dev) in CMakeLists.txt:

No cmake_minimum_required command is present. A line of code such as



cmake_minimum_required(VERSION 3.10)



should be added at the top of the file. The version specified may be lower

if you wish to support older CMake versions for this project. For more

information run "cmake --help-policy CMP0000".

This warning is for project developers. Use -Wno-dev to suppress it.



-- Configuring incomplete, errors occurred!

See also "/Users/renkai/Documents/Work/git/zephyr/tests/bluetooth/mesh_shell/pca10040/CMakeFiles/CMakeOutput.log".

I thought there may be some errors in ./cmake folder, so I tried to rebuild it, then:
$ cd $ZEPHYR_BASE
$ cd build
$ cmake $ZEPHYR_BASE/scripts
but there are still some errors, it seems like some packages missing.

MacBook-Pro-2:zephyr renkai$ cd build/

MacBook-Pro-2:build renkai$ cmake ../scripts/

-- Checking for modules 'gtk+-2.0;libglade-2.0'

-- No package 'gtk+-2.0' found

-- No package 'libglade-2.0' found

-- Skipped building gconf since GTK dependencies were not met.

-- Found unsuitable Qt version "" from NOTFOUND

-- Skipped building qconf since QT dependencies were not found.

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/renkai/Documents/Work/git/zephyr/build

so, I want to know, what wrong with it? And this phenomenon had ever been my Windows laptop before.

Regards,
Kai




_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org<mailto:Zephyr-devel@lists.zephyrproject.org>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality


Re: cmake error when I tried to build "mesh_shell"

Timothy <tymoteusz.kielan@...>
 

Hi Kai,

It looks like there are no errors on your 2nd pass.
Those are just warnings caused by CMake not finding Qt (in suitable version) and GTK libraries.
If you are not planning to build xconfig or gconfig target you can simply skip them.

This step has produced you a project build folder (called build)
Now you have to do an additional step and actually build the project.

To do that use one of the following commands:
- cmake --build build
- ninja -C build
- make -C build

Tim

On 29 November 2017 at 08:36, Kai Ren <kren@...> wrote:

Hi there,

I had ever cmake and make “sample/Bluetooth/mesh” application today, get the corresponding hex file, I just make my MacBook laptop sleep for a while and didn’t change anything, I can’t build again.

 

MacBook-Pro-2:pca10040 renkai$ cmake -DBOARD=nrf52_pca10040 ..

CMake Error at CMakeLists.txt:1 (include):

  include could not find load file:

 

    /cmake/app/boilerplate.cmake

 

 

CMake Error at CMakeLists.txt:5 (target_sources):

  Cannot specify sources for target "app" which is not built by this project.

 

 

CMake Warning (dev) in CMakeLists.txt:

  No cmake_minimum_required command is present.  A line of code such as

 

    cmake_minimum_required(VERSION 3.10)

 

  should be added at the top of the file.  The version specified may be lower

  if you wish to support older CMake versions for this project.  For more

  information run "cmake --help-policy CMP0000".

This warning is for project developers.  Use -Wno-dev to suppress it.

 

-- Configuring incomplete, errors occurred!

See also "/Users/renkai/Documents/Work/git/zephyr/tests/bluetooth/mesh_shell/pca10040/CMakeFiles/CMakeOutput.log".

 

I thought there may be some errors in ./cmake folder, so I tried to rebuild it, then:

$ cd $ZEPHYR_BASE

$ cd build

$ cmake $ZEPHYR_BASE/scripts

but there are still some errors, it seems like some packages missing.

MacBook-Pro-2:zephyr renkai$ cd build/

MacBook-Pro-2:build renkai$ cmake ../scripts/

-- Checking for modules 'gtk+-2.0;libglade-2.0'

--   No package 'gtk+-2.0' found

--   No package 'libglade-2.0' found

-- Skipped building gconf since GTK dependencies were not met.

-- Found unsuitable Qt version "" from NOTFOUND

-- Skipped building qconf since QT dependencies were not found.

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/renkai/Documents/Work/git/zephyr/build

 

so, I want to know, what wrong with it? And this phenomenon had ever been my Windows laptop before.

 

Regards,

Kai

 

 

 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality


cmake error when I tried to build "mesh_shell"

Kai Ren
 

Hi there,

I had ever cmake and make “sample/Bluetooth/mesh” application today, get the corresponding hex file, I just make my MacBook laptop sleep for a while and didn’t change anything, I can’t build again.

 

MacBook-Pro-2:pca10040 renkai$ cmake -DBOARD=nrf52_pca10040 ..

CMake Error at CMakeLists.txt:1 (include):

  include could not find load file:

 

    /cmake/app/boilerplate.cmake

 

 

CMake Error at CMakeLists.txt:5 (target_sources):

  Cannot specify sources for target "app" which is not built by this project.

 

 

CMake Warning (dev) in CMakeLists.txt:

  No cmake_minimum_required command is present.  A line of code such as

 

    cmake_minimum_required(VERSION 3.10)

 

  should be added at the top of the file.  The version specified may be lower

  if you wish to support older CMake versions for this project.  For more

  information run "cmake --help-policy CMP0000".

This warning is for project developers.  Use -Wno-dev to suppress it.

 

-- Configuring incomplete, errors occurred!

See also "/Users/renkai/Documents/Work/git/zephyr/tests/bluetooth/mesh_shell/pca10040/CMakeFiles/CMakeOutput.log".

 

I thought there may be some errors in ./cmake folder, so I tried to rebuild it, then:

$ cd $ZEPHYR_BASE

$ cd build

$ cmake $ZEPHYR_BASE/scripts

but there are still some errors, it seems like some packages missing.

MacBook-Pro-2:zephyr renkai$ cd build/

MacBook-Pro-2:build renkai$ cmake ../scripts/

-- Checking for modules 'gtk+-2.0;libglade-2.0'

--   No package 'gtk+-2.0' found

--   No package 'libglade-2.0' found

-- Skipped building gconf since GTK dependencies were not met.

-- Found unsuitable Qt version "" from NOTFOUND

-- Skipped building qconf since QT dependencies were not found.

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/renkai/Documents/Work/git/zephyr/build

 

so, I want to know, what wrong with it? And this phenomenon had ever been my Windows laptop before.

 

Regards,

Kai

 

 

 


Zephyr 1.10.0-rc2 tagged

Kumar Gala
 

Hi,

We have just tagged Zephyr 1.10.0-rc2. The release looks to be stabilizing pretty well. There are a few open PRs and issues that we will work to close out over the next few days. If you have any bugs please open an issue and mark it as v1.10. The release notes are still work in progress, however a detailed log of the changes since v1.10.0-rc1 can be found here:


https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.10.0-rc2

Thanks

- k


RPL Tests

Pedro
 

Hi,

I'm trying to validate some RPL features using QEMU. I know it's not the best approach but here we go.

For this tests, I'm using 83cf82b7a tag from zephyr git project.

I created a root node to build the RPL network using the code bellow:

'''
#define CURRENT_VERSION 0

void main(void) {
u8_t init_version = CURRENT_VERSION;

char prefix_str[NET_IPV6_ADDR_LEN + 1];
struct in6_addr prefix;
u8_t prefix_len;

printk("RPL root node starting\n");

struct net_if *iface = net_if_get_default();
if (!iface) {
printk("Interface is NULL\n");
printk("Failed to setup RPL root node\n");
return;
}

// Read prefix from KConfig and parse it
memset(prefix_str, 0, sizeof(prefix_str));
memcpy(prefix_str, CONFIG_NET_RPL_PREFIX, min(strlen(CONFIG_NET_RPL_PREFIX), NET_IPV6_ADDR_LEN));

char *slash = strstr(prefix_str, "/");
if (!slash) {
prefix_len = 64;
} else {
*slash = '\0';
prefix_len = atoi(slash + 1);
}

if (prefix_len == 0) {
printk("Invalid prefix length %s", slash + 1);
return;
}

if (net_addr_pton(AF_INET6, prefix_str, &prefix) < 0) {
printk("Invalid IPv6 prefix %s", prefix_str);
return;
}

// Check the current version
if (CURRENT_VERSION == 0) {
// case 0 - call init
init_version = net_rpl_lollipop_init();
} else if (CURRENT_VERSION > 0) {
// case > 0 - increment
net_rpl_lollipop_increment(&init_version);
} else {
printk("CURRENT_VERSION should be greater or eqaul to 0");
return;
}

// Setup the root node
struct net_rpl_dag *dag = net_rpl_set_root_with_version(iface, CONFIG_NET_RPL_DEFAULT_INSTANCE, &prefix, init_version);

if (!dag) {
printk("Cannot set root node");
return;
}

bool ret = net_rpl_set_prefix(iface, dag, &prefix, prefix_len);
if (!ret) {
printk("Cannot set prefix %s/%d", prefix_str, prefix_len);
return;
}
}
'''

Most part of the code are based in pull request #980 and #5035, except version update handling, which I do manually.

The leaf node will run an empty main, I'll do the validation just pinging between the nodes using net shell.

On KConfig definitions for root node I setup RPL, 6LoWPAN and uart_pipe driver for 802.15.4:
'''
CONFIG_NET_RPL=y
CONFIG_NET_DEBUG_RPL=y
CONFIG_NET_RPL_GROUNDED=y
CONFIG_NET_RPL_MAX_DAG_PER_INSTANCE=1
CONFIG_NET_RPL_PREFIX="2001:db8::1/64"

# IPv6 (L3)
CONFIG_NET_IPV6=y

# 6LoWPAN (L2 - Adaptation Layer)
CONFIG_NET_6LO=y

# 802.15.4 (L2)
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_FRAGMENT=y

# 802.15.4 (L1)
CONFIG_IEEE802154_UPIPE=y

# Enabled Shell Extensions
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154_SHELL=y

# Disable default Ethernet interface
CONFIG_NET_SLIP_TAP=n

# Application Settings
CONFIG_NET_APP_SETTINGS=y
CONFIG_NET_APP_MY_IPV6_ADDR="2001:db8::1"
'''

In leaf node:
'''
CONFIG_NET_RPL=y
CONFIG_NET_DEBUG_RPL=y
CONFIG_NET_RPL_MAX_DAG_PER_INSTANCE=1

# IPv6 (L3)
CONFIG_NET_IPV6=y

# 6LoWPAN (L2 - Adaptation Layer)
CONFIG_NET_6LO=y

# 802.15.4 (L2)
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_FRAGMENT=y

# 802.15.4 (L1)
CONFIG_IEEE802154_UPIPE=y

# Enabled Shell Extensions
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154_SHELL=y

# Disable default Ethernet interface
CONFIG_NET_SLIP_TAP=n
'''

This way, I was able to run the example fine. The root published the prefix in DIO messages, the leaf node joined the DAG with DAO and I managed to ping between hosts using net shell.

My problems started when I tried to simulate a global repair scenario, rebooting the root node. To achieve this, it was necessary to modify some environments configurations.

To setup the QEMU environment I created the pipes manually and disabled removing/creation commands from zephyr/cmake/qemu/CMakeLists.txt in QEMU_NET_STACK session. This way when the 'server' node is rebooted the connection is not lost in the 'client' caused by the pipes recreation.

Also needed to modify get_mac() function from ieee802154_uart_pipe driver to assure that the MAC address assigned to the root node will be always the same:
'''
static inline u8_t *get_mac(struct device *dev)
{
struct upipe_context *upipe = dev->driver_data;


upipe->mac_addr[0] = 0x00;
upipe->mac_addr[1] = 0x10;
upipe->mac_addr[2] = 0x20;
upipe->mac_addr[3] = 0x30;

#if defined(CONFIG_NET_RPL_GROUNDED)
upipe->mac_addr[4] = 0xAA;
upipe->mac_addr[5] = 0xAA;
upipe->mac_addr[6] = 0xAA;
upipe->mac_addr[7] = 0xAA;
#else
UNALIGNED_PUT(sys_cpu_to_be32(sys_rand32_get()),
      (u32_t *) ((void *)upipe->mac_addr+4));
#endif

return upipe->mac_addr;
}
'''

Now I run both applications and wait the network to be configured. After that, I kill the root node, update the constant CURRENT_VERSION in main.c to 240, recompile and rerun it.

The leaf node receives the DIO messages from the root with the new version and and trigger the global repair. During this process it removes the old neighbors/parents and try to setup the new one.

'''
[net/rpl] [DBG] handle_dio: (0x20000558): Received DODAG Information Object from fe80::210:2030:aaaa:aaaa to ff02::1a
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO len 72 id 30 ver 241 rank 256
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO dag_id 2001:db8::1 pref 0
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 4 length 14
[net/rpl] [DBG] handle_dio: (0x20000558): DAG conf dbl 8 min 12 red 10 maxinc 1792 mininc 256 ocp 1 d_l 255 l_u 65535
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 8 length 30
[net/rpl] [DBG] handle_dio: (0x20000558): Prefix 2001:db8::/64
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Global repair
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Prefix announced in DIO
[net/rpl] [DBG] net_rpl_set_prefix: (0x20000558): Prefix is non-NULL, will announce this in DIOs
[net/rpl] [DBG] check_prefix: (0x20000558): Same prefix 2001:db8::/64 flags 0x40
[net/rpl] [DBG] remove_parents: (0x20000558): Removing parents minimum rank 0
[net/rpl] [DBG] net_rpl_remove_parent: (0x20000558): Removing parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Removing default route fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_dao_send: (0x20000558): Send DAO with prefix 2001:db8::210:2030:9b:9856 from fe80::210:2030:9b:9856 to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent not set
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Nullifying parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_mrhof_reset: (0x20000558): Reset MRHOF
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Add parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] nbr_add: (0x20000558): nbr linking failure (-69)
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Cannot add RPL neighbor
[net/rpl] [DBG] global_repair: (0x20000558): Failed to add a parent during the global repair
[net/rpl] [DBG] global_repair: (0x20000558): Participating in a global repair version 241 rank 65535
'''

I think it should send a DAO message to the root to rejoin the network if everything is ok, but as we can see in the log it doesn't went right.

I tried to discover the reason why it was unable to add the parent, starting from nbr_add(). I reached to net_nbr_link() function from nbr.c and clearly it failed because of idx check (-EALREADY = -69):
'''
if (nbr->idx != NET_NBR_LLADDR_UNKNOWN) {
return -EALREADY;
}
'''

I don't understand properly the neighbor structures and organization from zephyr to reach any conclusion here, but seems the neighbor passed as argument to net_nbr_link() is not properly cleared as the function expects.

After expending some time on gdb, I verified that the neighbor passed as an argument is the same which was removed right before global repair process. This brings me to net_rpl_neighbor_data_remove() function from rpl.c, which just prints a message and doesn't clear nbr.

Based on this I did a stupid test adding a line to net_rpl_neighbor_data_remove(), just to check what would happen: 
'''
nbr->idx = 0xff;
'''

After rerunning the case I got the RPL network restablished.

'''
[net/rpl] [DBG] handle_dio: (0x20000558): Received DODAG Information Object from fe80::210:2030:aaaa:aaaa to ff02::1a
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO len 72 id 30 ver 241 rank 256
[net/rpl] [DBG] handle_dio: (0x20000558): Incoming DIO dag_id 2001:db8::1 pref 0
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 4 length 14
[net/rpl] [DBG] handle_dio: (0x20000558): DAG conf dbl 8 min 12 red 10 maxinc 1792 mininc 256 ocp 1 d_l 255 l_u 65535
[net/rpl] [DBG] handle_dio: (0x20000558): DIO option 8 length 30
[net/rpl] [DBG] handle_dio: (0x20000558): Prefix 2001:db8::/64
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Global repair
[net/rpl] [DBG] net_rpl_process_dio: (0x20000558): Prefix announced in DIO
[net/rpl] [DBG] net_rpl_set_prefix: (0x20000558): Prefix is non-NULL, will announce this in DIOs
[net/rpl] [DBG] check_prefix: (0x20000558): Same prefix 2001:db8::/64 flags 0x40
[net/rpl] [DBG] remove_parents: (0x20000558): Removing parents minimum rank 0
[net/rpl] [DBG] net_rpl_remove_parent: (0x20000558): Removing parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Removing default route fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_dao_send: (0x20000558): Send DAO with prefix 2001:db8::210:2030:9c:475a from fe80::210:2030:9c:475a to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent not set
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_nullify_parent: (0x20000558): Nullifying parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] nbr_free: (0x20000558): nbr 0x200062b0
[net/rpl] [DBG] net_rpl_neighbor_data_remove: (0x20000558): Neighbor 0x200062b0 removed
[net/rpl] [DBG] net_rpl_mrhof_reset: (0x20000558): Reset MRHOF
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): Add parent fe80::210:2030:aaaa:aaaa [00:10:20:30:AA:AA:AA:AA]
[net/rpl] [DBG] nbr_add: (0x20000558): [0] nbr 0x200062b0 IPv6 fe80::210:2030:aaaa:aaaa ll 00:10:20:30:AA:AA:AA:AA iface 0x200067a0
[net/rpl] [DBG] net_rpl_add_parent: (0x20000558): [0] nbr 0x200062b0 parent 0x200062c4
[net/rpl] [DBG] global_repair: (0x20000558): Starting global repair
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): Preferred parent fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_set_preferred_parent: (0x20000558): It used to be not set
[net/rpl] [DBG] net_rpl_set_default_route: (0x20000558): Adding default route through fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_select_dag: (0x20000558): Changed preferred parent, rank changed from 768 to 768
[net/rpl] [DBG] schedule_dao: (0x20000558): Scheduling DAO timer 4800 ms in the future
[net/rpl] [DBG] dao_timer: (0x20000cb0): Sending DAO iface 0x200067a0
[net/rpl] [DBG] net_rpl_dao_send: (0x20000cb0): Send DAO with prefix 2001:db8::210:2030:9c:475a from fe80::210:2030:9c:475a to fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] net_rpl_link_neighbor_callback: (0x2000060c): Neighbor link callback triggering update
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Received Destination Advertisement Object Ack from fe80::210:2030:aaaa:aaaa to fe80::210:2030:9c:475a
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Received a DAO ACK with seq number 244(244) status 0 from fe80::210:2030:aaaa:aaaa
[net/rpl] [DBG] handle_dao_ack: (0x20000558): Status ACK
'''

Clearly my approach wasn't correct, I don't even understand properly the neighbor dynamics. Did I miss something in my setup which might have caused this behavior? Or there are something wrong on neighbor management?

Thank you!

--
Att,
Pedro Martucci
---
Gerência de Tecnologias de Controle e Inteligência de Sistemas
CPqD - Diretoria de Tecnologias de Comunicação
Tel.: +55 19 3705-5995


Re: button1 GPIOTE interrupt enable for NRF52840_PCA10056

Carles Cufi
 

Hi Vikrant,

 

Why don’t you use the existing GPIO driver?

https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/gpio/gpio_nrf5.c

 

It works with the button sample.

 

Regards,

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Vikrant More
Sent: 28 November 2017 14:32
To: zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-devel] button1 GPIOTE interrupt enable for NRF52840_PCA10056

 

Hello,

I want to enable GPIOTE interrupt for for Button1. For that I write

void GPIOTE_IRQHandler(void *arg)
{

 

  if(NRF_GPIOTE->EVENTS_IN[0]!=0)
  {
    NRF_GPIOTE->EVENTS_IN[0]=0;

    NRF_P0->OUT ^= (1<<16);

  }
}

void gpio_init(void)
{

 

 

  NRF_P0->DIR |= 0x0001E000;           // for LEDs
  NRF_P0->OUTSET |= 0x0001E000;   // for LEDs

 

 

 

  NRF_P0->PIN_CNF[11]=0x0000000C;   // for making P0.11 as input

  NRF_GPIOTE->INTENSET |= 0x00000001;                         
  NRF_GPIOTE->CONFIG[0] |= 0x00000001 | (11<<8) | (2<<16);

  NVIC_EnableIRQ(GPIOTE_IRQn);
}

 

I am able to compile code successfully & as per my understanding after pressing Button1,

Led4 should toggle on every click.

 

But I think interrupt is not get executed.

 

 

Could anybody help me to solve this issue ?

 

 

How to rewrite logic as per it ? how to modify prj.conf ?

 

 

Thank You!!


button1 GPIOTE interrupt enable for NRF52840_PCA10056

Vikrant More <vikrant8051@...>
 

Hello,
I want to enable GPIOTE interrupt for for Button1. For that I write

void GPIOTE_IRQHandler(void *arg)
{
 
  if(NRF_GPIOTE->EVENTS_IN[0]!=0)
  {
    NRF_GPIOTE->EVENTS_IN[0]=0;

    NRF_P0->OUT ^= (1<<16);

  }
}

void gpio_init(void)
{


  NRF_P0->DIR |= 0x0001E000;           // for LEDs
  NRF_P0->OUTSET |= 0x0001E000;   // for LEDs

 

  NRF_P0->PIN_CNF[11]=0x0000000C;   // for making P0.11 as input

  NRF_GPIOTE->INTENSET |= 0x00000001;                         
  NRF_GPIOTE->CONFIG[0] |= 0x00000001 | (11<<8) | (2<<16);

  NVIC_EnableIRQ(GPIOTE_IRQn);
}

I am able to compile code successfully & as per my understanding after pressing Button1,
Led4 should toggle on every click.

But I think interrupt is not get executed.


Could anybody help me to solve this issue ?


How to rewrite logic as per it ? how to modify prj.conf ?


Thank You!!


Re: mesh: bt_mesh_model_publish called with BT_MESH_ADDR_UNASSIGNED

Johan Hedberg
 

Hi Steve,

On Tue, Nov 28, 2017, Steve Brown wrote:
Mesh spec 3.4.2.1 suggests that setting the publish address to the
unassigned address can be used to disable publishing.
Yes, and this is how it's implemented if you look at the _mod_pub_set()
function in cfg_srv.c.

However, the current implementation returns -EADDRNOTAVAIL.

Why doesn't bt_mesh_model_publish silently exit?
Do you mean why doesn't bt_mesh_model_publish() return 0 in this case? I
can imagine arguments for both ways. Wouldn't it be good for the app to
know that its attempts to send out data are not going anywhere? That
said, I'm not sure that -EADDRNOTAVAIL is the best choice here,
considering it's also used for when the publication app key is not
available. Perhaps -EAGAIN might make more sense since it conveys a more
temporary situation.

Johan


mesh: bt_mesh_model_publish called with BT_MESH_ADDR_UNASSIGNED

Steve Brown
 

Mesh spec 3.4.2.1 suggests that setting the publish address to the
unassigned address can be used to disable publishing.

However, the current implementation returns -EADDRNOTAVAIL.

Why doesn't bt_mesh_model_publish silently exit?

Steve


Success in testing of Silicon Labs Bluetooth Mesh APP with Zephyr

Vikrant More <vikrant8051@...>
 

static void gen_onoff_set_unack(struct bt_mesh_model *model,
                struct bt_mesh_msg_ctx *ctx,
                struct net_buf_simple *buf)
{   

        unsigned char tmp = net_buf_simple_pull_u8(buf);

    printk("Data = %u\n\r",tmp);
   
        switch(tmp)
        {
        case 1:   
                NRF_P0->OUT &= ~(1<<13);
                break;
            case 0:
                NRF_P0->OUTSET |= (1<<13);                             
                                break;   
     }
}

//----------------------------------------------------------------------------------------------------------------------------------

static const struct bt_mesh_prov prov = {
    .uuid = dev_uuid,
    //.output_size = 4,
    //.output_actions = BT_MESH_DISPLAY_NUMBER,
    //.output_number = output_number,
    .complete = prov_complete,
    .reset = prov_reset,
};

-----------------------------------------------------------------------------------------------------------------------------------
I modified gen_onoff_set_unack & struct bt_mesh_prov from $zephyr/samples/bluetooth/mesh/src/main.c as mentioned above.
And there should be only one active element. If we add more than one element then App throws "DCD request error".

Now after these modifications, I am able to provision & configure nrf52840_pca10056 board.

Plus I am able to control LED1 on all boards (after provisioning) using same Android App.

Thank You !!



Re: BLE frequency hopping

Chettimada, Vinayak Kariappa
 

Hi Jie,


On 27 Nov 2017, at 00:43, Jie Zhou <zhoujie@hawaii.edu> wrote:

Hello,

I'm trying to implement a simple random frequency hopping to avoid frequency clashes. I see in zephyr that there are channel map settings, but I can't seem to find documentations on what settings does what. How would I implement frequency hopping in, let's say, the bluetooth adv sample?
Zephyr BLE controller implements the Bluetooth Specification version 5.0 Data Channel Selection, please refer to section 4.5.8 in Vol 6, Part B.

For advertising and scanning states in BLE (exclude extending advertising), channels 37, 38, and 39 are used in consecutive order when transmitting or receiving.
Currently, if I am right, there is no public interfaces to control channel hopping. You could use the BLE controller HCI interface (samples/bluetooth/hci_uart or hci_spi) with other host implementations on second chip/PC that use standard HCI commands as defined in the BT specification.

Please clarify which sample are you using from the Zephyr project repository "let's say, the bluetooth adv sample” ?


(Addition question, not presently critical so I don't need an answer right now)
I also saw that zephyr has channel map settings to access 37 frequency channels. Firstly how can I access that? Secondly, reading the BlueZ specifications, there are 79 total bluetooth frequency channels and to implement adaptive frequency hopping, 79 channels is required. Does zephyr have that capability?

Thanks to all,
Jie
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: About publish & subscribe mechanism in Bluetooth Mesh

Vikrant More <vikrant8051@...>
 

#define BT_MESH_MODEL(_id, _op, _pub, _user_data)                             \
{                                                                                                                     \
.id = (_id),                                                                                              \
.op = _op,                                                                                              \
.keys = { [0 ... (CONFIG_BT_MESH_MODEL_KEY_COUNT - 1)] =    \
BT_MESH_KEY_UNUSED },                                                \
.pub = _pub,                                                                                           \
.groups = {0xC000},                                                                               \
.user_data = _user_data,                                                                       \
}


I edit BT_MESH_MODEL macro definition from  #zephyr/include/bluetooth/mesh/access.h as  mentioned above,
so that every model get subscribed to 0xC000 group address.

I am able to publish (using bt_mesh_model_send() this API)data to Nodes which are subsribing to 0xC000.

For that I write button interrupt code as follow on Publisher node:

void board_button_1_pressed(void)
{
struct net_buf_simple *msg1 = NET_BUF_SIMPLE(2 + 4 + 1);
struct bt_mesh_msg_ctx ctx1 = {
.net_idx = 0,
.app_idx = 1,
.addr = 0xC000,
.send_ttl = BT_MESH_TTL_DEFAULT,
};

/* Bind to Health model */
bt_mesh_model_msg_init(msg1 , BT_MESH_MODEL_OP_2(0x82, 0x02) );

       net_buf_simple_add_u8(msg1,0x5A); // 0x55 == any data

if (bt_mesh_model_send(&vnd_models[0], &ctx1, msg1, NULL, NULL)) {
printk("Unable to send Vendor Button message\n");
}

}


After accessing one of the Subscriber serial terminal, it is conform that it is receiving something from src=0x0100(Publisher Unicast Address).

But I don't know where I will find 0x5A at subscriber side which is value send by Publisher ??



On Mon, Nov 27, 2017 at 1:17 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Mon, Nov 27, 2017, Vikrant More wrote:
> How to send simple one byte of data from one node to another node which are
> provisioned using meshctl using unicast addresses ?

Mesh application payloads always start with a model-specific OpCode,
which is 1-3 bytes long. So if you want to send valid data you'd need to
do that in the context of a model, and in that case you'd use the
bt_mesh_model_publish() or bt_mesh_model_send() APIs.

If you want to discard the access layer formatting (i.e. OpCode +
payload) and send arbitrary "raw" application payloads, you could use
the "net-send" command that the mesh_shell app provides, however note
that this is purely for testing purposes and can't be used for building
final products.

> >>For subscribing you don't need anything >>special, except that a
> >>provisioner configures one or more >>subscription addresses to your
> >>models.
>
> How to achieve this using available meshctl commands ?

I'm not really familiar with meshctl, but looking at its source code it
seems to at least provide a "set-pub" command under the "config" submenu.
I don't see anything related to subscription there however. For testing
purposes you could also again use the Zephyr mesh_shell app since it can
send messages to itself. The shell provides "mod-pub" and "mod-sub-add"
commands for this.

Btw, if you want more help with meshctl, I recommend reaching out on
the BlueZ forums, i.e. the #bluez IRC channel on freenode and the
linux-bluetooth mailing list.

Johan


net_pkt_get(), net_pkt_append() queries

Vakul Garg <vakul.garg@...>
 

Hi

 

In function net_pkt_get(), it seems it does not take into account subtracting IPv4/IPv6 header length while setting pkt->data_len.

Also, in function net_pkt_append(), I do not understand, why max_len is overwritten with TCP send_mss.

 

Can someone please check?

 

Thanks & Regards

 

Vakul

 

 


Re: State Change and Periodic Publishing

Johan Hedberg
 

Hi Steve,

On Sun, Nov 26, 2017, Steve Brown wrote:
I need help clarifying my understanding of section 3.7.6.1 (Publish) of
the mesh spec.

As I read it, my onoff server would be responsible for publishing
status after a state change. I suspect it would always call
bt_mesh_model_publish for if publish wasn't enabled, nothing would be
output.

If periodic publishing is also enabled, the mesh stack would republish
the state change status message without any intervention by the onoff
server.

Is this the correct interpretation?
Yes, or at least that's how I interpret the spec myself as well. Well,
"without any intervention" isn't quite right, since to support periodic
publishing the model needs to provide an "update" callback which the
stack will call periodically. The intention of this callback is to let
the app update the content of pub->msg, however if there's nothing to be
updated (the buffer already has the right content) then the function
would do nothing, i.e. just return success (0).

Johan

4201 - 4220 of 7929