How the MESHdesk firmware works

  • The following flow diagram indicates the steps a node takes to fetch its settings.

A typical Request and Reply

What the node requests from the server

  • We assume the node is a gateway node with a MAC Address of AC:86:74:10:03:08 and the MESHdesk server is on
  • We run a 'tail -f' on the web server's access log file.
  • Note that gateway=true - - [06/Feb/2014:09:59:13 +0200] "GET /cake2/rd_cake/nodes/get_config_for_node.json?mac=AC-86-74-10-03-08&gateway=true HTTP/1.1" 200 2247 "-" "Wget"
  • We now have our gateway node and can start the other nodes who will fetch their settings through the hidden configuration AP which forms part of every mesh managed by MESHdesk.
  • Here is the entry when the node with MAC Address AC:86:74:10:03:10 fetched it's settings. Note that gateway=false. - - [06/Feb/2014:10:05:59 +0200] "GET /cake2/rd_cake/nodes/get_config_for_node.json?mac=AC-86-74-10-03-10&gateway=false HTTP/1.1" 200 2049 "-" "Wget"

What the server replies

  • Time to see what out server has to say for himself!
  • The feedback of course will depend on the how the mesh is defined.
  • The feedback will also depend on the fact that a node can be a gateway node or an standard node.
  • Here is the feedback if the node was specified as a gateway node:
      {"interface":"lan","options":{"ifname":"eth0 eth1","type":"bridge","proto":"dhcp"}},
      {"interface":"ex_two","options":{"ifname":"bat0.2 eth0.100 eth1.100","type":"bridge"}},
      {"interface":"ex_two","options":{"ifname":"bat0.2 eth0.100 eth1.100","type":"bridge"}},
      {"interface":"ex_three","options":{"ifname":"bat0.3 eth0.101 eth1.101","type":"bridge"}},
      {"interface":"ex_three","options":{"ifname":"bat0.3 eth0.101 eth1.101","type":"bridge"}},
      {"interface":"ex_four","options":{"ifname":"bat0.4 eth0.103 eth1.103","type":"bridge"}},
      {"interface":"ex_four","options":{"ifname":"bat0.4 eth0.103 eth1.103","type":"bridge"}},
  • Here's the feedback for a normal node:
{"interface":"lan","options":{"ifname":"eth0 eth1","type":"bridge","proto":"dhcp"}},

Flashing LEDs

A well designed interface is done in such a way that it is easy for you to interact with and easy to read. We use these principles with the nodes on which the MESHdesk firmware are running.

Where possible we use three LEDs to allow a mesh node to report visually about its status at a glance:

  • Morse LED is is used to flash a Morse code about:
    • The stages of the setup process
    • After setup it will flash a digital Morse code number to indicate how many neighbor nodes it sees.
  • Wifi LED will be associated with the working and traffic on the Batman-adv mesh.
  • Internet LED will be on if the node can get onto the Internet
  • Morse LED will be used to indicate which stage the process of setting up the node is in. We use the old tried and trusted Morse code flashing.
Text Morse code Meaning
A . _ Starting up - waiting for LAN
B _ . . . LAN is up - Trying for the Config server
C _ . _ . Conf server not available through LAN - Bring up WiFi
D _ . . Conf server reached - Applying latest config
E . Conf server down - Applying previous config
I . . Running the pre-configure code
SOS . . . _ _ _ . . . Conf server down No previous config to use
  • After the setup the node will continuously ask the Batman-adv daemon how many direct neighbors it sees and flash a Morse code digital number to indicate the count. If there is none around the Morse LED will be off.
Text Morse code Meaning
1 . _ _ _ _ One
2 . . _ _ _ Two
3 . . . _ _ Three
4 . . . . _ Four
5 . . . . . Five
6 _ . . . . Six
7 _ _ . . . Seven
8 _ _ _ . . Eight
9 _ _ _ _ . Nine
0 _ _ _ _ _ Ten or more
  • Wifi LED will be used to indicate if the bat0 (mesh interface) is up. This LED will also indicate when traffic flows through it by flashing proportionally to the traffic flow.
  • Internet LED may not come up immediately on non-gateway nodes but should come up after 5 minutes provided that the gateway node has Internet connectivity.

The Internet LED is actually an indication that the Alfred daemon could report the mesh status fine back to the MESHdesk server. So this light might actually be on without Internet connection if the MESHdesk server runs local.

Fetching settings through mesh

MESHdesk nodes which are not directly connected to a LAN will be able to reach the configuration server in the following way.

  • Each gateway node of a MESHdesk defined mesh network will run a NAT/DHCP termination point.
  • This NAT/DHCP termination point will be propagated through the mesh and accessible through a hidden SSID.
  • This hidden SSID is secured through WPA2 Personal security.
  • If a node that is not connected to the LAN starts up; the MESHdesk script will try to connect this node to this hidden SSID.
  • If successful it will subsequently try to fetch its settings through the mesh by means of this hidden SSID.


  • A node belonging to one mesh can get its settings through the hidden SSID of another mesh.
  • When these settings are applied by the node; the node can potentially move to another mesh.
  • This will allow two or more mesh networks to co-exist while still be separate since the ad-hoc Wi-Fi network in which each mesh network rely will be unique and exclusive.
  • Their hidden SSID used to obtain the configuration settings however will be common between all MESHdesk networks.

Reporting the status of the mesh

  • We use the Alfred daemon to collect and report collectively the status of the mesh.
  • This reduces traffic since only one node (typically the gateway node) will fulfill this function.
  • When a node starts up it will determine whether it is a gateway node or not.
  • If it is a gateway node, Alfred will be started in master mode.
  • If it is not, Alfred will be started in slave mode.
  • The server can also reply to each status report from a mesh. The reply can contain the following:
    • Reboot request for a node.
    • Reload request for a node.
    • Execute instructions for a node.
  • A node will then periodically ask on the Alfred 'bus' if there are any instructions for him. If so; it will confirm with the back end by asking the back-end directly for its instructions.
  • Again this way we reduce traffic to the back-end when we use one node as a proxy.