firmware-ng FAQ

If your question is not answered in the FAQ feel free to open a ticket.

How to login using SSH ?

Each node comes with an active SSH server that allows you to login into your nodes using the root password you configured on the dashboard. However, due to the bridged nature of firmware-ng you can only connect to one of your gateways (via the IP address it received from your DHCP server). Once on your gateway you can connect to any node in the network by either using the 5.x.x.x addresses shown on the dashboard or the node names you configured:

ssh root@5.x.x.x
ssh root@my_node_name

Note: Some characters are not allowed to be used in node names and have to be mangled, therefore the node names might differ. In case you experience difficulties consult the '/etc/hosts/' file.

Beware: It won't be possible to SSH into a node on SSID!#1 if chilli is active or SSID!#2 if bridge mode is active.

How to force a dashboard checkin from the commandline ?

Run:

dashboard checkin

How to configure my firewall to allow the nodes to operate ?

Each node needs to connect to the dashboard (HTTP - port 80) to send its check in data:

www.cloudtrax.com

There are a number of servers powering the dashboard with various IP addresses behind a loadbalancer. Configure your firewall with the DNS name (if possible) because the resolved IP addresses can change any time.

For the over-the-air firmware upgrades / packages / hotfixes the nodes need to be able to connect to our file server (HTTP - port 80):

dev.cloudtrax.com

Again, the resolving IP addresses might change.

To debug hard-to-track problems right in your network our nodes are equipped with a tunnel software allowing us to connect via SSH (TCP - port 18991):

vpn.cloudtrax.com

For denying the nodes to establish this connection back to us it suffices to block access to vpn.cloudtrax.com (fixed IP).

I have unchecked 'disable upgrades' and a new firmware version is out, still my network does not upgrade ?

In order to avoid orphaned nodes the dashboard won't start the upgrade as long as not all nodes in your network are online. Bring all nodes online or remove offline nodes from your network to start the upgrade.

How does the internet availability check work ?

The preferred way of checking for internet availability is a UDP based traceroute to the the following IP addresses (in a random manner):

* 198.41.0.4
* 192.33.4.12
* 128.8.10.90
* 192.5.5.241
* 192.36.148.17
* 192.58.128.30
* 193.0.14.129
* 198.32.64.12
* 202.12.27.33

However, if neither of these IPs can't be reached via traceroute firmware-ng will try a HTTP based "ping" to the following URLs:

* google.com
* yahoo.com
* alltheweb.com

If that also fails firmware-ng will try to download a page from checkin.cloudtrax.com as a last resort.

What is the 'lonely mode' good for ?

If 4 internet checks in a row fail, the node will fallback into 'lonely mode'. The node assumes that it operates on a wrong WiFi channel (the channel might have been changed). In lonely mode the node scans through all channels in the hope to find internet somewhere else. Scanning all channels takes roughly 5-6 minutes.

Note: In this mode normal WiFi operations (SSID!#1 / SSID!#2) are disabled otherwise the node would not be able to scan & switch channels.

How does the custom.sh feature work ?

Fill the "custom.sh" field (under Advanced) with the URL (domain + folder) which contains your "custom.sh" script including the trailing slash. For example:

http://www.mydomain.com/subfolder/

The firmware will download the "custom.sh" file from that location each time the dashboard sends a full configuration reply to the device (mainly happens when the 'update network settings' button is pushed). Then its md5 checksum is compared with the previously executed custom.sh file. If the md5 checksum mismatch (the custom.sh has been altered) the custom.sh is executed otherwise it is not, thus ensuring each device executes the custom.sh file only once.

The custom.sh file itself is deleted after the firmware ran it. Only the md5 checksum is stored in the uci config system. To verify whether or not your script ran you can retrieve the checksum with:

uci get node.setting.cs_md5

Note that if you wish to run your script more than once (without altering it) you need to delete the stored md5 checksum and force a dashboard config reload by pushing the 'update network settings' button. Because downloading the script over and over is neither efficient nor feasible (you would have to keep pushing the button) it is recommended you install a permanent script onto the device and link it to one of the special purpose folders firmware-ng comes with:

  • /etc/cron.5mins/ - Every script in this folder will be executed every 5 minutes.
  • /etc/cron.hourly/ - Every script in this folder will be executed once per hour.
  • /etc/online.d/ - Every script beginning with a capital 'S' (as in 'start') followed by a number (e.g. 'S13') will be executed as soon an internet connection has been detected. If the script name begins with a 'K' (as in 'kill') followed by a number the script is executed when the internet connection is lost. The purpose of the number is to define the sequence in which the scripts are called.

A number of sample scripts can be found here: custom scripts

What IP address space does NG use and how does it avoid IP collisions ?

Each node in a network potentially can become a gateway and start distributing IP addresses via DHCP on all active SSIDs (only gateways run a DHCP server). To avoid IP address collisions from the numerous gateways a network can have the dashboard has to send each node an identifier (so-called 'node id') from which firmware-ng will derive its unique (collision free) IP address space.

Firmware-ng divides the available 32Bit IP address space as follows:

<8Bit Class A net><14Bit network><10Bit host>

The 10 Bit host part allow a maximum of 1024 simultaneous clients per SSID per gateway.

An example with a node id of '1':

SSID#1: 10.255.240.1/22
SSID#2: 10.255.236.1/22

As shown firmware-ng will start with the highest bits counting downwards to avoid IP collisions with the LAN as well. To further reduce the likelihood of LAN IP collisions firmware-ng gateways will compare their IP address space with the LAN's address space and can change to the 172.16.x.x address space in case of a collision.

Why is my OpenMesh device unable to resolve some DNS entries ?

Firmware-ng always discards DNS responses if the domain is a valid internet domain (FQDN) and the resolved IP address a local address (192.168.x.x, 10.x.x.x, etc - see RFC1918 for details) as these replies could be part of a security breach attempt (search for 'DNS rebinding attack' for more information about the attack).

The protection can be disabled at your own risk. Our custom.sh snippet should provide a starting point for the configuration of your network.

What does the AP isolation setting do and which SSID / devices does it affect ?

AP isolation prevents client devices to exchange data with other client devices and is often seen as a way to make the network more secure. A malicious client device won't be able to attack other client devices connected to the same network.

ng4xx: Enabling AP isolation affects SSID#1 and SSID#2 wireless clients. Wired clients are not isolated.
ng5xx: Enabling AP isolation affects SSID#1 only. Wired clients are isolated as well.

What does the Gateway LAN Block setting do and which SSID does it affect ?

The Gateway LAN Block feature aims to deny access to resources in the LAN. If enabled client traffic (wireless and wired) to 192.168.x.x/16, 172.16.x.x/12 and 10.x.x.x/8 is dropped at the AP and not forwarded to the LAN. This setting affects SSID#1 only.