802.11s integration

[robimarko]

Work in progress for adding 802.11s mesh mode.

[robimarko]

@kostko I have made requested changes. Now the issue is that it does not work yet. Also When 802.11s is ticked then if the device has USB port specified it automatically creates wireless radio from USB port and no 802.11s wireless interface

[kostko]

if the device has USB port specified it automatically creates wireless radio from USB port

This has nothing to do with this PR and is caused by the new automatic configuration of multiple radios. I will fix it so it will never automatically configure USB radios.

[kostko]

I've pushed some USB and other fixes to development.

[robimarko]

Ok,I will then rebase this on development

[robimarko]

Now mesh interface is configured.

[mitar]

This really looks good. I think it is important to be able to experiment with other things. But yes, let's add it as an alternative to ad-hoc and not replace it.

[mitar]

BTW, can both ad-hoc and 802.11s be enabled at the same time?

[kostko]

BTW, can both ad-hoc and 802.11s be enabled at the same time?

I am not sure if we want that.

[robimarko]

Technically yes, but that would cripple performance for sure.

[mitar]

I am not sure if we want that.

Does it not work? Or you think it will just be useless use of spectrum? I see it that if there are no neighbors, then it does not really consume anything. But if there are ad-hoc neighbors, then it would still work. Maybe we should just make sure that if two nodes see each other on both ad-hoc or 802.11s, user can choose which one to prefer.

[mitar]

Technically yes, but that would cripple performance for sure.

Why exactly? Please make better arguments. If interface is up and is not used, I do not see why it would impact performance a lot? Maybe just for beacons sent? That should not be too much.

[robimarko]

Well even if the interface is not being used it is still up will impact performance. But in order to determine how much field test should be conducted.

[valentt]

@mitar I understand your point for having both (if possible) mesh interfaces because that would keep compatibility and make migration smoother. We had similar migration with routing protocols and kept both in parallel for some time. So having both adhoc modes make sense from that point, to prevent people from breaking their network by updating one node that then others can't connect .

But because of that I would suggest to keep adhoc as default mesh protocol and have option to switch to 802.11s if somebody wants to test and deploy 802.11s mesh, but not to have both protocols at the same time. It just complicates things too much and will confuse people as well (two mesh ssids).

[valentt]

And then we can test if needed how it works if we have two mesh interfaces.

[mitar]

I think this is why I think current proposal is to have one choice to select for mesh: no mesh, ad-hoc mesh, 802.11s mesh, if we want to support only one.

But the argument for having both is not for legacy purposes. I will discuss this more in chat. But in short, ad-hoc mesh serves a different purpose than 802.11s mesh. 802.11s mesh is a L2 mesh, it makes maybe easier to cover a local area you want to cover with APs, but you do not have cables to every location. ad-hoc mesh is meant to create a country wide network. A network which works (but not necessary efficiently) when the normal Internet fails. 802.11s does not scale to more than 32 nodes, it not even in the standard to support bigger networks, to what I remember.

So the proper approach here would be probably to have both of those enabled, so that if Internet uplink fails, connectivity is established by ad-hoc mesh. It could also be automatic process: if Internet uplink fails (which means also over 802.11s there is no Internet), turn off 802.11s and switch to ad-hoc. The reason is because maybe there people will start bringing more ad-hoc devices to heal bad spots in the network and with 802.11s the mesh would melt.

Anyway, I think that for experimentation it is good to support also 802.11s. But we should not remove ad-hoc mesh just because we are experimenting with 802.11s. One important part of wlan slovenija network is that under the table we are building an autonomous independent network. That you can just throw devices out and they just connect. Badly, not efficiently, but connect.

[kostko]

But we should not remove ad-hoc mesh just because we are experimenting with 802.11s.

Where did you see that we are removing ad-hoc? This PR just adds 802.11s as an optional enable.

[mitar]

Where did you see that we are removing ad-hoc? This PR just adds 802.11s as an optional enable.

I am talking about removing ad-hoc from nodes, not from support. I am talking about the way Valent is proposing to configure their nodes.

Anyway, let's experiment and let's see.

[robimarko]

Well, ad-hoc would be removed only if the user who is configuring node wants to do so. He can choose to have ad-hoc or 802.11s as Mesh solution or chose to not have Mesh at all.

I think that that is logical way

[robimarko]

I generated a new image and flashed it to see if mesh_id will be configured correctly. Unfortunately, it is completely empty in configuration. I can't seem to find the issue.

config wifi-iface option device 'radio0' option encryption 'none' option ssid 'mesh.otvorenamreza.org' option mode 'mesh' option mesh_id '' option ifname 'mesh11s0' option network 'mesh11s0'

[kostko]

Unfortunately, it is completely empty in configuration.

It is set, but to an empty string. So this means that wif.mesh_id = vif.bssid is executed correctly, so it must be that vif.bssid is empty. Can you check in your node's configuration if the 802.11s interface has a BSSID set?

[robimarko]

I just checked and BSSID is empty. Which is weird since ad-hoc mesh has BSSID field populated and that same BSSID should be used as set in code

[robimarko]

I have solved empty mesh_id. Field name in wireless configuration was wrong.

Now everything is configured properly.

[kostko]

That's great! Can you unify the part of the code that configures the mesh interface as previously discussed in the comments?

[robimarko]

Sure, after it is tested to work. It should be tested today and if it works I will unify it and remove docker-compose.yml and settings.py changes and then squash this to be mergeable

[kostko]

Sounds good! :+1:

[robimarko]

Just tested and it works. I did not test speeds but we will test those out too.

I will unify the code today and then squash to be ready for merging

[robimarko]

I have unified the code. I will squash it and have it ready for merging.

[robimarko]

Code is squashed and ready.