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!
As requested by @bennlich in https://github.com/sudomesh/sudowrt-firmware/commit/cab74028712990ee7a1492a4b7db034a96ca5cae#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
filesdirectory, 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-defaultsor acronto run it on first boot. You should be able to reuse autoconf to update the IP once you get a temporary oneFinally, I would go through autconf, figure out how to reverse the
cpthat 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!