On Wed, Feb 03, 2016 at 12:56:15PM +0000, Ed W wrote: > Is it normal/expected that hostapd will exit with an error if I have > a config file requesting 802.11n, when the card in question is known > not to support "n"? Yes, that is expected behavior. > Is there not an argument that hostapd should > ignore and prefer to continue rather than exit? I guess one could make such an argument, but I'm not sure I'd be willing to support that approach as a generic solution taken into account how complex it can become to figure out what exactly to ignore if some configured capability is missing. That may look trivial for HT, but it is far from that for various HT/VHT capabilities and configured TX rates. It looks clearer to reject the configuration if there is an item that cannot be met. > For a generic solution it looks like I need to parse details of the > card in-use and rewrite the conf file appropriately? For some of the parameters, that's likely the case. For cases where a default behavior to select something based on capabilities is sufficient, that may work. As an example, wpa_supplicant configures supported HT/VHT parameters automatically based on driver capabilities. In theory, hostapd could be made to provide an option for such configuration as well, but this sounds like a less likely use case for dedicated AP devices which is where it is more likely to use hostapd to control operations than wpa_supplicant AP mode.. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
