123
edits
Difference between revisions of "Mesh/15 May 2018"
Jump to navigation
Jump to search
no edit summary
| Line 12: | Line 12: | ||
* Action Items (5 mins) | * Action Items (5 mins) | ||
* Breakout Groups | * Breakout Groups | ||
* Notes from special meeting on how the firmware works and how to proceed | |||
=== Introductions === | === Introductions === | ||
| Line 164: | Line 165: | ||
[[Category:Mesh/Minutes]] | [[Category:Mesh/Minutes]] | ||
'''Special meeting on how the firmware works and how to proceed - May 15th 2018 ''' | |||
= Where are the builds? = | |||
Current stable is always linked from here: | |||
https://github.com/sudomesh/sudowrt-firmware/ | |||
Current dev build (not fully working): | |||
http://builds.sudomesh.org/dev-builds/dispossessed/0.3.0/ | |||
See PR: https://github.com/sudomesh/sudowrt-firmware/pull/132 | |||
= ToDo = | |||
== Things to fix for nullconf build (previously zeroconf) == | |||
The new home node build doesn't do hardware detection. I just assumes it's an n600. | |||
* Add hardware detection | |||
* Start /etc/init.d/meshrouting on boot (it's currently not starting) | |||
* Automated nightly builds? | |||
== Where do we stand with ubiquiti 802.11ac gear? == | |||
* Does it even have good openwrt support? | |||
* With AirOS do they support ad-hoc mode? (doesn't matter unless we can put babeld on them) | |||
* The /etc/init.d/meshrouting script on the home nodes should be re-written to use a `uci` `/etc/config/sudomesh` file. | |||
=== We should make it easy to get on the mesh with any debian-based system === | |||
A small script to install and configure the dependencies and get an IP from the secrets server? | |||
= How configuration works = | |||
Currently there are two directories in the sudowrt tree: | |||
* `files/` | |||
* `files_extender-node/` | |||
The files in `/files` and `/files_extender-node` overwrite any files from the openwrt base system and openwrt packages. They are copied on top of the system as the very last step before bundling everything into the image file. | |||
Grant says we can target specific models so instead of doing hardware detection we can just have one of these directories for each model. He thinks we should improve the build system in this way instead of adding hardware auto-detection on first boot. | |||
These are in turn potentially over-written by the zeroconf templates (described in the next section) which is the very last configuration step. | |||
= how nullconf (previously zeroconf) works = | |||
- `cron` checks for internet by pinging google every minute using `/opt/mesh/retrieve_ip`. | |||
- If it detects internet the `retrieve_ip` script does an `HTTPS GET` request with `curl` which returns JSON including an IP subnet. | |||
- retrieve_ip script then removes the cron job and deletes itself and calls `/opt/mesh/zeroconf` with the subnet | |||
- /opt/mesh/zeroconf copies files from /files/opt/mesh/templates/etc and /files/opt/mesh/templates/opt to /etc and /opt, overwriting anything that was there before | |||
In the template files you'll see hold-overs from `makenode` where some configs have e.g. `<% variable %>`. These used to be replaced by their appropriate values by makenode search-and-replacing them before copying them over to the node. Now the files are copied into `/etc/config/` as they are, including these unusable values, and then the values are replaced by the `/opt/mesh/zeroconf` script running `uci set` commands (`uci set` is a built-in openwrt command used to modify the files in `/etc/config/`). | |||
= Can we switch to IPv6 to get rid of the secrets server? = | |||
Maybe? We could set up 464LAT and give every home node the same IPv4 range. Then the nodes would translate from IPv4 to IPv6 and the exit node would NAT between IPv6 and IPv4 using NAT64. The software to do this is: | |||
* TAYGA: http://www.litech.org/tayga/ | |||
* clatd: https://github.com/toreanderson/clatd | |||