cc @Phreedom @NinjaTrappeur @mweinelt

Secure default (no TKIP). It's possible that setting wpa=2 disables TKIP anyway, but on my machine I could not get 802.11n to work without setting rsn_pairwise=CCMP.

WFM. This is also compatible with (mixed and pure) WPA3-PSK setups.

I don't see any reason not to enable PHY n/ac by default, as hostapd will still provide backwards-compatible service (I actually tested this with an old 802.11g adapter).

On the condition that this is a backwards compatible change, which is apparently what you tested already.

I would really recommend adding a settings option here in addition to what you have to avoid hard coding options. #89662 is a recent example of what I'm talking about. See RFC 42 for more details.

To clarify, I tested that with n/ac enabled, a g-only client was able to access the network as one would expect. I realise now that there's also the question of whether hostapd will tolerate these settings if the AP hardware doesn't support them. I haven't (yet) tested this.

@aanderse well, in this case hostapd will accept options multiple times and take the latest value. But yes, that looks nicer. Can you point me to a canonical example of how to deprecate extraConfig?

If we find there is backwards-incompatibility:
If we're going to change the option structure, we should probably also consider the question of whether we should just provide a better interface, e.g. a phy option [a, b, g, n, ac] and set hw_mode depending on channel. That way we do not require the user to understand hostapd.conf.

If we find there is not:
We might as well remove the hwMode option and leave it to settings.

I realise now that there's also the question of whether hostapd will tolerate these settings if the AP hardware doesn't support them. I haven't (yet) tested this.

Yep, that is the corner case I'm most worried about here. I currently imagine it checks for the capability and dies. I'd be happy to be proven wrong though.

If we're going to change the option structure, we should probably also consider the question of whether we should just provide a better interface, e.g. a phy option [a, b, g, n, ac] and set hw_mode depending on channel. That way we do not require the user to understand hostapd.conf.

Indeed, thats an important undertaking for getting real hostapd usage under way. It was already started here: #49171

@gloaming if you feel confident that you write a settings option that covers every possibility in hostapd.conf then you can simply remove the extraConfig option with mkRemovedOptionModule. If you aren't confident that your settings can cover every edge case (yet) then taking the approach of keeping extraConfig around for a release, marking it as deprecated, will allow using to report any configuration they can't produce with settings but could with extraConfig.

See #73872 for a nice example of deprecating. At this point @filalex77 might consider making a simple PR removing the services.hardware.bluetooth.extraConfig as their original change was over a release ago and I haven't heard any reported issues over it.

To directly answer your question, though, the above mentioned RFC is currently the main discussion point around introducing settings options and will eventually introduce official process/documentation in the NixOS manual.

I can test this on an older device that has no 802.11ac.

EDIT: Never mind, the driver doesn't support AP mode at all.

@aanderse @gloaming To consider if you want to replace extraConfig with settings, fields such as ssid or bss can appear multiple times in hostapd.conf: example.

In this case, merging is undesirable, so it could be quite complicated to transition.

@lbonn in that case I'll call in our RFC42 expert @infinisil to take a look at the format and see if he has any advice. Maybe I steered you in the wrong direction... 😟

^{what an awful format…} this can still be structured, e.g. by defining a services.hostapd.bss option, which then contains structured definitions of the networks it creates and is rendered into the "flat file" config.

I marked this as stale due to inactivity. → More info

Given how stale #49171 is, I think this should be merged anyway to make the default configuration for hostapd on NixOS not so unusably bad. I agree that a change based on structured configuration (something like #49171) would be best, but it should not be a requirement to improve the existing non-structured configuration. (There are already many other services which have non-structured configuration and we don't block config improvements for them)

I agree with both @lheckemann on how it should be implemented as settings, and with @catern that we shouldn't block this PR for a better settings.

Please don't merge merge commits in the future.