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 17:37] – [Select Packages To Include With Firmware] admin | md:openwrt-meshdesk_17 [2021/11/20 18:18] (current) – [captive_portal.json] admin | ||
|---|---|---|---|
| Line 112: | 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 ===== | ===== Initial File Preparation ===== | ||
| Line 186: | Line 192: | ||
| * 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) | * 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. | * Finally on mesh networks we can also specify a LED that will indicate mesh traffic flowing through a node. | ||
| - | * Again lets look at the **Xiaomi 4A 100M** as a sample. | + | * Again lets look at the **OM2P** as a sample. |
| <code bash> | <code bash> | ||
| #change directory to where the LEDs are | #change directory to where the LEDs are | ||
| Line 192: | Line 198: | ||
| ls | ls | ||
| #These are the LEDs available | #These are the LEDs available | ||
| - | blue: | + | ath9k-phy0 |
| #turn it off | #turn it off | ||
| - | echo " | + | echo " |
| #turn it on | #turn it on | ||
| - | echo " | + | echo " |
| - | #turn it off | + | #Go through all of them and confirm which is which on the device |
| - | echo " | + | |
| - | #turn it on | + | |
| - | echo " | + | |
| </ | </ | ||
| - | * In our case we can use the **yellow | + | |
| - | * We can use the **blue LED** to signal during startup and neighbor counts. | + | |
| - | * There is no extra LED so we will not define one for the mesh traffic. | + | * We can also use the **om2p: |
| + | * We can use the **om2p:blue:wan LED** to signal during startup and neighbor counts. | ||
| + | * We can use **om2p: | ||
| * With this info we can create a hardware section in /// | * With this info we can create a hardware section in /// | ||
| <code bash> | <code bash> | ||
| - | config hardware 'xiaomi_4a_100' | + | config hardware 'om2p' |
| - | option morse_led '/ | + | option morse_led '/ |
| - | option internet_led '/ | + | option internet_led '/ |
| - | option wifi_led 'led0' | + | option wifi_led 'om2p: |
| </ | </ | ||
| * This have to match the value for hardware under the **settings** section | * This have to match the value for hardware under the **settings** section | ||
| <code bash> | <code bash> | ||
| config settings ' | config settings ' | ||
| - | option hardware 'xiaomi_4a_100' | + | option hardware 'om2p' |
| option id_if ' | option id_if ' | ||
| option lan_up_file '/ | option lan_up_file '/ | ||
| Line 223: | Line 228: | ||
| </ | </ | ||
| - | * Later we will also use the value of **xiaomi_4a_100** to define the hardware on the controller. | + | * 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**. | * 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**. | * It will typically be **eth0**. | ||
| - | * On devices like the MT7621 based boards it will typically be **wan**. | ||
| * 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 | * 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> | <code bash> | ||
| vi / | vi / | ||
| Line 238: | Line 243: | ||
| checkForContollerReboot(' | checkForContollerReboot(' | ||
| end | 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 | * The following table lists some of the important items with comments | ||
| ^ Item ^ Typical value ^ Comment | ^ Item ^ Typical value ^ Comment | ||
| - | | settings -> hardware | xiaomi_4a_100 | + | | 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 -> id_if | eth0 | eg eth0, eth1 or wan - NOT eth0.1 (for those boards its just eth0) | | ||
| | settings -> skip_radio_0 | | settings -> skip_radio_0 | ||
| Line 257: | Line 288: | ||
| * We are nearly done. The last stop is to edit the **captive_config.json** file to fit our specific hardware. | * 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. | ||