Difference between revisions of "Mesh/Software ToDo"

Jump to navigation Jump to search
7,373 bytes added ,  06:08, 25 June 2018
no edit summary
(Created page with " 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/sudo...")
 
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
'''Adding to [[Mesh/ToDos]]!


- [[User:Tunabananas|Tunabananas]] ([[User talk:Tunabananas|talk]]) 06:08, 25 June 2018 (PDT)'''
----
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].
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].


Line 6: Line 9:
= Web UI =
= Web UI =


Should we split the dashboard into an unprivileged view-only dashboard and an admin interface that requires login and allow access to the admin only via the private wifi interface (the way it is now) but allow access to the dashboard via either? How hard would this be?


== Dashboard ==
== 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 ==
== 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
= Home node owner's manual =
We need one to include with each node!
= Make makenode simpler =
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.
= Stickers indicating what each port does =
* Extender ports (color: rainbow red+green+yellow?)
* Private port (color: red?)
* Public port (color: peoplesopen.net green)
* Internet port (color: yellow)
Make one sticker that fits the default layout and simply cut them up and stick them on separately for non-default setups. The Internet port one will always have to be cut off since that port is always a bit away from the rest. We'll save money on making just one sticker though.
The stickers should have text as well as the colors.
= Community support forum =
We should set one up!
Maybe [[User:Tunabananas|tunabananas]] wants to take this on?


--
marc/juul


= Fake captive portal splash =
= Fake captive portal splash =


We need a better splash page! Also we need to ensure the captive portal is working on the new exit server.
We need a better splash page! Also we need to ensure the captive portal is working on the new exit server.
= 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 =
= Removing our root access =
Line 57: Line 174:
* dmesg
* dmesg
* A dump of all config files (with e.g. wifi passwords censored)
* 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?
== Web UI for makenode ==
A web UI where people can sign up for a node. This UI should advise them that they will need to come by sudo room on a Tuesday at 7:30 pm to pick up their node.
We could hand out invite codes to this. E.g: We give each of our friends 10 invite codes.
If this UI could combine the .ipk generated by makenode with the firmware and allow you to download a firmware file then that would be just awesome!
== Extender node installation manual ==
Both software setup + physical mounting, running and crimping cable.
== 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).
1,194

edits

Navigation menu