Bureaucrats, oversight, Administrators
1,196
edits
Difference between revisions of "Mesh/ToDos"
Jump to navigation
Jump to search
m
no edit summary
Tunabananas (talk | contribs) m |
|||
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
'''We now use a number of other tools to manage our active tasks. As of June 2018, we use Trello for kanban boards, and we set a weekly list of action items at each Tuesday meeting. Technical issues are reported in related GitHub repos, and larger, network-level issues are discussed in the [https://github.com/sudomesh/bugs bugs repo].''' | |||
Below are a list of To Do items, separated by topical area. If you decide to take one on, please post your name after the item and send a note to the mailing list with your plan of action! We welcome contributions of tasks, also :) | Below are a list of To Do items, separated by topical area. If you decide to take one on, please post your name after the item and send a note to the mailing list with your plan of action! We welcome contributions of tasks, also :) | ||
The purpose of this page is to provide an overview over features we want for the next milestones. We also track feature requests and bugs on [https://github.com/sudomesh/sudowrt-firmware/issues the github issue tracker]. | |||
=Community Outreach ToDos= | =Community Outreach ToDos= | ||
*Outreach to churches with succinct argument [cite examples, e.g.; Sandy relief] | *Outreach to churches with succinct argument [cite examples, e.g.; Sandy relief] | ||
*Poster/ | *Poster/flyer at local coffeeshops, bikeshops, co-ops, collectives, community resource spaces, etc; | ||
*Walkabouts/canvassing in E Oakland, Berkeley, Downtown Oakland | *Walkabouts/canvassing in E Oakland, Berkeley, Downtown Oakland | ||
*Find folks in El Cerrito / Albany who can help us link up to the Internet Archive's Richmond node | *Find folks in El Cerrito / Albany who can help us link up to the Internet Archive's Richmond node | ||
*See if people in school system want to work with us to ensure every student has home connectivity - talk to Hilary | |||
*Convince libraries to share their connectivity - talk to Ivan | |||
*Conduct User Research on what sorts of [[Mesh/MeshApps|Local Services]] people would like to have - see [[Mesh/UserResearch]] | |||
*Write up a compelling argument for mesh re: disaster preparedness - see [https://jennyryan.net/occupy-sandy-a-model-for-grassroots-community-disaster-relief/ Jenny's post on Occupy Sandy] | |||
*[https://sudoroom.org/wiki/Mesh/Presentations Presentations / talks / events promo] | *[https://sudoroom.org/wiki/Mesh/Presentations Presentations / talks / events promo] | ||
=Operational Logistics= | =Operational Logistics= | ||
*Make a project roadmap | *[https://sudoroom.org/wiki/Mesh/Funding#Sustainable_Business_Models Business models] | ||
*Make a project roadmap - see [https://sudoroom.org/wiki/Mesh/17_Feb_2018 Strategic Planning Meeting Notes] | |||
*[https://sudoroom.org/wiki/Mesh/Funding Grants and other funds we can apply for] | *[https://sudoroom.org/wiki/Mesh/Funding Grants and other funds we can apply for] | ||
*Financials [current and projected] [Jenny, you?] | *<s>Financials [current and projected] [Jenny, you?]</s> | ||
* | *<s>Tax status (set up 501c3) [Marc, Matt, Jenny]</s> | ||
=Marketing / Branding= | =Marketing / Branding= | ||
*Blog posts | *Blog posts - continual, errybody! | ||
*Articles & Research | *Articles & Research | ||
*Photo album | *Photo album (currently a mix of GDrive, RocketChat, and the blog) | ||
*Design 'pods' for the outdoor routers [eg; birdhouses, planterboxes] | *Design 'pods' for the outdoor routers [eg; birdhouses, planterboxes] | ||
*Infographics | *Infographics, flyers, propaganda - add to our [https://github.com/sudomesh/propaganda propaganda repo] | ||
*Videos | *Videos | ||
* | *Bios, titles and photos of team members - (do we actually want this? -jnny) | ||
* | |||
* | =Software= | ||
== Dashboard == | |||
We want: | |||
* Node counts (server side done) | |||
** Total nodes on mesh (server side done) | |||
** Immediate neighbors on each wifi interface / extender node / ethernet interface (server side done) | |||
* Extender node states (server side done) | |||
* Extender node router models (how do we detect exact model?) | |||
* Internet connectivity and VPN status | |||
* Port status for non-extender ports (connected/disconnected) | |||
* Currently connected clients on each wifi interface (iwinfo) and total wifi+ethernet (dhcp leases) | |||
* Wifi channels and power used for local and extender interfaces | |||
== Admin == | |||
We want: | |||
* Change wifi channel for each radio | |||
* Change wifi transmit power for for each radio | |||
* Scan for other mesh nodes and see their channels | |||
* Grant temporary ssh root access to sudo mesh developers (maybe) | |||
* Change admin UI password (done) | |||
* Change private wifi name (done) | |||
* Change private wifi password (done) | |||
* Change shared bandwidth (done) | |||
== Extender node UI == | |||
[[User:Redconfetti|redconfetti]] is working on [https://github.com/sudomesh/ubus-https-forwarder ubus-https-forwarder] which will allow us access to dashboard info and web admin for the extender nodes via the main home node UI. | |||
Dashboard info: | |||
* Wifi channel | |||
* Wifi transmit power | |||
* Exact router model (e.g. NanoBridge M5) | |||
* Neighboring mesh nodes | |||
* Connected clients | |||
Admin features: | |||
* Scan for other mesh nodes and see their channels | |||
* Change wifi channel | |||
* Change wifi transmit power | |||
== Make makenode simpler == | |||
'''@paidforby has been working on this! See [https://github.com/sudomesh/sudowrt-firmware/releases/tag/0.3.0 sudowrt v.0.3.0] and [https://github.com/sudomesh/sudowrt-firmware/blob/master/files/opt/mesh/autoconf autoconf]! | |||
''' | |||
Make it ask: | |||
* What is the name of person owning this node (Won't be publicly shared)? | |||
* What is their email address? (Won't be publicly shared): | |||
* What will the street address of this node be? (_WILL_ be publicly shared) | |||
* Can we publicly show the location of this node on our mesh map? (y/n) | |||
* Name your node (or hit enter to skip): | |||
* We're going to send you an email with your node info. Do you want us to include passwords in this email? (if no, you'll still get them printed on a sticker) | |||
Auto-generate everything else. | |||
== Email automation == | |||
Emails we want to send: | |||
* Initial email with all your node info sent by makenode on node creation. Ask the user if they want to exclude passwords. | |||
* Congratulations email when new node is connected and meshing via Internet | |||
* Congratulations email when node is meshing for the first time via wifi/ethernet | |||
* A "what happened?" email if a node is down for e.g. more than 12 hours (which also goes to sudo mesh admins) | |||
** Repeat reminders after e.g. 1 week, 1 month and 1 year | |||
== Sticker printing on node creation == | |||
Print a sticker with basic info: | |||
* Admin interface | |||
* Admin username + password | |||
* Root password | |||
* Private wifi name | |||
* Private wifi password | |||
We have the code for this, we just need to attach it to makenode. | |||
== Support proprietary extender nodes == | |||
Minimal feature set: | |||
* Manual for how to use the Ubiquiti web UI to set up each node in a point to point or point to multipoint link | |||
** Needs one in WDS station and one in WDS master (access point) mode with the ethernet bridged to the wifi | |||
* A way to configure an ethernet port to be for a proprietary extender node | |||
** Maybe this isn't needed? When no extender is connected the ports are already in untagged mode and on the correct VLANs are set, so if we simply enable babeld on extender node interfaces per default and then remove the babeld add/remove lines from the notdhcpserver hook scripts that should do it! | |||
Nice to have: | |||
* Auto-detection and configuration of AirOS | |||
** SSH | |||
* Detect and show which model router is connected using dashboard | |||
== Removing our root access == | |||
Having root access mesh nodes means that we can potentially listen in on traffic on the _private_ router used by the node operator. That is: The router they use for their internet connection. This can be done by spoofing MAC addresses or using ARP flooding. That's bad. We don't want this power. How do we get rid of it. | |||
We only need root access to nodes for three reasons: | |||
* To upgrade the firmware | |||
* Remote password reset for people who forgot their password | |||
* Diagnostics / debugging | |||
Upgrading the firmware of course means that we could give ourselves root access or include whatever malicious code in the upgrade. In the end users will have to trust our firmware and upgrades, so why even bother taking away our root access? | |||
First, if upgrades are sent out as signed packages then those are easy to inspect and verify. Most node owners won't do this but at least we can make it an option for users to check the upgrades before installing them and even if one node owner checks them then they could find any potentially malicious code and alert everyone on the mesh to the problem. | |||
Second, there is a big difference between "we will sometimes send you a firmware upgrade, but you if you want you can check the contents before you install it" and "we can log into your device at any time and look at your private traffic and there is no way for you to know if we've done so, but we promise we won't do this". | |||
== Firmware upgrade == | |||
We should distribute signed .ipk packages and sometimes sysupgrade images. The clients will download them (to begin with from a central repository), verify and either install or wait for the user to authorize the install. | |||
== Remote password reset == | |||
We have a web app on a server. The web app asks security questions or verifies via sms and emails the node operator a password reset code that they copy and paste into a field on the node's web UI. This password reset code is actually a signed and encrypted JSON message saying "allow one password reset". The user then pastes this code into the Web UI and enters a new password. The password reset key should expire fairly quickly if unused. | |||
== Diagnostic / debugging == | |||
We want access to: | |||
* babeld -i | |||
* notdhcpserver -i | |||
* ip addr show | |||
* ip route show | |||
* ip route show table public | |||
* iw list | |||
* iw dev | |||
* iwinfo <dev> <cmd> (yes all of them) | |||
* ps | |||
* logread | |||
* dmesg | |||
* A dump of all config files (with e.g. wifi passwords censored) | |||
== Allow temporary (or permanent) remote SSH access == | |||
We could include a function in the UI to allow temporary root access to sudo mesh developers | |||
It would be _really_ useful if someone specifically asks us to help them out. This feature should not allow granting of temporary ssh access to anyone else since that would equate web admin access to root access which we do not want (web admin access should be seen as a relatively low security thing as it doesn't allow you to e.g. install malicious code). | |||
== Firewall rule rewrite and security test == | |||
See [https://github.com/sudomesh/sudowrt-firmware/issues/96 this issue]. | |||
[[User:Juul|juul]] will do the rule rewrite and then we'll need someone to test that no traffic is allowed to flow from public to private areas. | |||
= Nice to have = | |||
These are features we'd like to have but will only add if we feel like we have time. | |||
== "What is this?" sticker == | |||
A big sticker that covers a large part of the home node with an attention-catching message and an explanation in smaller text. Not everyone will want to stick it on their router but if people agree to put it on their node and the node is publicly visible then the node will be its own advertisement. | |||
== A way for node operators to directly contact each other without revealing email addresses == | |||
Is there an easy way to do this? | |||
== Allow proprietary extender nodes to link to sudowrt extender nodes == | |||
Since proprietary extender nodes can only operate in client wds or master wds modes that means we'd have to add both a client wds and master wds interface to each extender node. These can be bridged together and need to have babeld enabled. We might then also consider doing the same on home nodes. The first thing to do is test if e.g. a ubiquiti stock firmware 802.11ac device will even connect to an openwrt wds device. | |||
= | == A way to prioritize/round-robin routes to the internet = | ||
If you have two equally viable routes to the internet and the node is always picking the wrong one have a way to give one of them higher priority permanently. If possible make it round-robin the routes for each connection (this should be ok because it's all going to the same VPN). | |||