access address collisions?

[vliedel]

My mesh network went rogue: some node(s) started sending messages on handles I'm not even using (leading to continues conflicts on that handle). So I started to try out some thing on a few nodes with a different mesh access address, but it turned out that even though I was using a (slightly) different access address, I still got the random messages. Only when using a different channel, I didn't get these anymore.

So I'm wondering now how well the access address works to filter out messages from other sources.

Also: if I know which handles I'm going to use, should I call rbc_mesh_value_disable() for all the other handles?

[trond-snekvik]

Could you consider following the BLE specification's access-address guidelines, as explained in issue #59? Are you able to confirm that the out-of-context handles (and their attached data) are indeed from the other network, and not just mangled data?

I don't think value_disable is a good idea, as it keeps devices from relaying those values, and they will fail to propagate. Rather, you should keep the device-specific handles persistent. You may choose to utilize the TX-events, and disable retransmission of uninteresting handles after some N number of events, if you want to reduce traffic.

[trond-snekvik]

I might have misread your question: For handles which aren't supposed to be present in the mesh at all, disabling seems reasonable, but possibly redundant if the mesh is working properly.

[vliedel]

Ok, from the code, it looks like I can only disable it when the handle is in cache, so I now disable it in the rbc_mesh_event_handler. I was using access address 0xA541A68E and tried 0xA541A68A to 0xA541A68D. Now I'm on 0xA641A69E and it seems to filter ok so far.

The random messages started after I updated the app on each node (1 by 1), so I guess the old messages were confusing the new app or so?

[daviddedwin]

My suggestion on the access addresses is to have at least 4 bits different in the MSB 16 bits and and an additional 4 bits different on the LSB 16 bits, this is in addition to the BTLE specification rules.

[trond-snekvik]

The update procedure might be a cause of error, yes. Since old devices will still be transmitting whatever is in their cache while you update the others, the new devices will pick these up, since they don't know any better. The cleanest solution would be to disable your mesh nodes somehow (tell all devices to do value_disable or mesh_stop, or do a network-wide power cut). We've seen these errors with access-address similarity as well, so you should employ both changes.

[vliedel]

Thanks a lot for the help.