Difference between revisions of "Mesh/Firmware"

Jump to navigation Jump to search

Mesh/Firmware (view source)

Revision as of 21:19, 27 June 2018

112 bytes removed ,  21:19, 27 June 2018
m
no edit summary
(→‎Block ads and tracking: Some more polipo thoughts)
m
 
(14 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Documentation for the sudo mesh firmware.
[[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 =


Stuff we _need_ before beta launch:
[https://github.com/sudomesh/sudowrt-firmware/issues?q=is%3Aopen+is%3Aissue+milestone%3A%220.3+-+Improved+UI%22 Issues for version 0.3]
* basic notdhcp polishing
* finish firmware for extender node antennas
* Routerboard admin UI should be able to push settings changes to extender nodes
* Better interface and security for node database
* Deal with situations where internet is not shared or not present. (juul)
* Implement remote password reset (via h.sudomesh.org)
* Implement error reporting in web admin interface
* Set up a remote monitoring solution
* Implement a remote logging/monitoring solution
** Nodewatcher 2 looks like it's not going to be ready for test deployments
** 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.


Issues for later versions:
Issues for later versions:
* Remote updating
* Basic admin web UI for node database that let's you log in and list current nodes.
* Make analog hardware watchdog for old chipset and solder to devices.
* fake captive portal working
* Better flexibility for notdhcp ports  
* service browser working
* IPv6 support (possibly switching to IPv6 entirely)
* hardware watchdog working on ar71xx
* Figure out how to legally use lower 5 ghz frequencies
* support for manually configured non-openwrt extender nodes
* Set up OpenVPN on exit node.
** Allow user to switch ethernet ports into "extender node (manual)" mode
* Implement statistics for web admin interface.
** Only one network (either adhoc or open) can be extended using this mode. The user must be able to select which.
* Manual (or automatic?) speed and output power selection via web interface.
** 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).


= Firmware generation features =
It should be easy to generate a new firmware with the following custom config:
*Location and ownership information.
:Contact info should be saved in a secure database but maybe not on the node itself?
*Randomly generated passwords set for wpa2, admin interface and ssh.
:The SSH password should be stored securely and a couple of stickers with the wpa2 and admin password should be printed for the user.
*Web interface
*ssh key generation
[http://meshkit.freifunk.net/ Freifunk Meshkit] is pretty neat!
We'll be dividing the image generation and node configuration aspects into two parts.
[https://github.com/sudomesh/sudowrt-firmware Sudomesh Firmware Image Builder Github Repo] has our image builder and
[https://github.com/sudomesh/makenode Sudomesh Node Configurator Makenode Github Repo] is our node configurator.


[https://github.com/sudomesh/sudowrt-packages Sudomesh OpenWrt Packages] has all of the sudomesh openwrt packages that we're using/we've written.
= Stuff we are working on =
 
We flash nodes with the sudomesh image and then we use the makenode to set them up with networking configs, ssh keys, etc. We also use makenode in conjuction with meshnode-db to write pertinent info to a database.
 
 
Status:
Pretty much finished! We're testing the last few issues!
 
= Stuff the firmware should have =


<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 implemented a MVP of this. Chris (snake_wrangler) is working on polishing, etc. it.
[[User:maxb|maxb]] has implemented it! We need a tiny bit of polishing, especially for corner case browsers.
 
== SSH server ==
 
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.
 
 
Status: Implemented. Mostly openwrt stock but we've added keygen features for the node-configurator


== Extender node firmware ==
== 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.
See the [[Mesh/Technical Overview]] to learn about home nodes and extender nodes.


We've developed [https://github.com/sudomesh/notdhcp notdhcp], which will allow a routerboard and extender node to negotiate a connection/configurations.
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.


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.
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:
 
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]
[https://gist.github.com/max-b/97bd7d59259cfbdfbbb2 uci-defaults script gist]


== Mesh Protocol ==
== Mesh Protocol ==
Line 112: Line 84:
== Multiple virtual network interfaces with their own SSIDs ==
== Multiple virtual network interfaces with their own SSIDs ==


*One ad-hock mode, unencrypted interface for the mesh nodes, e.g. sudomesh-backchannel
*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
*One access point mode, unencrypted interface, for non-mesh devices to connect to the mesh, e.g. sudomesh.
*The Open interface: An access-point-mode, unprotected interface, for non-mesh devices to connect to the mesh, ssid: peoplesopen.net
*One access point mode, private interface with WPA2, for the people who own the nodes. [optional]
*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 207: Line 179:
Here is our [[Mesh/Network_topology|Network Topology]].  
Here is our [[Mesh/Network_topology|Network Topology]].  


== Mesh VPN ==
== 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 VPN. The easy solution is to use the same VPN servers as for the internet.
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 ==
Line 236: 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 274: Line 245:
= Compatible devices =
= Compatible devices =


We should have ready-made images for:
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).


*One really cheap indoor router (with 3G usb stick support?) like [http://wiki.openwrt.org/toh/tp-link/tl-wr703n TP-Link TL-WR703N]
[[Category:Mesh]]
*One nice high-speed indoor router (300 mbps 802.11n)
*Ubiquiti hardware. Most of the AirMAX stuff.
Tunabananas
Bureaucrats, oversight, Administrators
1,194

edits

Retrieved from "https://sudoroom.org/wiki/Special:MobileDiff/9384...11360"

Navigation menu