apache / apache/mynewt-nimble

mesh: advertising and relay memory pool depletion after some time sending messages

Open
#486 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
893
Forks
512
Avg merge
13d 31m
Merged PRs (30d)
7

Description

**This is my mesh network:**

- **Number of Nodes:** 7

- **Type of Nodes:** Proxy

- **Models on Each Node:** Generic OnOff Client & Generic OnOff Server and required foundation models

- **Network configuration:** In a circular fashion where each node publishes to next node and subscribed to previous node. For example Node 1 is subscribed to Node 7 and publishes to Node 2; Node 2 is subscribed to Node 1 and publishes to Node 3 and so on. (I know this can be impelemented using Unicast Addresses however I am trying to implement my requirements.)

**What I am doing?** After network configuration with publish-subscribe addresses, I am sending a Generic OnOff Set message to Node 1, after receiving this message Node 1 publishes the same message to Node 2 and Node 2 will publish to Node 3 and so on the cycle continues.

I am using the address range C001, ... for publishing and subscribing.

**What problem I am having?** The application runs perfectly initially and as soon as the buffer pool runs out the application is not able to send any messages because of these two errors.

1. out of network buffers
2. out of relay buffers

Below is the code snippet to achieve the same send-receive the onoff message. I tracked the **adv_buf_pool** and it is becoming 0.

So is the adv_buffer not being freed after each time sending the adv packet? I believe it is being freed each time. If it is, then what is the thing that I am missing and if not then point me where I can solve the problem.

```
static void server_gen_onoff_set_unack(struct bt_mesh_model *model,
struct bt_mesh_msg_ctx *ctx, struct os_mbuf *buf)
{
struct bt_mesh_gen_onoff_srv_cb *cb = model->user_data;
struct bt_mesh_model_pub *pub_cli = onoff_model_cli->pub;

u8_t err;

gen_on_off_state = net_buf_simple_pull_u8(buf);

hal_gpio_write(LED_BLINK_PIN, gen_on_off_state);

BT_DBG("state: %d", gen_on_off_state);

if (cb && cb->set) {
cb->set(model, gen_on_off_state);
}

if (onoff_model_cli != NULL) {

if (onoff_model_cli->pub->addr != BT_MESH_ADDR_UNASSIGNED) {

bt_mesh_model_msg_init(pub_cli->msg, OP_GEN_ONOFF_SET);

net_buf_simple_add_u8(pub_cli->msg, gen_on_off_state);
net_buf_simple_add_u8(pub_cli->msg, trans_id++);

fill_mempool_stats();

err = bt_mesh_model_publish(onoff_model_cli);
if (err) {
BT_ERR("bt_mesh_model_publish err %d", err);
}
}
} else {
console_printf("MODEL CLI - Invalid Publish Address\n");
}

}
```

![Screenshot from 2019-06-07 18-47-52](https://user-images.githubusercontent.com/50844088/59465777-80868100-8de0-11e9-8cd4-f7072a3eae40.png)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the seven-node circular publish-subscribe setup and trace bt_mesh_model_publish while monitoring adv_buf_pool, network buffers, and relay buffers. Check whether buffers are reclaimed after each advertising packet and identify the point where depletion begins. Done means the same workload can continue sending messages without exhausting the pools.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
embedded-iot, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.