Mesh/Software ToDo

Adding to Mesh/ToDos!

- 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 the github issue tracker.

This page is an attempt to list the software ToDo items that we are aiming to complete before a wider beta launch.

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

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

redconfetti is working on 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 tunabananas wants to take this on?

-- marc/juul

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.

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 this issue.

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).