Implement WifiAccessPointSetPhyType

[corbin-phipps]

Type

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

Side Effects

• Breaking change
• Non-functional change

Goals

This PR adds a new netremote API, WifiAccessPointSetPhyType, to allow clients to update the PHY type in the configuration of an AP.

Technical Details

• Added WifiAccessPointSetPhyType to NetRemoteService.proto and related types to NetRemoteWifi.proto.
• Implemented API in NetRemoteService.*.
• Added SetProtocol function to IAccessPointController interface and in its implementations (e.g. AccessPointControllerLinux.
• Added unit test.

Test Results

Unit tests pass.

Reviewer Focus

• SetProtocol sets the hw_mode hostapd property, as well as wmm_enabled and ieee80211* properties where applicable. Are others needed, such as ht_capab for ieee80211n?

• In IeeeProtocolToHostapdHwMode, the conversion from ieee80211n to hostapd hw_mode can be either a or g depending on the band, currently it's set to a. How should we handle this? Is there a way to check the bands that are currently set in hostapd somewhere and choose the best option, or should we always set this to a and update it later if a client wants to set a specific frequency band?

Future Work

None.

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]

I re-targeted this to user/corbinphipps/add-update-config-apis so it's easier to see the changes compared to there since it seems this is a child branch of that.

[abeltrano]

I re-targeted this to user/corbinphipps/add-update-config-apis so it's easier to see the changes compared to there since it seems this is a child branch of that.

Nevermind, I now re-targeted it such that it can be applied directly to develop without the changes in user/corbinphipps/add-update-config-apis. Limiting the scope should make it easier to review and test. Overall, it probably makes sense to complete this PR first.

[abeltrano]

• SetProtocol sets the hw_mode hostapd property, as well as wmm_enabled and ieee80211* properties where applicable. Are others needed, such as ht_capab for ieee80211n?

We'll need to figure this out eventually, but we can defer that and do it later on an as-needed, case-by-case basis. I'll create some issues to track that work. The only thing to verify now is whether or not hostapd will refuse to apply the hw_mode setting if the associated settings like ht_capab, vht_capab, are not specified. As long as it doesn't,

• AccessPointControllerTest::SetProtocol currently just returns true. Is this okay to leave unimplemented since this is for a mocked AP?

This one is handled now right, so we can remove this part from the PR description?

• In IeeeProtocolToHostapdHwMode, the conversion from ieee80211n to hostapd hw_mode can be either a or g depending on the band, currently it's set to a. How should we handle this? Is there a way to check the bands that are currently set in hostapd somewhere and choose the best option, or should we always set this to a and update it later if a client wants to set a specific frequency band?

This one is difficult because of the hostapd config file implementation. I think what you've done here is good for now, and we can plan to sort out the nuisances nuances later.

[abeltrano]

Ship it!