On 2014-01-31 14:46, Sven Eckelmann wrote:
> On Friday 31 January 2014 03:54:19 Felix Fietkau wrote:
>> > --- a/package/base-files/files/sbin/wifi
>> > +++ b/package/base-files/files/sbin/wifi
>> > @@ -72,7 +72,7 @@ prepare_key_wep() {
>> >
>> > wifi_fixup_hwmode() {
>> > local device="$1"
>> > local default="$2"
>> >
>> > - local hwmode hwmode_11n
>> > + local hwmode hwmode_11n hwmode_11ac
>> >
>> >
>> > config_get channel "$device" channel
>> > config_get hwmode "$device" hwmode
>> >
>> > @@ -89,6 +89,12 @@ wifi_fixup_hwmode() {
>> >
>> > esac
>> > config_set "$device" hwmode_11n "$hwmode_11n"
>> > ;;
>> >
>> > + 11ac)
>> > + hwmode_11n=a
>> > + hwmode_11ac=a
>> > + config_set "$device" hwmode_11n "$hwmode_11n"
>> > + config_set "$device" hwmode_11ac "$hwmode_11ac"
>> > + ;;
>> >
>> > *)
>> > hwmode=
>> > if [ "${channel:-0}" -gt 0 ]; then
>> >
>> > @@ -203,6 +209,7 @@ scan_wifi() {
>> >
>> > append DEVICES "$section"
>> > config_set "$section" vifs ""
>> > config_set "$section" ht_capab ""
>> >
>> > + config_set "$section" vht_capab ""
>> >
>> > ;;
>> > esac
>> >
>>
>> I think all of the above changes are unnecessary.
>
> Because of your next suggestion or is there another reason?
Because it's touching legacy code that will not be used for 802.11ac
drivers. wifi_fixup_hwmode is not called from netifd based scripts.
>> I think reusing htmode instead of introducing vhtmode would be a better
>> choice, especially since it never makes sense to configure both separately.
>
> So we would change it to just use "VHT40", "VHT80", "VHT160" and someone
> could
> later introduce options to configure the center freq0 (and maybe freq1 for
> 80+80mhz mode) manually with another option.
Yes.
>> > - option hwmode 11${mode_11n}${mode_band}
>> > + option hwmode 11${mode_11ac}${mode_11n}${mode_band}
>> >
>> > $dev_id
>> > $ht_capab
>> >
>> > +$vht_capab
>> >
>> > # REMOVE THIS LINE TO ENABLE WIFI:
>> > option disabled 1
>>
>> I think we should probably introduce a new option that avoids the
>> overload of mode and band into one single option. We can keep backwards
>> compatibility for 11n.
>
> I am not quite sure what you want to say here. You seem to want to have 11n
> and band separated, ok. Are you now suggestion that the uci should get a new
> option to say "enable ht/disable ht"? Wouldn't it make more sense to just to
> keep mode_11n as it was before and make the decision whether ieee80211ac=1
> can
> be enabled on the modified htmode wireless option?
I think in new configs, the mode should only be 11a or 11g, and
802.11n/802.11ac is enabled through the htmode option. 11na and 11ng
would only be supported for compatibility reasons.
> At the end I would suggest following approach:
>
> * Introduce wireless.@wifi-device[*].vht_capab with a similar function as
> list ht_capab
I actually want to get rid of ht_capab as well, because it's annoying to
deal with wrt. UI, config changes, etc.
It also makes it more annoying to port configs between devices
(capabilities might be different).
I would prefer enabling all capabilities by default (aside from the mode
related ones), and allowing the user to selectively disable them via
individual bool options.
Example: option rx_stbc_123 0
> * Allow "VHT40", "VHT80" (default when AC is found), "VHT160" in htmode
> * enable ieee80211ac=1 when one of the new htmode's are found
>
> This would mean following user visible changes to the patch:
>
> * no wireless.@wifi-device[*].vhtmode
> * no wireless.@wifi-device[*].hwmode='11ac' and instead 11na would be the
> default for AC devices
Right, in addition to what I mentioned above.
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
