Support for WiFi Client as an Internet connection

Introduction

Today, all of the commercial cloud based controllers we know about require that the hardware be connected to an Ethernet network running a DHCP server.
MESHdesk and APdesk was also like that until recently.
So we added support for 3G/4G dongles and were very proud if it until we hit the real world.
While we were going to deploy a mesh at one of our clients using our newly added support for 3G/4G dongles, they asked why can't we make use of their existing LTE router with WiFi and cut on the hardware costs. Then there's no need of an extra dongle and the mesh can have one less node which they have to pay for.
Since neither MESHdesk nor APdesk are driven by hardware sales but rather to provide creative solutions, we went back home and started working on a solution.
We can now with pride say we also support WiFi Client connections as an alternative to Ethernet and 3G/4G dongle based Internet connections.

Having a controller somewhere on the Internet where a device will fetch its settings from will require the device to have an Internet connection to start with.
If you use a WiFi Client connection to some Access Point there will be the requirement to specify to the device the SSID and optional security settings of the Access Point to which it will be a client.
This is where we use the MESHdesk Node Config Utility.
The utility now includes a WiFi Client tab to pre-configure the device to connect to an Access Point for Internet connectivity.
This is usually a once off setup and will be left unchanged until you maybe one day decide to disable it or to use another Access Point for Internet connectivity.
The first item to select on the WiFi Client tab is an Action
- Do Not Change will leave the device unchanged and without adding or removing any existing WiFi Client specific settings. This is the default and set during start-up.
- Enable will enable all the fields which you can then populate.
- Disable will disable an existing WiFi Client configuration (provided there is one)
- See the following screenshot which was for a sub-mesh. That is one mesh fed from another mesh.

Now that the device is pre-configured it can connect as a WiFi Client to an existing Access Point to get Internet access and fetch the rest of its settings from the RADIUSdesk server.

Remember that on single radio devices it adds another load on the radio so the throughput might suffer (provided you Internet connection is not the bottle neck)
This option opens up the door to have a high speed dual radio mesh with sub meshes hanging off the main mesh.
Remember that the channel the mesh runs on should be the same as the Access Point it connects to as a client.

The good news is that with this solution you do not need any additional hardware, in fact you'll probably use fewer nodes in your mesh.
All you need is to use the latest SVN code and build the MESHdesk firmware with the relayd package included as specified on this page: http://www.radiusdesk.com/old_wiki/technical_discussions/md_on_lede
On the exit points of both MESHdesk meshes and APdesk AP Profiles you cannot have an exit point that is bridged with Ethernet
You can have a:
- Captive Portal
- NAT + DHCP
- OpenVPN Bridge