rbattala
commented
9 years ago Additional inputs into this issue...this is a issue is because of the way we are handling the auto channel configuration and not because of an invalid configuration in this case.
If you visit the settings page and change the band for both networks to "AUTO", upon reloading the page the following error occurs:
Server Error: KeyError: 'AUTO', [' File "/www/cgi-bin/routerapi/settings", line 67, in <module>\n get_attributes(private, "@wifi-iface[2]")\n', ' File "/www/cgi-bin/routerapi/settings", line 53, in get_attributes\n interface["channel"] = channels[channel_short_hand]\n']SSH is required to change the channel back to "1". Note that setting 5GHz band to channel 1 is probably invalid. FYI, uci also shows that there are three wifi interfaces, the third being "openwireless-5G" which is disabled by default.
Acceptance Criteria Given that I am accessing the router through web UI settings page When I set the bands to AUTO Then sanity checking should prevent me from locking myself out with invalid settings.
Good suggestion would be to ensure that invalid settings do not lock the (casual, consumer) user out. To accomplish this each data field could be handled independently or wrapped such that an error only affects one field. Alternatively it could present them a clear error mesage and a shell that only accepts uci commands, allowing them to fix the invalid setting. Or perhaps the ui should simply roll the setting back to something valid, perhaps by rendering the page again before committing. The bottom line is that, In additon to sanity checking, there should be some anti-lockout for casual (http-only) users.