New ath10k-ct driver available
Hello, On June 30, I pulled in an upstream commit that changed dma_burst. This broke at least some systems (see: https://github.com/greearb/ath10k-ct/issues/153) I am not sure how to detect which value to use in the driver, it seems platform dependent from what little I know of the problem. So, I'm adding a fwcfg option to override the dma_burst option. Here is the new ath10k-ct commit ID. If someone can pull this in a do a bit of testing I'd appreciate it. Bug 153 has some details on how to configure the override if you want to try that. commit 76280f692492fb9ddd506bddffab76efd2a57312 (HEAD -> master, origin/master) Author: Ben Greear Date: Wed Sep 16 14:31:42 2020 -0700 ath10k-ct: Allow override of dma_burst setting using fwcfg. Previously tested and shown to work on 5.4 kernel, now applied to 4.16 through 5.8 kernels. Signed-off-by: Ben Greear Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
New ath10k-ct driver available
Hello, On June 30, I pulled in an upstream commit that changed dma_burst. This broke at least some systems (see: https://github.com/greearb/ath10k-ct/issues/153) I am not sure how to detect which value to use in the driver, it seems platform dependent from what little I know of the problem. So, I'm adding a fwcfg option to override the dma_burst option. Here is the new ath10k-ct commit ID. If someone can pull this in a do a bit of testing I'd appreciate it. Bug 153 has some details on how to configure the override if you want to try that. commit 76280f692492fb9ddd506bddffab76efd2a57312 (HEAD -> master, origin/master) Author: Ben Greear Date: Wed Sep 16 14:31:42 2020 -0700 ath10k-ct: Allow override of dma_burst setting using fwcfg. Previously tested and shown to work on 5.4 kernel, now applied to 4.16 through 5.8 kernels. Signed-off-by: Ben Greear Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] hostapd: enable background scanning in wpa_supplicant_full
Hello!
Could someone please take care of this little snippet?
Kind regards,
André
Am 09.09.20 um 22:00 schrieb André Valentin:
> Activation of autoscanning enables a a wifi client to select the best
> accesspoint based on rssi.
>
> This feature is useful in case you have multiple access points in your range
> and you do not want to stick the client on the first one it connected to.
> Especially when used with 802.11r this allows seamless transition to the
> optimal accesspoints.
>
> Setting the config value bgscan to -65 will tell wpa_supplicant to try to
> connect to an access points with better rssi.
>
> Example config:
> config wifi-iface 'default_radio1'
> option device 'radio1'
> option mode 'sta'
> option ssid 'openwrt'
> option encryption 'psk2'
> option key 'mykey'
> option network 'wlan'
> option roam_rssi_threshold '-65'
>
> The ipk sizes for mipsel_24kc change like this:
> old:
> wpad-openssl_2020-06-08-5a8b3662-4_mipsel_24kc.ipk 550133
>
> new:
> wpad-openssl_2020-06-08-5a8b3662-5_mipsel_24kc.ipk 551961
>
> Signed-off-by: André Valentin
> ---
> package/network/services/hostapd/files/hostapd.sh| 7
> +++
> package/network/services/hostapd/files/wpa_supplicant-full.config | 6
> +++---
> package/network/services/hostapd/Makefile| 1 +-
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/package/network/services/hostapd/files/hostapd.sh
> b/package/network/services/hostapd/files/hostapd.sh
> index 88113cd7ce..85299234c2 100644
> --- a/package/network/services/hostapd/files/hostapd.sh
> +++ b/package/network/services/hostapd/files/hostapd.sh
> @@ -272,6 +272,8 @@ hostapd_common_add_bss_config() {
> config_add_array operator_icon
> config_add_array hs20_conn_capab
> config_add_string osu_ssid hs20_wan_metrics hs20_operating_class
> hs20_t_c_filename hs20_t_c_timestamp
> +
> + config_add_string roam_rssi_threshold
> }
>
> hostapd_set_vlan_file() {
> @@ -1178,6 +1180,11 @@ wpa_supplicant_add_network() {
> [ -n "$bssid_blacklist" ] && append network_data
> "bssid_blacklist=$bssid_blacklist" "$N$T"
> [ -n "$bssid_whitelist" ] && append network_data
> "bssid_whitelist=$bssid_whitelist" "$N$T"
>
> + [ -n "$roam_rssi_threshold" ] && {
> + json_get_vars roam_rssi_threshold
> + append network_data
> "bgscan=\"simple:120:${roam_rssi_threshold}:600\"" "$N$T"
> + }
> +
> [ -n "$basic_rate" ] && {
> local br rate_list=
> for br in $basic_rate; do
> diff --git
> a/package/network/services/hostapd/files/wpa_supplicant-full.config
> b/package/network/services/hostapd/files/wpa_supplicant-full.config
> index 982f4d5534..d39ee74a8d 100644
> --- a/package/network/services/hostapd/files/wpa_supplicant-full.config
> +++ b/package/network/services/hostapd/files/wpa_supplicant-full.config
> @@ -527,9 +527,9 @@ CONFIG_WNM=y
> #
> # Enabling directly a module will enable autoscan support.
> # For exponential module:
> -#CONFIG_AUTOSCAN_EXPONENTIAL=y
> +CONFIG_AUTOSCAN_EXPONENTIAL=y
> # For periodic module:
> -#CONFIG_AUTOSCAN_PERIODIC=y
> +CONFIG_AUTOSCAN_PERIODIC=y
>
> # Password (and passphrase, etc.) backend for external storage
> # These optional mechanisms can be used to add support for storing passwords
> @@ -600,7 +600,7 @@ CONFIG_IBSS_RSN=y
> # operations for roaming within an ESS (same SSID). See the bgscan parameter
> in
> # the wpa_supplicant.conf file for more details.
> # Periodic background scans based on signal strength
> -#CONFIG_BGSCAN_SIMPLE=y
> +CONFIG_BGSCAN_SIMPLE=y
> # Learn channels used by the network and try to avoid bgscans on other
> # channels (experimental)
> #CONFIG_BGSCAN_LEARN=y
> diff --git a/package/network/services/hostapd/Makefile
> b/package/network/services/hostapd/Makefile
> index 8f94dce782..8c264854d7 100644
> --- a/package/network/services/hostapd/Makefile
> +++ b/package/network/services/hostapd/Makefile
> @@ -7,7 +7,7 @@
> include $(TOPDIR)/rules.mk
>
> PKG_NAME:=hostapd
> -PKG_RELEASE:=5
> +PKG_RELEASE:=6
>
> PKG_SOURCE_URL:=http://w1.fi/hostap.git
> PKG_SOURCE_PROTO:=git
>
--
Mit freundlichen Grüßen
André Valentin
Systemadministration - Projektkoordination
--
MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net
Re: ath79: move 8/32 boards to tiny subtarget
Hi, On 9/16/20 11:40 AM, Adrian Schmutzler wrote: >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Sven Roederer >> Sent: Mittwoch, 16. September 2020 09:17 >> To: openwrt-devel@lists.openwrt.org >> Subject: ath79: move 8/32 boards to tiny subtarget >> >> Hi, >> >> not sure if this has been discussed before. >> I recently worked with some 8/32 boards (Ubiquiti Nanostation M (XM), >> TPLink >> WR842 v2) for our Freifunk-project and realized that the low RAM situation >> requires quite different handling than the full boards (8+/64+). >> >> I wonder if there is a reason to not move the boards, which are affected by >> the 4/32MB warning also, to the ath79-tiny target? > > I wonder whether the tiny subtarget will actually make much difference for > RAM issues? In it's current state, it will most likely increase low-memory issues as the squashfs blocksize is 1024kB compared to the regular 256kB. Not that ath79-tiny has no target-flag for small memory set. Best wishes David > > Best > > Adrian > >> >> Sven >> >> >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: ath79: move 8/32 boards to tiny subtarget
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Sven Roederer > Sent: Mittwoch, 16. September 2020 09:17 > To: openwrt-devel@lists.openwrt.org > Subject: ath79: move 8/32 boards to tiny subtarget > > Hi, > > not sure if this has been discussed before. > I recently worked with some 8/32 boards (Ubiquiti Nanostation M (XM), > TPLink > WR842 v2) for our Freifunk-project and realized that the low RAM situation > requires quite different handling than the full boards (8+/64+). > > I wonder if there is a reason to not move the boards, which are affected by > the 4/32MB warning also, to the ath79-tiny target? I wonder whether the tiny subtarget will actually make much difference for RAM issues? Best Adrian > > Sven > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: add support for Ubiquiti UniFi AP Pro
Hi Rafal,
On 9/16/20 7:03 AM, Rafał Miłecki wrote:
> On Mon, 14 Sep 2020 at 14:22, David Bauer wrote:
>> + firmware-partition@5 {
>> + label = "firmware";
>> + reg = <0x5 0xf6>;
>> + };
>
> Please specify "compatible" so the kernel doesn't have to guess its format.
There's not MTD splitter for JFFS2 kernel partitions as far as I'm concerned.
kernel and rootfs partitions are also defined in the DTS, so no splitter is
needed.
The sole purpose of th firmware partition is to allow the default sysupgrade
method.
Best wishes
David
>
> https://openwrt.org/docs/guide-developer/defining-firmware-partitions#defining_software_partitions_in_all_dts_targets
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ath79: move 8/32 boards to tiny subtarget
Hi, not sure if this has been discussed before. I recently worked with some 8/32 boards (Ubiquiti Nanostation M (XM), TPLink WR842 v2) for our Freifunk-project and realized that the low RAM situation requires quite different handling than the full boards (8+/64+). I wonder if there is a reason to not move the boards, which are affected by the 4/32MB warning also, to the ath79-tiny target? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
