meshdesk file

• The meshdesk configuration file follows the UCI conventions that are standard for OpenWrt.
• It has the following named sections:

• This section is used to activate or deactivate the central control of the hardware.
• The FQDN and IP address of the RADIUSdesk server and the URLs for certain actions are also specified here.

• The wifi-client section is used by hardware that has WiFi radios on to configure itself as a WiFi client.
• This WiFi client then attempts to connect to a hidden SSID contained in mesh networks to serve as an information station for other devices that are also centrally managed.

• This section is the only section which is unique according to the hardware.
• It will list the hardware id and the LEDs as well as the interface used for identity.
• It also includes other settings which tweak the behavior of the device when it is centrally managed.

• This section fine tunes the reporting parameters

• This section is used to specify WiFi client settings for the device when it uses WiFi for an Internet connection.

• Some default settings for CoovaChilli captive portal.

The only two sections you will typically tweak is the settings and internet sections.

• MESHdesk use the LEDs of the device on which it is installed to display information about the environment.
  • During startup, an LED indicates the method used to retrieve the settings from the controller.
  • After startup, when the device is used in a mesh network, this LED indicates how many neighboring nodes it sees.
  • A second LED indicates whether the device is in proper contact with the controller. (The LED can be either ON or OFF in such a case)
  • Finally, for mesh networks, we can also specify a third LED that indicates the mesh traffic flowing through a node.

• Let us take a look at the Xiaomi 4A 100M as an example.

#change directory to where the LEDs are
cd /sys/class/leds/
ls 
#These are the LEDs available
blue:power    mt76-phy0     mt76-phy1     yellow:power
#turn it off
echo "0" > yellow\:power/brightness
#turn it on
echo "1" > yellow\:power/brightness
#turn it off
echo "0" > blue\:power/brightness
#turn it on
echo "1" > blue\:power/brightness

• We can use the blue LED to signal during startup and neighbour counting.
• We can also use the yellow LED to signal that communication with the controller is interrupted.
• However, since there is no third LED, we will not define one for mesh traffic.

• With this information, we can create a hardware section in /etc/config/meshdesk

config hardware 'xiaomi_4a_100'
   option morse_led '/sys/class/leds/blue:power/brightness'
   option internet_led '/sys/class/leds/yellow:power/brightness'
   option wifi_led 'led0'

• There are two important options here to customize the
  • hardware - they must match the value of a hardware definition in the settings section.
  • id_if - must match the interface specified in the wan_network file.

config settings 'settings'
   option hardware 'xiaomi_4a_100'
   option id_if 'eth0'
   option lan_up_file '/tmp/lan_up'

• Later we will also use the value of xiaomi_4a_100 to define the hardware on the controller.

• We use the yellow LED as an alarm, i.e. it must light up when communication with the controller is interrupted.
• Since we do not want the yellow LED to light up when communication with the controller is OK, we need to check what the current setting is.

vi /etc/MESHdesk/reporting/report_to_server.lua 
#Look for this section
    if(ok_flag)then                                 
        internetLED('0'); -- NOTE Here we can swap them, e.g. 0 to turn off a red LED when the internet is OK
        checkForContollerReboot('1');                   
    else                                                                             
        internetLED('1');                                                        
        checkForContollerReboot('0');                  
    end

• The following table lists the most important points with comments

• Finally you need to adjust some items to match up with your controller and its environment.
• The following table lists some of the important items with comments

• We are almost finished. The last stop is to edit the captive_config.json file to customise it to our specific hardware.