Difference between revisions of "Mesh/Firmware/Overview"

Jump to navigation Jump to search
m
Redconfetti moved page Mesh/SudoWRT Tour to Mesh/Firmware/Overview: overview for misc notes and links to other more detailed pages
m (Redconfetti moved page Mesh/SudoWRT Tour to Mesh/Firmware/Overview: overview for misc notes and links to other more detailed pages)
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Accessing Home Node via SSH =
= OpenWRT Build =


Your home node is accessible via the [https://wiki.openwrt.org/doc/uci/dropbear Dropbear] Secure Shell (SSH) server.
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 [https://github.com/sudomesh/sudowrt-firmware SudoWRT-Firmware].


== Ethernet Port ==
== Included Software Packages ==


The 4 Ethernet ports that are provided with your router should be configured as follows:
The SudoWRT-Firmware code contains a configured list of software packages that are included within the builds for home nodes and the extender antennas.


1. Private network with DHCP of 172.30.0.x network addresses
* Home Node Packages - [https://github.com/sudomesh/sudowrt-firmware/blob/master/openwrt_config/packages openwrt_config/packages].  
2. Public network with DHCP of 100.64.x.x network addresses (SudoMesh network)
* Extender Antenna Packages - [https://github.com/sudomesh/sudowrt-firmware/blob/master/openwrt_config/packages.extender-node openwrt_config/packages.extender-node]
3. NotDHCP for Extender 1
4. NotDHCP for Extender 2


[https://github.com/sudomesh/notdhcp NotDHCP] is a network configuration service developed by SudoMesh for the extender antennas.
=== uhttpd ===


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.
[https://wiki.openwrt.org/doc/howto/http.uhttpd uhttpd] is an efficient and stable web server daemon, suitable for lightweight tasks commonly used with embedded devices and proper integration with [https://wiki.openwrt.org/doc/uci OpenWrt's configuration framework (UCI)]. In particular, it is configured by default for the [https://wiki.openwrt.org/doc/techref/luci LuCI web interface] to administer OpenWrt. SudoMesh uses it's own [https://github.com/sudomesh/sudowrt-web-ui SudoWRT-Web-UI], see [[Mesh/Firmware/Web_Admin_Development]] for more information.


== Network Settings ==
=== uhttpd-mod-ubus ===


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.
[https://wiki.openwrt.org/doc/techref/ubus#access_to_ubus_over_http 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.


* IP Address: 172.30.0.9
= Web Interface =
* Netmask: 255.255.255.0
* Gateway: 172.30.0.1


See Network Configuration Guides: [https://sudoroom.org/wiki/Mesh/Network%20Configuration%20for%20Linux Linux] [https://sudoroom.org/wiki/Mesh/Network%20Configuration%20for%20MacOS%20X Mac]
The [https://wiki.openwrt.org/doc/howto/webinterface.overview web interface] for OpenWRT is supported by a framework of components known as [https://wiki.openwrt.org/doc/techref/luci LuCI].
 
== Default Build Configuration ==
 
The IP address of your home node is <tt>172.22.0.1</tt> prior to configuration via the [https://github.com/sudomesh/makenode makenode] utility. You can SSH into the node as <tt>root</tt> using the password 'meshtheplanet'.
 
== Post Makenode Configuration ==
 
The IP of your home node on the private network is <tt>172.30.0.1</tt>, with the root password you specified when running <tt>makenode</tt> 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 <tt>configs/authorized_keys</tt> 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 =
= Discovering Network Configuration =
Line 79: Line 56:
   uci show notdhcpserver[0].addresses
   uci show notdhcpserver[0].addresses


= Debugging =
= Babeld =


Babel provides the entire routing table for the network.
[https://wiki.openwrt.org/doc/uci/babeld Babel] provides the entire routing table for the network.


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


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.


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 [https://github.com/sudomesh/babeld babeld], with support for adding or removing interfaces while babeld is running added.  


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.
= Exit Node =


== Extender 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.


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.
= Extender Antenna Nodes =


libopenssl, uhttpd and uttpd-mod-ubus (module for uhttpd that acts as proxy between HTTP interface and local ubus, running on port 80)
A client/server system called [https://github.com/sudomesh/notdhcp notdhcp] was developed to help extender nodes obtain an IP address and establish a trust relationship with a SudoMesh home node upon physical connection.


It would be ideal to have an SSL between. Marc has this ready, he'll apply this later after a ubus solution is implemented.
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 [https://github.com/sudomesh/ubus-https-forwarder ubus-https-forwarder].


You do have to provide a password when accessing the ubus interface. That may not be setup with extender nodes.
The ubus-https-forwarder software will be responsible for enabling the home nodes to receive requests on the HTTP interface provided by [https://wiki.openwrt.org/doc/techref/ubus#access_to_ubus_over_http uhttpd-mod-ubus] that are addressed for the extender nodes instead of the home node, and then forwarding those requests to the 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).
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 [https://github.com/sudomesh/notdhcp 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.
128

edits

Navigation menu