Difference between revisions of "Mesh/Firmware"

Jump to navigation Jump to search
605 bytes added ,  21:36, 28 April 2015
→‎Stuff the firmware should have: Updating to reflect new firmware ideas
(→‎Mesh Protocol: Incorporating new firmware ideas)
(→‎Stuff the firmware should have: Updating to reflect new firmware ideas)
Line 89: Line 89:


Status: Implemented. Mostly openwrt stock but we've added keygen features for the node-configurator
Status: Implemented. Mostly openwrt stock but we've added keygen features for the node-configurator
== Extender node firmware ==
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:
[https://gist.github.com/max-b/97bd7d59259cfbdfbbb2 uci-defaults script gist]


== Mesh Protocol ==
== Mesh Protocol ==
Line 135: Line 147:
:One idea we had (but this is probably better for splash screen) is "adopt a node". Where a neighbor who uses a node a lot and depends on the node can donate some money to keep it up, but can then give a nickname or avatar to the node. Or something. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)
:One idea we had (but this is probably better for splash screen) is "adopt a node". Where a neighbor who uses a node a lot and depends on the node can donate some money to keep it up, but can then give a nickname or avatar to the node. Or something. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:20, 24 July 2013 (PDT)


Status: [[User:Maxb|Maxb]] is implementing. Pretty much finished. Still needs graphs, etc. but has most of the other functionality including bandwidth shaping controls.
Status: [[User:Maxb|Maxb]] implemented a luci-based ui. We decided we hate luci, so we're going to use the ubus uhttpd rpc protocol with a jsonrpc front-end. It's a bit copy-pasta'd from the openwireless router.


Source here:
Source here:


https://github.com/sudomesh/luci-app-peopleswifi
https://github.com/sudomesh/sudowrt-luci2-webclient


== Remote Updates ==
== Remote Updates ==
Line 203: Line 215:
Status: Implemented
Status: Implemented


== DHCP and batman-adv gateway mode ==
Nodes with an internet connection should run DHCP and [http://www.open-mesh.org/projects/batman-adv/wiki/Gateways batman-adv gateway mode]. We want to detect if the node can connect to a relay in which case it should configure as a batman-adv gateway server node. Otherwise they should configure as batman-adv gateway clients.
Staus: Implemented


== Location and status reporting ==
== Location and status reporting ==


Something that reports location and status when polled.
Something that reports location and status when polled. I think we can probably get away with using snmp v1.


We developed this format and easy to publish status data from nodes for our [http://dev.wlan-si.net/wiki/Nodewatcher/NodeTelemetryProvider nodewatcher]. OpenWrt packages are [https://github.com/wlanslovenija/firmware-packages-opkg/tree/master/util here]. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:02, 11 July 2013 (PDT)
We developed this format and easy to publish status data from nodes for our [http://dev.wlan-si.net/wiki/Nodewatcher/NodeTelemetryProvider nodewatcher]. OpenWrt packages are [https://github.com/wlanslovenija/firmware-packages-opkg/tree/master/util here]. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 22:02, 11 July 2013 (PDT)

Navigation menu