Accessing Home Node via SSH
Your home node is accessible via the Dropbear Secure Shell (SSH) server.
The private network configuration uses the 172.22.0.x network.
Reconfigure your machine to use the following network settings, then connect it to Ethernet port 1 to connect on the local private network interface.
- IP Address: 172.22.0.9
- Netmask: 255.255.255.0
- Gateway: 0.0.0.0
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 firstname.lastname@example.org 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.
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.
Run ip addr show to discover the IP addresses assigned to your home node. Use iw addr show to see 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
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.addresses
``` babeld -i ```
Provides the entire babel routing table. 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.
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).