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?
[...]
> 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.
[...]
> > - 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?
At the end I would suggest following approach:
* Introduce wireless.@wifi-device[*].vht_capab with a similar function as
list ht_capab
* 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
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
