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

Implement temporary mesh addressing and refactor autoconf script #153

Open
paidforby opened this issue Oct 27, 2018 · 0 comments
Open

Implement temporary mesh addressing and refactor autoconf script #153

paidforby opened this issue Oct 27, 2018 · 0 comments

Comments

@paidforby
Copy link

As requested by @bennlich in cab7402#commitcomment-31070199, here's an outline of how we could refactor our home node configurations:

Problem:
Home nodes can't mesh with out running /opt/mesh/autoconf. Additionally, the template files that are copied and then modified by autconf are a redundant hold over from our makenode days.

Proposed solution:
Implement a temporary mesh address system, so a home node starts with working configs on first boot. Upon detecting an internet connection, the home node backups its previous configs to directory such as, /opt/mesh/files.bak/, and then modifies in place the existing configs, only updating what absolutely needs to be changed, i.e. files containing it's mesh IP address.

More details:
For the temporary mesh IPs, I would suggesting assigning an address randomly from the upper range of our /10 mesh IP range. According to some quick calculations, given our block of 64 address per home node scheme, there are 65536 usable home node addresses ranging from 100.64.0.1 to 100.127.255.192.

So we should be able to safely assign a home node IP address randomly in the 100.127.0.0/16 range, which gives 1024 usable dynamic mesh ips.

Ideally, these temporary addresses would be used only until the home node is able to find a mesh node database. In the event that a network was unable to reach it's mesh node database, the network could still expand and the network operators could carefully assign IPs outside the temporary range by manually running autoconf.

As for the configuration files, I would recommend starting by using autoconf to generate configs with a temporary address, such as 100.127.0.1. Then, I would copy those configs back to the firmware repo's non-template files directory, leaving autoconf and templates untouched, rebuild the firmware. Reflash a home node and check that it works without ever being plugged into the internet (i.e. can it babel with another node) and if it can run autoconf correctly once it has internet.

Then, I would go about generating the random IP address with a shell script and figure out how to use uci-defaults or a cron to run it on first boot. You should be able to reuse autoconf to update the IP once you get a temporary one

Finally, I would go through autconf, figure out how to reverse the cp that copies the templates and have it make backup copies of the configs. Then take out all the configs that aren't actually changed by autoconf, such as the constant listed here. And then use the same kind of uci commands to update only the mesh IP.

Hope this helps, would love to see someone take a crack at this problem!

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

No branches or pull requests

1 participant