Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a use case for a changing master node? #206

Closed
2bndy5 opened this issue Feb 19, 2022 · 2 comments
Closed

Is there a use case for a changing master node? #206

2bndy5 opened this issue Feb 19, 2022 · 2 comments
Labels

Comments

@2bndy5
Copy link
Member

2bndy5 commented Feb 19, 2022

I was testing the exposed addrList in pyrf24 and hit a segmentation fault when I changed the mesh child node into a master node and explicitly called loadDHCP(). I already can see the problem because if the node's ID is not 0 upon calling mesh.begin(), then the addrList doesn't have any memory allocated.

code to reproduce segmentation fault
mesh.setNodeID(1);
mesh.begin();
mesh.setNodeID(0);
mesh.renewAddress();
mesh.loadDHCP();

Is there a practical use case in which the master node of a mesh can change similar to how child nodes change?

This wouldn't be a hard problem to solve, but it would definitely involve increased compile size... One could probably just solve it by recalling mesh.begin() after mesh.setNodeID(0).

@TMRh20
Copy link
Member

TMRh20 commented Feb 21, 2022

I don't think there is really a use case for it, plus as you mentioned it would increase memory and program space usage just to support an unlikely scenario.

@2bndy5 2bndy5 closed this as completed Feb 21, 2022
@2bndy5
Copy link
Member Author

2bndy5 commented Feb 21, 2022

I also had an idea a while back (when porting to pure python) to reserve a msg type that transfers the DHCP list to a new master node. The only case for that would be if you want a continuous network running while phasing in a firmware update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants