This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
md:openwrt-meshdesk_17 [2021/11/20 05:45] – admin | md:openwrt-meshdesk_17 [2021/11/20 18:18] (current) – [captive_portal.json] admin | ||
---|---|---|---|
Line 96: | Line 96: | ||
| **libuci-lua** | | **libuci-lua** | ||
| **luci** | | **luci** | ||
- | | **luci-compat** | ||
| **luci-app-meshdesk** | | **luci-app-meshdesk** | ||
| **luci-theme-material** | | **luci-theme-material** | ||
| **luci-lib-httpclient** | | **luci-lib-httpclient** | ||
- | | **luci-lib-httpprotoutils** | ||
| **luci-lib-json** | | **luci-lib-json** | ||
| **luci-lib-jsonc** | | **luci-lib-jsonc** | ||
- | | **coova-chilli** | Network -> Captive Portals | Select **OpenSSL** as **SSL Library**. Also select **Enable the JSON interface..** and **..Coova miniportal...** | | + | | coova-chilli |
| **curl** | | **curl** | ||
| **relayd** | | **relayd** | ||
- | | **wpad IEEE 802.1x Auth/ | + | | batctl |
- | | batctl-full | Network | + | |
| mosquitto-client-ssl | Network | Note the **CLIENT** package | | | mosquitto-client-ssl | Network | Note the **CLIENT** package | | ||
+ | | wpad IEEE 802.1x Auth/ | ||
* After you selected these packages you can save the configuration and issue **make** to build the firmware. | * After you selected these packages you can save the configuration and issue **make** to build the firmware. | ||
Line 114: | Line 112: | ||
* Username and Password is **root** and **admin** for Luci and ssh. | * Username and Password is **root** and **admin** for Luci and ssh. | ||
* The next section will cover the files you have to attend to for the specific hardware tweaks. | * The next section will cover the files you have to attend to for the specific hardware tweaks. | ||
+ | |||
+ | <WRAP center round info 90%> | ||
+ | Although the **OM2P** has 16M FLASH there is a 7M fail-safe partition which complicates things a bit. | ||
+ | To keep things small I // | ||
+ | </ | ||
+ | |||
+ | |||
+ | ===== Initial File Preparation ===== | ||
+ | * Use ssh to gain access to the device in order to tweak these files. | ||
+ | ==== wan_network ==== | ||
+ | * Refer to the default **/ | ||
+ | <file bash network> | ||
+ | config interface ' | ||
+ | option ifname ' | ||
+ | option proto ' | ||
+ | option ipaddr ' | ||
+ | option netmask ' | ||
+ | |||
+ | config globals ' | ||
+ | option ula_prefix ' | ||
+ | |||
+ | config interface ' | ||
+ | option type ' | ||
+ | option ifname ' | ||
+ | option proto ' | ||
+ | option ipaddr ' | ||
+ | option netmask ' | ||
+ | option ip6assign ' | ||
+ | |||
+ | config interface ' | ||
+ | option ifname ' | ||
+ | option proto ' | ||
+ | |||
+ | config interface ' | ||
+ | option ifname ' | ||
+ | option proto ' | ||
+ | |||
+ | </ | ||
+ | * With this setup we have the POE port as LAN (The port next to the Power Jack). | ||
+ | * We also have the WAN sitting next to the antenna. | ||
+ | * This is **not ideal** for us since we want to feed power onto the WAN port. | ||
+ | * Next look at the **/ | ||
+ | <file bash wan_network> | ||
+ | config interface ' | ||
+ | option proto ' | ||
+ | option ipaddr ' | ||
+ | option netmask ' | ||
+ | option ifname ' | ||
+ | |||
+ | config interface ' | ||
+ | option ifname ' | ||
+ | option type ' | ||
+ | option proto ' | ||
+ | |||
+ | config interface ' | ||
+ | option proto ' | ||
+ | |||
+ | config interface ' | ||
+ | option proto ' | ||
+ | |||
+ | </ | ||
+ | * Note there are no **switch** sections. Please refer to the other Wiki pages on the convention to use if the //network// file has **switch** sections. | ||
+ | * **client_0** and **client_1** interface sections can always be kept as is. | ||
+ | * **lan** interface section is in actuality the **WAN** port. (This is due to the historical nature of the project and also that we support hardware with a single Ethernet port) | ||
+ | * Since we wanted the port with POE (eth0) as WAN we actually kept the membership of the **lan** interface as is (remember it is actually the **WAN** port) | ||
+ | * Next we will look at the /// | ||
+ | |||
+ | <WRAP center round tip 90%> | ||
+ | * There is a growing list of existing sample **wan_network** files under the /// | ||
+ | * They have a convention of **network_< | ||
+ | * Simply copy that file over // | ||
+ | * Those files will have a matching existing hardware section in the // | ||
+ | </ | ||
+ | ==== meshdesk ==== | ||
+ | === Tweaks For Our Hardware === | ||
+ | * MESHdesk use the LEDs of the device it is installed on to signal about the environment | ||
+ | * It signals during startup about the method it uses to try and fetch its settings at that moment. | ||
+ | * If the device is used in a mesh network it will signal how many neighboring nodes it sees after startup. | ||
+ | * There is also another LED used to indicate if the device has proper contact with the controller. (The LED can be either ON or OFF in such a case) | ||
+ | * Finally on mesh networks we can also specify a LED that will indicate mesh traffic flowing through a node. | ||
+ | * Again lets look at the **OM2P** as a sample. | ||
+ | <code bash> | ||
+ | #change directory to where the LEDs are | ||
+ | cd / | ||
+ | ls | ||
+ | #These are the LEDs available | ||
+ | ath9k-phy0 | ||
+ | #turn it off | ||
+ | echo " | ||
+ | #turn it on | ||
+ | echo " | ||
+ | #Go through all of them and confirm which is which on the device | ||
+ | </ | ||
+ | * This device has an interesting LED. It is the **tricolor wifi** LED. | ||
+ | * In our case we can use the **om2p: | ||
+ | * We can also use the **om2p: | ||
+ | * We can use the **om2p: | ||
+ | * We can use **om2p: | ||
+ | * With this info we can create a hardware section in /// | ||
+ | <code bash> | ||
+ | config hardware ' | ||
+ | option morse_led '/ | ||
+ | option internet_led '/ | ||
+ | option wifi_led ' | ||
+ | </ | ||
+ | * This have to match the value for hardware under the **settings** section | ||
+ | <code bash> | ||
+ | config settings ' | ||
+ | option hardware ' | ||
+ | option id_if ' | ||
+ | option lan_up_file '/ | ||
+ | </ | ||
+ | <WRAP center round info 90%> | ||
+ | Don't make the name of the hardware section more than 14characters. Longer names break things during deployment. | ||
+ | </ | ||
+ | |||
+ | * Later we will also use the value of **om2p** to define the hardware on the controller. | ||
+ | * The final tweak for the hardware in the config file is the interface that must be used as the **id_if**. | ||
+ | * It will typically be **eth0**. | ||
+ | * Since we want the **yellow LED** to be off when the comms to the controller is fine we need to check what the current setup is | ||
+ | * With this device we also want to light up the green LED when the comms is fine. | ||
+ | <code bash> | ||
+ | vi / | ||
+ | #Look for this section | ||
+ | if(ok_flag)then | ||
+ | internetLED(' | ||
+ | checkForContollerReboot(' | ||
+ | else | ||
+ | internetLED(' | ||
+ | checkForContollerReboot(' | ||
+ | end | ||
+ | | ||
+ | #Also modify the internetLED function to look like this: | ||
+ | function internetLED(state) | ||
+ | local hardware | ||
+ | local led = x.get(' | ||
+ | if(state == ' | ||
+ | | ||
+ | end | ||
+ | if(state == ' | ||
+ | | ||
+ | end | ||
+ | os.execute(' | ||
+ | end | ||
+ | |||
+ | </ | ||
+ | |||
+ | * To activate the mesh traffic indicator LED you need to edit the /// | ||
+ | * See this snippet as reference. | ||
+ | <file bash> | ||
+ | |||
+ | config led ' | ||
+ | option name ' | ||
+ | option trigger ' | ||
+ | option dev ' | ||
+ | option mode 'link tx rx' | ||
+ | option sysfs ' | ||
+ | </ | ||
+ | |||
+ | * The following table lists some of the important items with comments | ||
+ | |||
+ | ^ Item ^ Typical value ^ Comment | ||
+ | | settings -> hardware | om2p | Must match a hw definition in the file itself | ||
+ | | settings -> id_if | eth0 | eg eth0, eth1 or wan - NOT eth0.1 (for those boards its just eth0) | | ||
+ | | settings -> skip_radio_0 | ||
+ | |||
+ | === Tweaks For Our Environment === | ||
+ | * The following table lists some of the important items with comments | ||
+ | |||
+ | ^ Item ^ Typical value ^ Comment | ||
+ | | internet1 -> disabled | ||
+ | | internet1 -> dns | cloud.radiusdesk.com | ||
+ | | internet1 -> protocol | https | Can be http or https | | ||
+ | | internet1 -> ip | 176.31.15.210 | Fallback when FQDN does not resolve on FQDN not used | | ||
+ | |||
+ | * We are nearly done. The last stop is to edit the **captive_config.json** file to fit our specific hardware. | ||
+ | |||
+ | |||
+ | ==== captive_portal.json ==== | ||
+ | * Edit the file /// | ||
+ | * This file is a JSON structure that the device uses as a reference to configure itself with a special captive portal when it is not yet managed by the controller. | ||
+ | * There are only two items that might need to be tweaked | ||
+ | * The radio number for the 2.4G band. | ||
+ | * The **ifname** for the **lan** interface (We use the WAN port in out implementation) | ||
+ | * With the **OM2P** radio0 is the 2.4G radio so no need to tweak that item. (If the hardware has radio1 as the 2.4G band simply look for all the references to **radio0** and make them radio1) | ||
+ | * See this snippet of a device which has radio1 using the 2.4G band | ||
+ | <code javascript> | ||
+ | " | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | }, | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | }, | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | } | ||
+ | ], | ||
+ | </ | ||
+ | * With the **OM2P** the **ifname** we use is **eth0** for the **lan** interface definition. | ||
+ | <code javascript> | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | }, | ||
+ | </ | ||
+ | * Once the tweaks are completed we can test everything out. | ||
+ | * The following link shows how to point the device to the controller using the GUI. | ||
+ | * [[2021: | ||
+ | * Point the device to your controller and reboot it. | ||
+ | * If all goes well it will show up in **Unknown Nodes** | ||
+ | * If it is a new hardware type add it to the controller as described here: [[2021: | ||
+ | * [[md: | ||
+ | |||
+ | ===== The Final Built ===== | ||
+ | * If everything on the device work as intended you can use those tweaked files to build a final version of the firmware for the specific hardware. | ||
+ | * Copy the files to a temporary folder on the machine where you are building the firmware. | ||
+ | * Use the following as a lookup for the location inside the SDK where the tweaked files need to go. | ||
+ | |||
+ | ^On Device | ||
+ | |/ | ||
+ | |/ | ||
+ | |/ | ||
+ | |/ | ||
+ | |||
+ | * This brings us to the end of the page on how to build MESHdesk firmware for specific hardware. | ||
+ |