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 18:10] – admin | md:openwrt-meshdesk_17 [2021/11/20 18:18] (current) – [captive_portal.json] admin | ||
|---|---|---|---|
| Line 288: | 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. | ||