The patch checks the existence of the needed files for the WPS support and if they are present, shows the option to toggle WPS pushbutton settings.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
Besides several AP networks, I have configured two STA networks on my
openwrt box - both on the same radio and thus on the same channel.
This was done via LuCI.
However after both STA networks were set up, I am unable to edit the
channel on neither network. When editing the one STA network, LuCI
tells me that the channel is locked by the other STA network. Same for
the other STA network.
Looks like a bug to me, so I made a patch.
Signed-off-by: Stephan Günther <steph.guenther@googlemail.com>
While working with 802.11ac (ath10k) I've noticed the web interface
configuration missing basic support for 11ac devices - unable to set VHT
(htmode) and 11ac (hwmode).
This patch adds initial support for luci admin-full page and 802.11ac
MAC80211 devices.
v2:
* replace obsolete 11nac mode with 11a + vhtmode (jow in ticket: #17323)
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
[jow: fix typo in get_i18n()]
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
Drop 11b support since its not properly supported by mac80211 anyway.
Rename 'hwmode' option to 'Band' and remove dependencies from 'htmode' field.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
OpenWrt contains a patch for hostapd which allows to override the channel-bandwidth decission
to always use 40MHz regardless of overlapping networks.
Though it does not conform with IEEE 802.11n-2009, this became the de-facto standard behaviour
of most off-the-shelf wifi routers.
Adding this option to LuCI makes it more accessible to users, which probably not everybody will
agree with to be a good idea. However, I didn't yet come across a single commercial product which
actually complies with 802.11n-2009 in that regard.
Signed-off-by: Daniel Golle <dgolle@allnet.de>
Some mac80211 drivers (rt2x00) probably won't support limiting TX-power to a
user-defined value in the near future under certain conditions, so it makes
sense to not expose that option in order not to confuse the user.
See http://patchwork.openwrt.org/patch/2187/
to understand the situation.
Signed-off-by: Daniel Golle <dgolle@allnet.de>
