Allow routing on top of AP-client links, rewrite of #551, fix #415

[ilario]

This is a rewrite of #551.
Here I created a new apbackbone mode and proto instead of modifying the currently existing ap and apname.
This way I can avoid removing tableMelt function in wireless.lua (which maybe would be a good idea anyway, to be discussed).
The only difference between apname and apbackbone is that in the latter the network option is not hard-coded to lan.
A proto for apbackbone has been created so that the base interface, needed for hosting the vlan interface with the routing protocols, can be created.
I documented everything in lime-example and I removed the documentation for the BMX6 case added in #426 as BMX6 will not be selected by default for the next release.

Additionally, I cleaned some other proto files removing an unused .configured variable and cleaned the lime-example file. I can split this to a separate PR if needed.

Testing of this PR is being done, I'll update here with the results.

[gmarcos87]

#415

[ilario]

Please don't merge yet, I am testing :)

[ilario]

Ok, I tested the link between various routers models and it works (in most of the cases it associates and the routing protocols see each other):

TP-Link WDR3600 (Atheros wifi) tested as AP, works (ap+apname+apbb+ieee80211s)
YouHua WR1200JS (MediaTek wifi) tested as AP, works (ap+apname+apbb+ieee80211s)
Comtrend AR-5387un (Broadcom wifi) tested as client, works (only client)
Comtrend AR-5315u (Broadcom wifi) tested as client, works (only client)
Huawei HG556a-C (Ralink wifi) tested both as client, does not work, and as AP, does not work (does not associate, driver problem?)
Observa VH4032N (Broadcom wifi) tested both as client, does not work, and as AP, does not work (does not associate, driver problem?)

I think the PR is ready for merging :)

[ilario]

I took the liberty to include more documentation fixes in this branch, let me know if I should make separate PRs for those.
Anyway it is ready to be merged.

[gmarcos87]

I approve as it is.
Nevertheless I would like to know a case of specific use, it would be good to document that case. Otherwise we could generate confusion in people at the time of choosing what type of connections to use.

[ilario]

I would like to know a case of specific use, it would be good to document that case. Otherwise we could generate confusion in people at the time of choosing what type of connections to use.

Ok, I merge now but I totally agree that documentation is needed.
Up to now I included a little in lime-example file.
Where should I include more? In the website?

Here you are an example of reason for which a community could want to use AP-sta instead of mesh:
a community which relies mainly on long distance point-to-point or point-to-multipoint connections, could prefer a more traditional AP-sta configuration over the mesh one. Reasons could be: better performances because of better drivers (I did not test, but I expect implementation of AP and client to be more mature as it gets used by far more people) and more choice in hardware (I don't know if this applies also on latest hardware, but for the not-so-new wireless routers the IEEE802.11s support is not assured while the AP and the client support is certain).
Other communities could prefer the default mesh approach as is more convenient for multipoint-to-multipoint connections employing with just sectorial or onmidirectional antennas covering short distances.
It is possible to use both AP-sta and mesh in the same network or even on the same radio.