Mesh/Firmware/Overview

Accessing Home Node via SSH

Your home node is accessible via the Dropbear Secure Shell (SSH) server.

Ethernet Port

The 4 Ethernet ports that are provided with your router should be configured as follows:

1. Private network with DHCP of 172.30.0.x network addresses 2. Public network with DHCP of 100.64.x.x network addresses (SudoMesh network) 3. NotDHCP for Extender 1 4. NotDHCP for Extender 2

NotDHCP is a network configuration service developed by SudoMesh for the extender antennas.

This may not apply to your router. For instance, the TP-Link N750 uses the opposite port assignment, with port 3 for private network, and port 4 for public SudoMesh/PeoplesOpen.net network.

Network Settings

The private network configuration uses the 172.30.0.x network. You should be able to rely on DHCP, or configure a static IP address within this network by using the following settings.

• IP Address: 172.30.0.9
• Netmask: 255.255.255.0
• Gateway: 172.30.0.1

See Network Configuration Guides: Linux Mac

Default Build Configuration

The IP address of your home node is 172.22.0.1 prior to configuration via the makenode utility. You can SSH into the node as root using the password 'meshtheplanet'.

Post Makenode Configuration

The IP of your home node on the private network is 172.30.0.1, with the root password you specified when running makenode to configure it.

 ssh root@172.30.0.1
 The authenticity of host '172.30.0.1 (172.30.0.1)' can't be established.
 RSA key fingerprint is b8:9d:4a:2f:1b:f5:e1:ae:b8:19:5b:70:92:8b:7f:34.
 Are you sure you want to continue connecting (yes/no)? 

After accepting the key by entering 'yes' and pressing ENTER, it will ask you for the root password.

SSH Keys

If you'd like to add your ssh key to the router (instead of using a root password), add it to the configs/authorized_keys file. You'll see that there are 3 other keys there for our developers. You can remove them if you'd like, but they're currently the only way we can provide remote support. During the alpha test phase we ask that you consider whether you are able to do diagnostics/debugging yourself before you remove them.

Discovering Network Configuration

IP

Run ip addr show to discover the IP addresses assigned to your home node.

IW

Use iw to inspect the wireless interfaces that are configured.

iw phy will display physical interfaces and capabilities, seeing each radio that is available.

iw dev will display devices

Switch Configuration

swconfig is an OpenWRT binary for switch configuration. The routers have a switch that can be used to recognized Virtual LAN (VLAN). You 5 different Ethernet devices, but it's not that there are 5 different Ethernet interfaces, but instead the router is a switch that uses VLANs. You can configure traffic coming in on a specific VLAN so that it can be recognized (VLAN tagged) and routed as needed. You can have multiple layer 2 Ethernet networks on the same wire.

Use swconfig to see if there are other switches available by running `swconfig list`. Once you identify the device, run `swconfig dev eth0 show`. You will see the various physical ports first, then you will see each VLAN.

The uplink port may show up in the list depending on the device.

Get the IP for the extenders from: less /etc/config/notdhcpserver

There is a library that can be used to read from this config file, as well as a command, called `uci` (unified configuration interface) that allows you to obtain information such as the IP address of the extender nodes.

 uci show notdhcpserver
 uci show notdhcpserver[0].addresses

Debugging

Babel provides the entire routing table for the network.

 babeld -i

This provides you with the data on every node on the entire network. Everything connected to the mesh that you can reach will be listed (nodes and extender nodes, not hosts).

babel is the daemon that broadcasts routes that are available via the ad-hoc network connection. The age provides how long ago the node announced it's existence. When a node becomes too old, it gets dropped from the table.

The mesh node will always try to route via the node that has the lowest metric. It tracks the metric also. The 'nexthop' value helps provide information used for routing. It's very lightweight, not complex.

We're using a modified version of babel. It wasn't possible to dynamically configure babel while it is running, so we added that feature. Right now your mesh node is routing traffic to the exit node that SudoMesh / PeoplesOpen.net setup, which is the gateway from the VPN to the Internet.

Extender Node

In the sudowrt-firmware code on Github, there is a file under openwrt_config/packages.extender-node contains the packages that are installed in the extender node.

libopenssl, uhttpd and uttpd-mod-ubus (module for uhttpd that acts as proxy between HTTP interface and local ubus, running on port 80)

It would be ideal to have an SSL between. Marc has this ready, he'll apply this later after a ubus solution is implemented.

You do have to provide a password when accessing the ubus interface. That may not be setup with extender nodes.

The extenders are registered with notdhcp, so it would also be best if we could ask notdhcp for the passwords needed to auth and communicate with the ubus HTTP. It's currently not possible to ask notdhcp for that information while it's running (but planned to be implemented).