WLAN configurator does not warn about hostapd failure

[Samsonov]

webGUI for wireless interface configuration is dangerously ignorant on syntax errors in particular and hostapd's failures in general.

For example, while recently moving from PSK to EAP, I had to fill-in the 802.1X Authentication Server IP Address field. As I prefer to use DNS names as much as possible instead of literal numeric addresses, I just typed in “localhost”, — when a numeric IP address is absolutely required, webGUI always warns about it after you press the Save button. But not this time.

As a result, hostapd disliked the configuration and refused to start. And webGUI didn't warn about that, too! The network became completely unprotected — anyone could connect without any authenticaion and gain access to LAN, WAN or whatever allowed by firewall. And it was not before some hours of digging why even mixed PSK/EAP mode won't work anymore, that I launched hostapd from CLI and saw it was complaining about syntax error in auth_server_addr directive.

IMHO, this is an unacceptable behavior. pfSense should:

• apply strict value checking for all parameters of all integrated components — not just the majority of them, which puts the user into false sense of protection against any syntax error;
• warn if hostapd refused the new configuration, and provide verbose information on that;
• have an option to monitor hostapd state and shut the WLAN interface down if that process somehow stopped.

Because with wireless networking there is no such thing as “too much security”!

[cmb]

make a list of exactly which parts are missing input validation and open a bug ticket at redmine.pfsense.org.

[Samsonov]

@cmb:

Make a list of exactly which parts are missing input validation and open a bug ticket.

This would require studying of sources of both pfSense/webGUI and hostapd. ;D

But my point is not just about syntax checking, rather than about a major security flaw. What if hostapd crashes while running because of a bug or another issue? What if such issue can be deliberately exploited by an unauthenticated wireless user to crash hostapd? The network would be left widely open to anyone, and you won't know of it until some friendly person receives a warning about connecting to unprotected WLAN and informs you.