search

prplfoundation / prplMesh

This repository moved to https://gitlab.com/prpl-foundation/prplmesh/prplMesh
Other
65 stars 32 forks source link

[BUG] autoconfig: teardown / update VAPs in non-easymesh mode #797

Closed tomereli closed 4 years ago

tomereli commented 4 years ago

Currently, the son slave is updating VAP credentials regardless of the operating mode. This means that prplMesh is always tearing down all radios, which is fine in EasyMesh mode BUT not in a product.

BTW - I suggest renaming the "proprietary-mesh" mode to "legacy" or something like that. We can decide whatever we want since we don't use anything other than the Multi-AP-Controller-And-Agent mode.

Steps to reproduce

Simply get to operational in UGW/RDKB. Use hostapd_cli to see that all VAPs are in start_disabled mode, or simply read /var/run/hostapd-phy0.conf and see that start_disabled=1 for all VAPs.

arnout commented 4 years ago

Is this really only on UGW/RDKB? I expect that it's also on prplWrt/OpenWrt when you pre-configure a VAP. The problem is that we don't have a way to indicate which VAPs are the EasyMesh VAPs and which are the manual VAPs.

How was this done in the past in beerocks?

tomereli commented 4 years ago

Is this really only on UGW/RDKB? I expect that it's also on prplWrt/OpenWrt when you pre-configure a VAP. The problem is that we don't have a way to indicate which VAPs are the EasyMesh VAPs and which are the manual VAPs.

It is not only in UGW/RDKB, but these are the only real products we have, so are affected by this "bug". For now I think the simplest solution is to simply not touch the VAPs at all in non-EasyMesh mode, and do whatever we want when we are in EasyMesh mode since it is expected that prplMesh will "own" the VAPs configuration in this case. Later, we can for example add "excluded" VAPs and add them to the platform DB to mark VAPs as manual - but we should really not decide this now but rather discuss it as part of https://github.com/prplfoundation/prplMesh/milestone/12.

How was this done in the past in beerocks?

In the past, we simply did not have this issue - when beerocks was enabled it unified the credentials to the "beerocks credentials" on boot. Since then we moved to passive mode, in which beerocks does not touch the VAPs at all unless requested to.

arnout commented 4 years ago

Later, we can for example add "excluded" VAPs and add them to the platform DB to mark VAPs as manual

I agree with the "Later" part for sure.

About the approach, I'd revert it, i.e. have a list of easymesh VAPs. All the other ones are manual.

Make sure when fixing this to add a TODO that says it needs to be fixed later.

tomereli commented 4 years ago

So bottom line: