Date   

Re: [Zephyr-devel] 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: [Zephyr-devel] RPL Tests

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@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


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: [Zephyr-devel] 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!!


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


Re: L2CAP errors on linux while running 6loble

Vakul Garg <vakul.garg@...>
 

Adding steps to reproduce the problem.

 

I am running samples/net/http_server and trying to download a file from it of size 4000 bytes.

Instead of Ethernet, I use 6loble link between zephyr and linux.

 

The changes that have been made to sample application are given below.

To download index.html from zephyr host, execute from linux (after connecting ble link, attaching IP address etc).

 

wget -6 http://[2001:db8::1]/index.html

 

 

 

[b16394@lti http_server]$ git diff src/main.c

diff --git a/samples/net/http_server/src/main.c b/samples/net/http_server/src/main.c

index 32d3fa13f..43e9e8e87 100644

--- a/samples/net/http_server/src/main.c

+++ b/samples/net/http_server/src/main.c

@@ -16,6 +16,7 @@

 #include <zephyr.h>

#include <stdio.h>

+#include <stdlib.h>

 #include <net/net_context.h>

@@ -215,10 +216,11 @@ int http_serve_headers(struct http_ctx *ctx)

 static int http_serve_index_html(struct http_ctx *ctx)

{

-       static const char index_html[] = {

-#include "index.html.inc"

+       static const char index_html[4000] = {

+//#include "index.html.inc"

        };

+

        NET_DBG("Sending index.html (%zd bytes) to client",

                sizeof(index_html));

 

 

 

 

diff --git a/samples/net/http_server/prj.conf b/samples/net/http_server/prj.conf

index 14b6ec8b5..8cb00ad40 100644

--- a/samples/net/http_server/prj.conf

+++ b/samples/net/http_server/prj.conf

@@ -46,3 +46,29 @@ CONFIG_NET_STATISTICS=y

 CONFIG_NET_MGMT=y

CONFIG_NET_MGMT_EVENT=y

+

+CONFIG_BT=y

+CONFIG_NET_L2_BT=y

+CONFIG_NET_L2_BT_ZEP1656=n

+

+CONFIG_BT_DEBUG_LOG=y

+CONFIG_BT_SMP=y

+CONFIG_BT_PERIPHERAL=y

+CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y

+CONFIG_BT_DEVICE_NAME="http_server"

+CONFIG_NET_APP_BT_NODE=y

+CONFIG_NET_SHELL=y

+CONFIG_BT_SHELL=y

+CONFIG_NET_L2_ETHERNET=n

+CONFIG_ETH_MCUX_0=n

+CONFIG_BT_PRIVACY=n

+CONFIG_BT_DEBUG=y

+CONFIG_BT_DEBUG_HCI_CORE=n

+CONFIG_BT_DEBUG_CONN=n

+CONFIG_BT_DEBUG_KEYS=n

+CONFIG_BT_DEBUG_L2CAP=n

+CONFIG_BT_DEBUG_SMP=n

+CONFIG_BT_DEBUG_SDP=n

+

+CONFIG_NET_DEBUG=y

+CONFIG_NET_DEBUG_TCP=y

 

From: Vakul Garg
Sent: Monday, November 27, 2017 4:42 PM
To: 'Cufi, Carles' <Carles.Cufi@...>
Cc: zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

It seems that there are issues in multiple places.

 

First one, I encounter is the following log:

 

[bt] [ERR] bt_l2cap_chan_send: failed to send message -36

 

Digging deeper, I find that the function net_pkt_get() does not take into account Ipv4/v6 header lengths while calculating pkt->data_len.

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

 

The same questions I just now asked over zephyr-devel.

I am sorry for the duplication.

 

Regards

 

Vakul

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Monday, November 27, 2017 4:35 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

Right, so now we know that this is an issue with the Zephyr side, either on the Host or Controller side.

 

Maybe Luiz can shed some light into this. Perhaps if you send exact instructions on how to reproduce the issue by providing the code and the configuration files?

 

Regards,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 27 November 2017 06:41
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

I tried again with a standard dongle for linux controller. (I used CSR 4.0 dongle as mentioned in the link below.)

The behavior is the same.

 

The linux kernel sometimes reports error:
“Bluetooth: Too much LE L2CAP data received

 

On zephyr side also, I can that l2cap does not like the size of SDU.

Function l2cap_chan_le_send_sdu() finds that the total_len is more than channel’s tx mtu.

 

So I believe that the SDUs sometime get generated beyond allowable size by zephyr side.

 

Regards

 

Vakul

 

PS: I am using sample/net/https_server with a bigger index_html (2000 bytes).

File size around 1100 byte work ok.

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:39 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Any 4.0 dongle should work fine, but maybe  Johan or Luiz can let us know of their favorite ones, since they test more often with dongles than myself.

I personally use the Intel controller that is built into my laptop.

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 15:04
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Ok, I will buy a standard dongle for linux controller.

Can you suggest which one to buy?

Is this one ok?

 

https://www.amazon.in/GENERIC-Ultra-Mini-Bluetooth-Dongle-Adapter/dp/B0117H7GZ6/ref=sr_1_2?ie=UTF8&qid=1511359408&sr=8-2&keywords=bluetooth+dongle+for+desktop

 

Regards,

Vakul

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:32 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

The reason I ask is that I’ve seen similar issues with our boards (nRF5x) when we had issues in the HCI flow control.

Is there a chance you can test replacing the Linux controller with a “standard” one (the PTS dongle or any Bluetooth 4.0+ dongle you have) to see which side is introducing the issue?

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 14:59
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

Thanks for paying attention to this.

I am running latest zephyr from master branch on nxp board frdm_k64f.

The k64f board is connected to another nxp board frdm_kw41z.

Kw41z board runs nxp ble controller firmware (based on freertos).

 

On linux side as well, it is another frdm_kw41z board (connected through usb) acting as ble controller.

 

Regards

 

Vakul

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:15 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

Could you share a bit more info about the Zephyr endpoint? Which board/chip are you using, what Zephyr version and whether this is a single-chip or dual-chip solution?

Also on the Linux side, what controller are you using? Is it Zephyr-based? If so, which Zephyr version and hardware?

 

Thanks,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: 22 November 2017 11:24
To: zephyr-users@...
Subject: [Zephyr-users] L2CAP errors on linux while running 6loble

 

Hi

 

I am transferring UDP packets over 6loble link between a zephyr endpoint and linux box.

On my linux box, I see errors:

 

[root@lti ~]# dmesg

[416975.584892] Bluetooth: Too much LE L2CAP data received

[416976.365482] Bluetooth: Too much LE L2CAP data received

[416977.171158] Bluetooth: Frame is too long (len 186, expected len 68)

[416977.566971] Bluetooth: Too much LE L2CAP data received

 

Can someone please provide some hint what could I be doing wrong?

I am using linux kernel version 4.13.12.

 

Regards

 

Vakul


Re: L2CAP errors on linux while running 6loble

Vakul Garg <vakul.garg@...>
 

Hi Carles

 

It seems that there are issues in multiple places.

 

First one, I encounter is the following log:

 

[bt] [ERR] bt_l2cap_chan_send: failed to send message -36

 

Digging deeper, I find that the function net_pkt_get() does not take into account Ipv4/v6 header lengths while calculating pkt->data_len.

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

 

The same questions I just now asked over zephyr-devel.

I am sorry for the duplication.

 

Regards

 

Vakul

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Monday, November 27, 2017 4:35 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

Right, so now we know that this is an issue with the Zephyr side, either on the Host or Controller side.

 

Maybe Luiz can shed some light into this. Perhaps if you send exact instructions on how to reproduce the issue by providing the code and the configuration files?

 

Regards,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 27 November 2017 06:41
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

I tried again with a standard dongle for linux controller. (I used CSR 4.0 dongle as mentioned in the link below.)

The behavior is the same.

 

The linux kernel sometimes reports error:
“Bluetooth: Too much LE L2CAP data received

 

On zephyr side also, I can that l2cap does not like the size of SDU.

Function l2cap_chan_le_send_sdu() finds that the total_len is more than channel’s tx mtu.

 

So I believe that the SDUs sometime get generated beyond allowable size by zephyr side.

 

Regards

 

Vakul

 

PS: I am using sample/net/https_server with a bigger index_html (2000 bytes).

File size around 1100 byte work ok.

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:39 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Any 4.0 dongle should work fine, but maybe  Johan or Luiz can let us know of their favorite ones, since they test more often with dongles than myself.

I personally use the Intel controller that is built into my laptop.

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 15:04
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Ok, I will buy a standard dongle for linux controller.

Can you suggest which one to buy?

Is this one ok?

 

https://www.amazon.in/GENERIC-Ultra-Mini-Bluetooth-Dongle-Adapter/dp/B0117H7GZ6/ref=sr_1_2?ie=UTF8&qid=1511359408&sr=8-2&keywords=bluetooth+dongle+for+desktop

 

Regards,

Vakul

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:32 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

The reason I ask is that I’ve seen similar issues with our boards (nRF5x) when we had issues in the HCI flow control.

Is there a chance you can test replacing the Linux controller with a “standard” one (the PTS dongle or any Bluetooth 4.0+ dongle you have) to see which side is introducing the issue?

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 14:59
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

Thanks for paying attention to this.

I am running latest zephyr from master branch on nxp board frdm_k64f.

The k64f board is connected to another nxp board frdm_kw41z.

Kw41z board runs nxp ble controller firmware (based on freertos).

 

On linux side as well, it is another frdm_kw41z board (connected through usb) acting as ble controller.

 

Regards

 

Vakul

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:15 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

Could you share a bit more info about the Zephyr endpoint? Which board/chip are you using, what Zephyr version and whether this is a single-chip or dual-chip solution?

Also on the Linux side, what controller are you using? Is it Zephyr-based? If so, which Zephyr version and hardware?

 

Thanks,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: 22 November 2017 11:24
To: zephyr-users@...
Subject: [Zephyr-users] L2CAP errors on linux while running 6loble

 

Hi

 

I am transferring UDP packets over 6loble link between a zephyr endpoint and linux box.

On my linux box, I see errors:

 

[root@lti ~]# dmesg

[416975.584892] Bluetooth: Too much LE L2CAP data received

[416976.365482] Bluetooth: Too much LE L2CAP data received

[416977.171158] Bluetooth: Frame is too long (len 186, expected len 68)

[416977.566971] Bluetooth: Too much LE L2CAP data received

 

Can someone please provide some hint what could I be doing wrong?

I am using linux kernel version 4.13.12.

 

Regards

 

Vakul


Re: L2CAP errors on linux while running 6loble

Carles Cufi
 

Hi Vakul,

 

Right, so now we know that this is an issue with the Zephyr side, either on the Host or Controller side.

 

Maybe Luiz can shed some light into this. Perhaps if you send exact instructions on how to reproduce the issue by providing the code and the configuration files?

 

Regards,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 27 November 2017 06:41
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

I tried again with a standard dongle for linux controller. (I used CSR 4.0 dongle as mentioned in the link below.)

The behavior is the same.

 

The linux kernel sometimes reports error:
“Bluetooth: Too much LE L2CAP data received

 

On zephyr side also, I can that l2cap does not like the size of SDU.

Function l2cap_chan_le_send_sdu() finds that the total_len is more than channel’s tx mtu.

 

So I believe that the SDUs sometime get generated beyond allowable size by zephyr side.

 

Regards

 

Vakul

 

PS: I am using sample/net/https_server with a bigger index_html (2000 bytes).

File size around 1100 byte work ok.

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:39 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Any 4.0 dongle should work fine, but maybe  Johan or Luiz can let us know of their favorite ones, since they test more often with dongles than myself.

I personally use the Intel controller that is built into my laptop.

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 15:04
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Ok, I will buy a standard dongle for linux controller.

Can you suggest which one to buy?

Is this one ok?

 

https://www.amazon.in/GENERIC-Ultra-Mini-Bluetooth-Dongle-Adapter/dp/B0117H7GZ6/ref=sr_1_2?ie=UTF8&qid=1511359408&sr=8-2&keywords=bluetooth+dongle+for+desktop

 

Regards,

Vakul

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:32 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

The reason I ask is that I’ve seen similar issues with our boards (nRF5x) when we had issues in the HCI flow control.

Is there a chance you can test replacing the Linux controller with a “standard” one (the PTS dongle or any Bluetooth 4.0+ dongle you have) to see which side is introducing the issue?

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 14:59
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

Thanks for paying attention to this.

I am running latest zephyr from master branch on nxp board frdm_k64f.

The k64f board is connected to another nxp board frdm_kw41z.

Kw41z board runs nxp ble controller firmware (based on freertos).

 

On linux side as well, it is another frdm_kw41z board (connected through usb) acting as ble controller.

 

Regards

 

Vakul

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:15 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

Could you share a bit more info about the Zephyr endpoint? Which board/chip are you using, what Zephyr version and whether this is a single-chip or dual-chip solution?

Also on the Linux side, what controller are you using? Is it Zephyr-based? If so, which Zephyr version and hardware?

 

Thanks,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: 22 November 2017 11:24
To: zephyr-users@...
Subject: [Zephyr-users] L2CAP errors on linux while running 6loble

 

Hi

 

I am transferring UDP packets over 6loble link between a zephyr endpoint and linux box.

On my linux box, I see errors:

 

[root@lti ~]# dmesg

[416975.584892] Bluetooth: Too much LE L2CAP data received

[416976.365482] Bluetooth: Too much LE L2CAP data received

[416977.171158] Bluetooth: Frame is too long (len 186, expected len 68)

[416977.566971] Bluetooth: Too much LE L2CAP data received

 

Can someone please provide some hint what could I be doing wrong?

I am using linux kernel version 4.13.12.

 

Regards

 

Vakul


Re: About publish & subscribe mechanism in Bluetooth Mesh

Johan Hedberg
 

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


Re: L2CAP errors on linux while running 6loble

Vakul Garg <vakul.garg@...>
 

Hi Carles

 

I tried again with a standard dongle for linux controller. (I used CSR 4.0 dongle as mentioned in the link below.)

The behavior is the same.

 

The linux kernel sometimes reports error:
“Bluetooth: Too much LE L2CAP data received

 

On zephyr side also, I can that l2cap does not like the size of SDU.

Function l2cap_chan_le_send_sdu() finds that the total_len is more than channel’s tx mtu.

 

So I believe that the SDUs sometime get generated beyond allowable size by zephyr side.

 

Regards

 

Vakul

 

PS: I am using sample/net/https_server with a bigger index_html (2000 bytes).

File size around 1100 byte work ok.

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:39 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Any 4.0 dongle should work fine, but maybe  Johan or Luiz can let us know of their favorite ones, since they test more often with dongles than myself.

I personally use the Intel controller that is built into my laptop.

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 15:04
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Ok, I will buy a standard dongle for linux controller.

Can you suggest which one to buy?

Is this one ok?

 

https://www.amazon.in/GENERIC-Ultra-Mini-Bluetooth-Dongle-Adapter/dp/B0117H7GZ6/ref=sr_1_2?ie=UTF8&qid=1511359408&sr=8-2&keywords=bluetooth+dongle+for+desktop

 

Regards,

Vakul

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:32 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

The reason I ask is that I’ve seen similar issues with our boards (nRF5x) when we had issues in the HCI flow control.

Is there a chance you can test replacing the Linux controller with a “standard” one (the PTS dongle or any Bluetooth 4.0+ dongle you have) to see which side is introducing the issue?

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 14:59
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

Thanks for paying attention to this.

I am running latest zephyr from master branch on nxp board frdm_k64f.

The k64f board is connected to another nxp board frdm_kw41z.

Kw41z board runs nxp ble controller firmware (based on freertos).

 

On linux side as well, it is another frdm_kw41z board (connected through usb) acting as ble controller.

 

Regards

 

Vakul

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:15 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

Could you share a bit more info about the Zephyr endpoint? Which board/chip are you using, what Zephyr version and whether this is a single-chip or dual-chip solution?

Also on the Linux side, what controller are you using? Is it Zephyr-based? If so, which Zephyr version and hardware?

 

Thanks,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: 22 November 2017 11:24
To: zephyr-users@...
Subject: [Zephyr-users] L2CAP errors on linux while running 6loble

 

Hi

 

I am transferring UDP packets over 6loble link between a zephyr endpoint and linux box.

On my linux box, I see errors:

 

[root@lti ~]# dmesg

[416975.584892] Bluetooth: Too much LE L2CAP data received

[416976.365482] Bluetooth: Too much LE L2CAP data received

[416977.171158] Bluetooth: Frame is too long (len 186, expected len 68)

[416977.566971] Bluetooth: Too much LE L2CAP data received

 

Can someone please provide some hint what could I be doing wrong?

I am using linux kernel version 4.13.12.

 

Regards

 

Vakul


Re: About publish & subscribe mechanism in Bluetooth Mesh

Vikrant More <vikrant8051@...>
 

How to send simple one byte of data from one node to another node which are provisioned using meshctl using unicast addresses ?

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

On Mon, Nov 27, 2017 at 12:41 AM, Vikrant More <vikrant8051@...> wrote:
How to send simple one byte of data from one node to another node which are provisioned using meshctl using unicast addresses ?

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


On Nov 26, 2017 7:22 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Sun, Nov 26, 2017, Vikrant More wrote:
> Is publish & subscribe mechanism only related with Group addresses ?
>
> Or we can add even unicast and virtual addresses in whitelist of Publish &
> Subscription list ?

You can find the answer in the Mesh Profile Specification. E.g. section
4.2.2.1 states: "The publish address shall be the unassigned address, a
unicast address, a Label UUID, or a group address".

> How to use these two structure:
>
> static struct bt_mesh_model_pub gen_level_pub;
> static struct bt_mesh_model_pub gen_onoff_pub;
>
> to create publish & subscribe model for testing ?

To make a model capable of publishing you need to give a reference to a
structure like that to the BT_MESH_MODEL() macro (the third parameter).
For subscribing you don't need anything special, except that a
provisioner configures one or more subscription addresses to your
models.

Johan



Job Opportunity for Zephyr Developers at ProGlove

Valentin Sawadski <valentin.sawadski@...>
 

Hi everyone,

it seems to me this mailing list is best suited for my message.  I apologize in advance in case I misread the Mailing List guidelines.

At ProGlove, we are looking for an Embedded Software Engineer (m/f) with experience in Networking & Bluetooth who wants to be a crucial part of the architecture and connectivity of our products. 

Your tasks and responsibilities will include:

- Enabling and supporting Bluetooth and 6lowPAN communication in Zephyr
- Researching and recommending wireless communication technology for our products
- Advising on distributed application architecture and design
- Implementing support for key protocols and applications such as LWM2M and IPSP

If you enjoy implementing wireless communication into our wearable products and design embedded networking applications? Then ProGlove is the place to be!


Best regards,
Valentin
--

Valentin Sawadski | CTO
valentin.sawadski@...
PGP: 91D3 6680 969 7C11


Workaround GmbH (ProGlove)  
Friedenstr. 4 | 81671 München


Managing Director: Thomas Kirchner 
HRB: 216605 | AG München 
USt.-IdNr.: DE298859320


Re: About publish & subscribe mechanism in Bluetooth Mesh

Johan Hedberg
 

Hi Vikrant,

On Sun, Nov 26, 2017, Vikrant More wrote:
Is publish & subscribe mechanism only related with Group addresses ?

Or we can add even unicast and virtual addresses in whitelist of Publish &
Subscription list ?
You can find the answer in the Mesh Profile Specification. E.g. section
4.2.2.1 states: "The publish address shall be the unassigned address, a
unicast address, a Label UUID, or a group address".

How to use these two structure:

static struct bt_mesh_model_pub gen_level_pub;
static struct bt_mesh_model_pub gen_onoff_pub;

to create publish & subscribe model for testing ?
To make a model capable of publishing you need to give a reference to a
structure like that to the BT_MESH_MODEL() macro (the third parameter).
For subscribing you don't need anything special, except that a
provisioner configures one or more subscription addresses to your
models.

Johan


About publish & subscribe mechanism in Bluetooth Mesh

Vikrant More <vikrant8051@...>
 

Is publish & subscribe mechanism only related with Group addresses ?

Or we can add even unicast and virtual addresses in whitelist of Publish & Subscription list ?

How to use these two structure: 

static struct bt_mesh_model_pub gen_level_pub;
static struct bt_mesh_model_pub gen_onoff_pub;
to create publish & subscribe model for testing ?




Running http_server sample over 6loble

Vakul Garg <vakul.garg@...>
 

Hi

 

I am running http_server example application with a 6loble link between a zephyr host and linux host.

The http_server example code has been modified to send 4000 bytes of index.html (instead of default size of 170 bytes).

 

In this case, I see that following error:

 

[bt] [ERR] bt_l2cap_chan_send: failed to send message -36

 

The error code means EMSGSIZE.

The l2cap function l2cap_chan_le_send_sdu() finds that the message fragment to be sent is bigger in size than MTU.

 

Further, I found that the data passed to http library function http_send_msg_raw() is converted to TCP segments, (IP headers added) and handed over to l2cap backed network interface.

The TCP functions do not create segment with the http data message passed by function http_send_flush() as per MTU size.

I see that http_prepare_and_send() prepares a net_pkt by adding several fragments and when it calls http_send_flush(), the size of net_pkt becomes more than allowed as per MTU.

The resultant segment size is bigger than that can be tolerated by l2cap and it results in above mentioned error log.

 

Can someone comment whether is this TCP behavior intentional?

 

Regards

 

Vakul

 

 

 


Re: L2CAP errors on linux while running 6loble

Vakul Garg <vakul.garg@...>
 

I get error logs on both linux and zephyr consoles.

Not sure if they come up together.

 

The data transfer is almost equal in both the directions.

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:42 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

I assume you see this on the Zephyr side. Since you are using a dual-chip solution there it could be that the Host is dropping packets, but that would be in the other direction (Linux to Zephyr), and here there seems to be an issue with the Zephyr to Linux side. You don’t see any errors printed on the Zephyr side at the same time you see the ones in Linux?

 

Which direction is the bulk of the data transfer taking place?

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 15:07
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

BTW, it seems my BLE controller does not support flow control.

During BLE init, following logs are printed.

 

[bt] [WRN] set_flow_control: Controller to host flow control not supported

[bt] [WRN] hci_vs_init: Vendor HCI extensions not available

 

From: Vakul Garg
Sent: Wednesday, November 22, 2017 7:34 PM
To: 'Cufi, Carles' <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Ok, I will buy a standard dongle for linux controller.

Can you suggest which one to buy?

Is this one ok?

 

https://www.amazon.in/GENERIC-Ultra-Mini-Bluetooth-Dongle-Adapter/dp/B0117H7GZ6/ref=sr_1_2?ie=UTF8&qid=1511359408&sr=8-2&keywords=bluetooth+dongle+for+desktop

 

Regards,

Vakul

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:32 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

The reason I ask is that I’ve seen similar issues with our boards (nRF5x) when we had issues in the HCI flow control.

Is there a chance you can test replacing the Linux controller with a “standard” one (the PTS dongle or any Bluetooth 4.0+ dongle you have) to see which side is introducing the issue?

 

Thanks,

 

Carles

 

From: Vakul Garg [mailto:vakul.garg@...]
Sent: 22 November 2017 14:59
To: Cufi, Carles <Carles.Cufi@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Carles

 

Thanks for paying attention to this.

I am running latest zephyr from master branch on nxp board frdm_k64f.

The k64f board is connected to another nxp board frdm_kw41z.

Kw41z board runs nxp ble controller firmware (based on freertos).

 

On linux side as well, it is another frdm_kw41z board (connected through usb) acting as ble controller.

 

Regards

 

Vakul

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Wednesday, November 22, 2017 7:15 PM
To: Vakul Garg <vakul.garg@...>; zephyr-users@...
Subject: RE: L2CAP errors on linux while running 6loble

 

Hi Vakul,

 

Could you share a bit more info about the Zephyr endpoint? Which board/chip are you using, what Zephyr version and whether this is a single-chip or dual-chip solution?

Also on the Linux side, what controller are you using? Is it Zephyr-based? If so, which Zephyr version and hardware?

 

Thanks,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: 22 November 2017 11:24
To: zephyr-users@...
Subject: [Zephyr-users] L2CAP errors on linux while running 6loble

 

Hi

 

I am transferring UDP packets over 6loble link between a zephyr endpoint and linux box.

On my linux box, I see errors:

 

[root@lti ~]# dmesg

[416975.584892] Bluetooth: Too much LE L2CAP data received

[416976.365482] Bluetooth: Too much LE L2CAP data received

[416977.171158] Bluetooth: Frame is too long (len 186, expected len 68)

[416977.566971] Bluetooth: Too much LE L2CAP data received

 

Can someone please provide some hint what could I be doing wrong?

I am using linux kernel version 4.13.12.

 

Regards

 

Vakul


Re: Questions about Bluetooth certification

Carles Cufi
 

Hi Laurence,

 

First, you understand correctly, the controller is qualified if you run Zephyr on a Nordic IC.

To qualify a Host you only need to provide evidence that it passes a suite of PTS (Profile Testing Suite) tests.

These tests are run regularly by members of the Zephyr project, but so far they have not been submitted for qualification yet.

 

That said, this is a fairly simple process that you could consider doing yourself if you want to speed up the qualification. You might want to talk to Intel members (in particular Johan Hedberg, whom I’ve copied) about obtaining the PTS evidence in a form you can submit directly to the Bluetooth SIG.

 

We do plan to qualify the Zephyr Host, but the timeline is uncertain due to administrative decisions that need to be taken prior to a qualification.

 

Thanks,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Laurence Pasteau
Sent: 22 November 2017 15:26
To: zephyr-users@...
Subject: [Zephyr-users] Questions about Bluetooth certification

 

Hello,

 

As a NRF52 user we would like to integrate to our solution an opensource OS in which we could take part. A study leads us in particular to zephyr.

However until now we use the fully qualified bluetooth nordic solution. If I correctly understand, the controller side of zephyr stack is qualified.

I wonder what brings the certification of the host part (we use BLE mainly for maintenance and configuration) ?

Is the host qualification forecast in zephyr project ?

Has someone already integrate the nordic firmware into zephyr ? It could be a good first solution before considering the qualification.

 

Thank you in advance for any advice or answer.

Regards,

Laurence

 

 

---

Laurence Pasteau

laurence.pasteau@...

1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou

www.stimio.fr

 

 


Questions about Bluetooth certification

Laurence Pasteau
 

Hello,


As a NRF52 user we would like to integrate to our solution an opensource OS in which we could take part. A study leads us in particular to zephyr.

However until now we use the fully qualified bluetooth nordic solution. If I correctly understand, the controller side of zephyr stack is qualified.

I wonder what brings the certification of the host part (we use BLE mainly for maintenance and configuration) ?

Is the host qualification forecast in zephyr project ?

Has someone already integrate the nordic firmware into zephyr ? It could be a good first solution before considering the qualification.


Thank you in advance for any advice or answer.

Regards,

Laurence



---

Laurence Pasteau

laurence.pasteau@...

1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou

www.stimio.fr

 


2421 - 2440 of 2730