mesh: advertising and relay memory pool depletion after some time sending messages
- 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");
}
}
```

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