Difference between revisions of "Mesh/Firmware"

Documentation for the sudo mesh firmware.

Stuff we _need_ before beta launch:

* Implement remote password reset (via h.sudomesh.org)

* Implement a remote logging/monitoring solution

** Right now we can probably just incorporate the Makenode db with some fairly simple cacti+graphite+icinga

* Select a wifi channel, both 2.4 ghz and 5 ghz.

* Remote updating

* Make analog hardware watchdog for old chipset and solder to devices.

* Better flexibility for notdhcp ports  

* IPv6 support (possibly switching to IPv6 entirely)

* Figure out how to legally use lower 5 ghz frequencies

* Set up OpenVPN on exit node.

= Stuff the firmware should have =

Chris (snake_wrangler) is working on it and calling it the Garden Gnome. Ideally, we could just package this for debian - I think it's actually something a lot of projects would be excited about...

[[User:maxb|maxb]] has implemented a MVP of this. Chris (snake_wrangler) is working on polishing, etc. it.

 

 

The SSH server should be contactable from any interface. It should initially allow root access using a random generated password that the mesh group has and that the node owner can get and change if they are so inclined.

 

 

We want to have a fairly simple extender node firmware that we can just flash to any openwrt compatible device and have it be able to be plugged into our routerboard and be a sudomesh radio which will be bridged. That way, the only routing that needs to take place will be on the routerboards.

 

We've developed [https://github.com/sudomesh/notdhcp notdhcp], which will allow a routerboard and extender node to negotiate a connection/configurations.

One thing is that we'll likely want to target a variety of hardware (if not chipsets), without having to run any sort of makenode after the firmware has been flashed.

A good example of how this could be done is by creating a /file/etc/uci-defaults script which will run first boot and can set configs depending on the "board" type:

*One ad-hock mode, unencrypted interface for the mesh nodes, e.g. sudomesh-backchannel

*One access point mode, unencrypted interface, for non-mesh devices to connect to the mesh, e.g. sudomesh.

*One access point mode, private interface with WPA2, for the people who own the nodes. [optional]

== Mesh VPN ==

If the mesh does not see any other nodes (and maybe even if it does?), and it has internet, then it should connect to another node or two over VPN. The easy solution is to use the same VPN servers as for the internet.

It would be nice to be able to have the network intelligently determine channels

We should have IPv6 support, but I am ok with launching the mesh with only IPv4 and adding in IPv6 later. ([[User:Juul|Juul]] ([[User talk:Juul|talk]]))

Then we can use "extender nodes" which can basically just do wifi and bridging. This would be basically any router which supports openwrt. We'll probably begin by targeting a variety of ubiquiti long-distance high power radios (Nanostation M line, Bullet M line, Picostation M line, Nanobridge/beam/etc).  

Really the extender nodes are just doing dumb bridging. The only reason we want them to run openwrt is so that they can do some fancier address assignment with [https://github.com/sudomesh/notdhcp notdhcp] and have some nice UI features. We could actually setup something like 2 ends of an airfiber and just configure them the way we want (wouldn't need the dynamic features of notdhcp).