Mesh/Firmware/Overview

Revision as of 20:26, 5 May 2016 by Redconfetti (talk | contribs) (Redconfetti moved page Mesh Home Node Internals to Mesh/Home Node Internals: consistent use for mesh page naming convention)

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.

OpenWRT Build

The SudoMesh project maintains firmware builds for a certain set of Wireless routers (home nodes) and extender antennas. The code used to create these builds is available in SudoWRT-Firmware. These firmware builds are a

Included Software Packages

The SudoWRT-Firmware code contains a configured list of software packages that are included within the builds for home nodes and the extender antennas.

libopenssl

[libopenssl]

uhttpd

uhttpd is an efficient and stable web server daemon, suitable for lightweight tasks commonly used with embedded devices and proper integration with OpenWrt's configuration framework (UCI). In particular, it is configured by default for the LuCI web interface to administer OpenWrt.

uhttpd-mod-ubus

uhttpd-mod-ubus is a module for uhttpd that acts as a proxy between the HTTP interface of the home node, and the local ubus that is available to processes running on the home node.

Web Interface

The web interface for OpenWRT is supported by a framework of components known as LuCI.

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

Babeld

Babel provides the entire routing table for the network.

 babeld -i

This provides you with the data on every node on the entire network. Every node and extender node connected to the mesh that you can reach will be listed. babeld is the daemon that broadcasts routes that are available via the ad-hoc network connection (pplsopen.net-node2node). The age shown in the output provides how long ago the node announced it's existence on the network. 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.

SudoMesh uses a modified version of babeld, with support for adding or removing interfaces while babeld is running added.

Exit Node

Every home node routes traffic to the exit node that was setup for PeoplesOpen.net. This exit node acts as the gateway from the Virtual Private Network (VPN) used by PeoplesOpen.net to contain the SudoMesh network to the Internet.

Extender Antenna Nodes

A client/server system called notdhcp was developed to help extender nodes obtain an IP address and establish a trust relationship with a SudoMesh home node upon physical connection.

As of May 2016 the wired interface between the extender node and the home node does not use SSL for communication, however this is planned for implementation after the completion of the ubus-https-forwarder.

The ubus-https-forwarder software will be responsible for enabling the home nodes to receive requests on the HTTP interface provided by uhttpd-mod-ubus that are addressed for the extender nodes instead of the home node, and then forwarding those requests to the extender nodes.

Authentication is required when accessing the ubus HTTP interface, which may not yet be setup for the extender nodes. A possible approach is to update notdhcp so that it provisions a password to the extender node upon physical connection. Then the notdhcp server could make the password available to the home node or the web interface client.