Bureaucrats, oversight, Administrators
1,194
edits
Difference between revisions of "Mesh/Firmware"
Jump to navigation
Jump to search
m
no edit summary
(→ToDo: Updating to reflect new firmware ideas) |
Tunabananas (talk | contribs) m |
||
| (21 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Stale]] | |||
'''This page has been marked as [[:Category:Stale|stale]], as it is outdated to the point of providing significant misinformation. Please update it before linking other pages here.''' | |||
'''For now, please see the [https://github.com/sudomesh/sudowrt-firmware firmware repo] on GitHub.''' | |||
For the new ToDo see [[Mesh/Software ToDo|Software ToDo]]. | |||
= ToDo = | = ToDo = | ||
[https://github.com/sudomesh/sudowrt-firmware/issues?q=is%3Aopen+is%3Aissue+milestone%3A%220.3+-+Improved+UI%22 Issues for version 0.3] | |||
Issues for later versions: | Issues for later versions: | ||
* | * Basic admin web UI for node database that let's you log in and list current nodes. | ||
* | * fake captive portal working | ||
* | * service browser working | ||
* IPv6 | * hardware watchdog working on ar71xx | ||
* Figure out how to legally use lower 5 ghz frequencies | * support for manually configured non-openwrt extender nodes | ||
* | ** Allow user to switch ethernet ports into "extender node (manual)" mode | ||
** Only one network (either adhoc or open) can be extended using this mode. The user must be able to select which. | |||
** Set up port forwarding from home node to each manually configured extender node for web UI access, e.g. 1443 to 443 on extender node 1, etc. | |||
*** This can be always-on for e.g. up to 16 ports without causing problems since it is only for traffic destined for the home node IP. | |||
*** There should be links to the extender node web UIs from the home node web UI. | |||
* Apply for internet-routable IPv6 subnet and give each node their own subnet + hand out IPv6 addresses to clients | |||
* extender node firmware working on old atheros chipset | |||
* Remote firmware updates working | |||
** Use either DNS-SD to list and pick an update server at random or IPv6 multi-homing? | |||
* Remote automated root password reset (via h.sudomesh.org) | |||
* IPv6 support for extender nodes | |||
* Figure out how to legally use lower 5 ghz frequencies and ensure fancy back-off features are working | |||
* Run OpenVPN on exit node. | |||
In the future: | |||
* Support TDMA on Linux (Adri is working on FreeBSD support, maybe we can port). | * Support TDMA on Linux (Adri is working on FreeBSD support, maybe we can port). | ||
= Stuff | = Stuff we are working on = | ||
<big>Ranked from most to least important</big> | <big>Ranked from most to least important</big> | ||
| Line 70: | Line 48: | ||
Status: Implemented except for OS-specific captive portal requests. | Status: Implemented except for OS-specific captive portal requests. | ||
== Splash page == | == Splash page (Garden Gnome) == | ||
We can capture OS specific probes in order to specifically redirect captive portal requests without affecting any other network traffic. | We can capture OS specific probes in order to specifically redirect captive portal requests without affecting any other network traffic. | ||
Chris (snake_wrangler) was working on it and calling it the Garden Gnome. | |||
[[User:maxb|maxb]] picked up the idea and ran with it in nodejs: https://github.com/sudomesh/garden-gnome | |||
Features: | Features: | ||
| Line 78: | Line 59: | ||
* Brief info on the mesh | * Brief info on the mesh | ||
* Link to our website? | * Link to our website? | ||
Status: | Status: | ||
[[User:maxb|maxb]] has | [[User:maxb|maxb]] has implemented it! We need a tiny bit of polishing, especially for corner case browsers. | ||
== | == Extender node firmware == | ||
See the [[Mesh/Technical Overview]] to learn about home nodes and extender nodes. | |||
With the extender node firmware we're targeting a variety of hardware (if not chipsets), and we don't want to run any sort of makenode after the firmware has been flashed. | |||
We're doing this 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 94: | Line 78: | ||
[http://www.open-mesh.org/projects/batman-adv/wiki BATMAN-adv] was the protocol that we had assumed we'd be able to use. Unfortunately, it looks as though it won't support tunneling over the internet, which is one of the primary features we had been hoping to implement. See [https://lists.sudoroom.org/pipermail/mesh-dev/2014-October/000019.html our mailing list convo]. | [http://www.open-mesh.org/projects/batman-adv/wiki BATMAN-adv] was the protocol that we had assumed we'd be able to use. Unfortunately, it looks as though it won't support tunneling over the internet, which is one of the primary features we had been hoping to implement. See [https://lists.sudoroom.org/pipermail/mesh-dev/2014-October/000019.html our mailing list convo]. | ||
We're now | We're now using [https://github.com/jech/babeld babel]. It's been looking pretty good for our particular applications. There are some security/trust issues that we'd like to investigate further - see http://lists.alioth.debian.org/pipermail/babel-users/2015-April/001973.html for some ideas that babel might incorporate in the future. | ||
Status: | Status: Ready, but can be improved | ||
== Multiple virtual network interfaces with their own SSIDs == | == Multiple virtual network interfaces with their own SSIDs == | ||
* | *The Mesh interface: An ad-hock mode, unprotected interface for the mesh nodes to talk to each other with Babel handling routing, ssid: pplsopen-node2node | ||
* | *The Open interface: An access-point-mode, unprotected interface, for non-mesh devices to connect to the mesh, ssid: peoplesopen.net | ||
* | *The Private interface: An access-point mode, private interface with WPA2, for the people who own the nodes, ssid: Decided by node owner | ||
Traffic on the private interface should be completely separated from traffic on the non-private interfaces unless a client connected to the private interface requests an IP on the mesh. | Traffic on the private interface should be completely separated from traffic on the non-private interfaces unless a client connected to the private interface requests an IP on the mesh. | ||
| Line 135: | Line 119: | ||
: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]] | 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/ | https://github.com/sudomesh/sudowrt-luci2-webclient | ||
== Remote Updates == | == Remote Updates == | ||
| Line 195: | Line 179: | ||
Here is our [[Mesh/Network_topology|Network Topology]]. | Here is our [[Mesh/Network_topology|Network Topology]]. | ||
== Mesh | == Mesh VPuN == | ||
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 | 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 a [[VPuN]] server. The easy solution is to use the same VPuN servers as for the internet connection. | ||
[[Mesh/Network_topology|Network Topology]] | [[Mesh/Network_topology|Network Topology]] | ||
Status: Implemented | Status: 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) | ||
| Line 229: | Line 207: | ||
== Intelligent Wifi Channel Switching == | == Intelligent Wifi Channel Switching == | ||
It would be nice to be able to have the network intelligently determine channels | It would be nice to be able to have the network intelligently determine channels but we don't want a node changing channel if it means other nodes connected to it will have to change as well so it may make sense to only set the channel once on first boot based on which channels have other nodes. | ||
== IPv6 support == | == IPv6 support == | ||
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]])) | We should have IPv6 support, but I am ok with launching the mesh with only IPv4 and adding in IPv6 later. We can do without IPv6 but not without IPv4 ([[User:Juul|Juul]] ([[User talk:Juul|talk]])) | ||
= Stuff the firmware could have = | = Stuff the firmware could have = | ||
| Line 253: | Line 231: | ||
== Caching web proxy == | == Caching web proxy == | ||
We could use [http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Polipo] to improve people's browsing experience. Not sure how much cpu and memory this would need. We may not be able to run it on the routers with less than 32 MB ram (e.g. the Bullet 2 HPs). | We could use [http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Polipo] to improve people's browsing experience. Not sure how much cpu and memory this would need. We may not be able to run it on the routers with less than 32 MB ram (e.g. the Bullet 2 HPs). | ||
Maxb has installed polio as a transparent caching proxy on a picostation 2HP. It improved web browsing significantly! However, it sorta breaks "net neutrality". Also - it'll be irrelevant for https and it might break some things (webdav?). | |||
I wonder if you could (as an end user?) enable/disable this kinda proxying? On splash page? We would need MAC, but it would only get logged on the mesh node itself (not network wide....) | |||
== Block ads and tracking == | == Block ads and tracking == | ||
We could use e.g. [http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Polipo] with the sources from both adblock plus and ghostery. If we implement this, it should be an optional (default off) feature that you can select on the splash page, with a "remember this" that remembers either using a cookie or using your MAC (but then we'd be logging people's MAC addresses :-S). The block should probably be time-limited (e.g. 30 days). | We could use e.g. [http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Polipo] with the sources from both adblock plus and ghostery. If we implement this, it should be an optional (default off) feature that you can select on the splash page, with a "remember this" that remembers either using a cookie or using your MAC (but then we'd be logging people's MAC addresses :-S). The block should probably be time-limited (e.g. 30 days). | ||
Now that we're running more powerful devices, I wonder if we could actually run this kind of blocking on the actual mesh nodes. That way we could do a "remember this" MAC and only store it on the mesh node itself (NOT network-wide). | |||
= Compatible devices = | = Compatible devices = | ||
We | We're going to target ar71xx devices with decent storage + processing speed + memory for "router board" nodes. | ||
Right now we're using for "router board" nodes: | |||
WD MyNet N750 and/or TP-Link TL-WDR4300 | |||
The MyNets are no longer in production, but the TL-WDR4300 are the exact same board, just with external antennas. | |||
Then we are using [[extender node|extender nodes]] which plug into the home node and just bridge/forward traffic. This could theoretically be any router which supports openwrt. We've begun by targeting a variety of ubiquiti long-distance outdoor radios (Nanostation M line, Bullet M line, Picostation M line, Nanobridge/beam/etc). | |||
We would also like to support non-openwrt routers (like Ubiquiti Airfiber and Nanobeam 802.11ac devices) but these will only be able to extend one of the three networks (Mesh, Public or Private) and will need to use WDS mode to do so (at least for Mesh). | |||
[[Category:Mesh]] | |||