Add APIs to update AP configuration

[corbin-phipps]

Type

• Bug fix
• Feature addition
• Feature update
• Documentation
• Build Infrastructure

Side Effects

• Breaking change
• Non-functional change

Goals

This PR adds three new APIs for updating the configuration of an AP after the AP is enabled: WifiAccessPointSetPhyType, WifiAccessPointSetAuthenticationConfiguration, and WifiAccessPointSetFrequencyBands. This allows netremote clients to update the PHY type, AKM suite(s), cipher suite(s), and frequency band(s) of an AP.

Technical Details

• Added WifiAccessPointSetAuthenticationConfiguration, and WifiAccessPointSetFrequencyBands to NetRemoteService.proto and related types to NetRemoteWifi.proto and WifiCore.proto.
• Added placeholder API implementations to NetRemoteService.hxx/cxx.
• Added basic unit tests for all APIs.

Test Results

Unit tests pass.

Reviewer Focus

None.

Future Work

• Need to complete the API implementations and improve associated unit tests.
• Update Dot11AccessPointConfiguration to use Dot11AccessPointAuthenticationConfiguration instead of a single Dot11AuthenticationAlgorithm and Dot11CipherSuite.

Checklist

• Build target all compiles cleanly.
• clang-format and clang-tidy deltas produced no new output.
• Newly added functions include doxygen-style comment block.

[abeltrano]

This is very good, mathcing the existing APIs we have in place to configure the AP. I left a few comments of things to explore a bit further for looking forward.

[abeltrano]

Test Results

Unit tests currently fail due to failures in the API implementations when creating an access point controller.

This is probably because the unit tests are using fake access point ids, and the server's AccessPointManager doesn't know about any APs with those ids. Probably we need to create software APs using the mac80211_hwsim driver which will be discovered by the server, like is done for the wpa-controller tests. Unfortunately, that again necessitates running the tests as root. Alternatively, we might be able to provide a fake ap discovery agent that serves up mocked APs.

[corbin-phipps]

Test Results

Unit tests currently fail due to failures in the API implementations when creating an access point controller.

This is probably because the unit tests are using fake access point ids, and the server's AccessPointManager doesn't know about any APs with those ids. Probably we need to create software APs using the mac80211_hwsim driver which will be discovered by the server, like is done for the wpa-controller tests. Unfortunately, that again necessitates running the tests as root. Alternatively, we might be able to provide a fake ap discovery agent that serves up mocked APs.

Yes, you're absolutely right. I removed some REQUIRE statements from the unit tests so that they would pass as is until we added a way to create APs for the tests. It would be nice to avoid mocked APs if possible, but that's an option if needed

[abeltrano]

Test Results

Unit tests currently fail due to failures in the API implementations when creating an access point controller.

This is probably because the unit tests are using fake access point ids, and the server's AccessPointManager doesn't know about any APs with those ids. Probably we need to create software APs using the mac80211_hwsim driver which will be discovered by the server, like is done for the wpa-controller tests. Unfortunately, that again necessitates running the tests as root. Alternatively, we might be able to provide a fake ap discovery agent that serves up mocked APs.

Yes, you're absolutely right. I removed some REQUIRE statements from the unit tests so that they would pass as is until we added a way to create APs for the tests. It would be nice to avoid mocked APs if possible, but that's an option if needed

Looking at this now, the AccessPointManager part will be easier than expected as it has AddAccessPoint and RemoveAccessPoint functions; they're private, but I don't see much harm in making them public, allowing the test to use them and add arbitrary access points. Alternatively, a thin wrapper class exposing the Add/Remove functions is another option that preserves the existing function visibility.

We can trivially extend the existing AccessPointTest, AccessPointFactoryTest, and AccessPointControllerTest with the functionality needed in the tests. For example, AccessPointTest would just save whatever values requested to be set in members. Should be straight-forward. I'll take a look at doing this later today.

[abeltrano]

Looking at this now, the AccessPointManager part will be easier than expected as it has AddAccessPoint and RemoveAccessPoint functions; they're private, but I don't see much harm in making them public, allowing the test to use them and add arbitrary access points. Alternatively, a thin wrapper class exposing the Add/Remove functions is another option that preserves the existing function visibility.

We can trivially extend the existing AccessPointTest, AccessPointFactoryTest, and AccessPointControllerTest with the functionality needed in the tests. For example, AccessPointTest would just save whatever values requested to be set in members. Should be straight-forward. I'll take a look at doing this later today.

Done in #136.

[abeltrano]

FYI, I'm still trying to parse out whether this is the best encoding of all the auth args w.r.t. to the 802.11 specification. I think it's very close, if not completely correct.

I'm giving the auth-related parts of the spec a careful read through to hopefully resolve this.