meshrouting does not start on boot

[paidforby]

In the latest build of firmware (0.3.0 unstable/testing), the meshrouting script is not started automatically. This prevents a node from routing any traffic (either public or private). Once you ssh in and run /etc/init.d/meshrouting start the node begins operating as expected, it should be noted that starting meshrouting in uci-defaults like so, https://github.com/sudomesh/sudowrt-firmware/commit/3f6f2ac9e1cfa624e7be2db4ab86256e0a84d3cd, breaks the node and prevents it from booting at all. Starting this script hasn't been an issue for makenoded nodes, so I'm not sure what's the discrepancy or if we just need a better understanding of the OpenWrt startup sequence as suggested in #128

The bleeding edge build can (usually) be found here, http://builds.sudomesh.org/dev-builds/dispossessed/0.3.0/openwrt-ar71xx-generic-mynet-n600-squashfs-factory.bin

[paidforby]

so doing something as shown here, https://github.com/sudomesh/sudowrt-firmware/commit/3bb611c2ef799d47f6946573f5923b5b827a8c6a, appears to work, I'm not sure if this is the best way to do this. I feel there is something fundamentally wrong with the meshrouting script if we have to explicitly start it in rc.local. Perhaps porting meshrouting to a UCI configured script would elucidate some its issues.

[paidforby]

Found/remembered how makenoded nodes start meshrouting, I think it has to do with this postscript I'm not sure how these postscripts are triggered, but I know they were left out of 0.3.0. I still haven't found where makenoded nodes start meshrouting, since above script only appears to "enable" services, whatever that means.

[paidforby]

After realizing that makenoded nodes do not explicitly start meshrouting on every boot, but rather enable it once, I tried just running /etc/init.d/meshrouting enable and its seems to be working. This commit, https://github.com/sudomesh/sudowrt-firmware/commit/e998e1e18e07e5c8dd6a18471c3726e4f3ee463b should fix the bug, but will have to rebuild to fully test. I guess "enabling" the service does just that, it enables it to restart itself after reboot.

[paidforby]

Latest commit does fix this issue, though I do notice a slight discrepancy between retrieve_ip and zeroconf,

https://github.com/sudomesh/sudowrt-firmware/blob/master/files/opt/mesh/retrieve_ip#L72

https://github.com/sudomesh/sudowrt-firmware/blob/master/files/opt/mesh/zeroconf#L168

not sure if "start" is necessary, but we should probably "enable" and "start" meshrouting in one place to avoid future confusion.

P.S. latest working build can be found as usual here, http://builds.sudomesh.org/dev-builds/dispossessed/0.3.0/openwrt-ar71xx-generic-mynet-n600-squashfs-factory.bin

Also I'm going to open an issue for better versioning with file nomenclature.

[bennlich]

not sure if "start" is necessary, but we should probably "enable" and "start" meshrouting in one place to avoid future confusion.

Yeah I think the two start lines in retrieve_ip should be removed since the router is rebooted immediately after anyway.