[PATCH] firewall: config: drop input traffic by default
From: Baptiste Jonglez This is necessary with firewall4 to avoid a hard-to-diagnose race condition during boot, causing DNAT rules not to be taken into account correctly. The root cause is that, during boot, the ruleset is mostly empty, and interface-related rules (including DNAT rules) are added incrementally. If a packet hits the input chain before the DNAT rules are setup, it can create buggy conntrack entries that will persist indefinitely. This new default should be safe because firewall4 explicitly accepts authorized traffic and rejects the rest. Thus, in normal operations, the default policy is not used. Fixes: #10749 Ref: https://github.com/openwrt/openwrt/issues/10749 Signed-off-by: Baptiste Jonglez --- package/network/config/firewall/files/firewall.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/config/firewall/files/firewall.config b/package/network/config/firewall/files/firewall.config index 61cfe665e4..b90ac7af0a 100644 --- a/package/network/config/firewall/files/firewall.config +++ b/package/network/config/firewall/files/firewall.config @@ -1,6 +1,6 @@ config defaults option syn_flood1 - option inputACCEPT + option inputREJECT option output ACCEPT option forward REJECT # Uncomment this line to disable ipv6 rules -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Refactoring OpenWrt's build infra
On 16-10-22, Christian Marangi wrote: > On Sun, Oct 16, 2022 at 02:07:05PM +0200, Baptiste Jonglez wrote: > > - either buildbot can run latent workers with a different Docker image > > depending on the build > > IMHO, this would be the safest and better solution to the problem. But > this means that we will have to support 2 thing instead of having one > centrilized container. I'm not even sure Buildbot is able to do that :) But if it is, and the only change between worker images is the version of the base image (e.g. Debian), then that sounds manageable. > Would be ideal to have one centrilized dl/ dir where each runner can go > and take the file. We already support that in openwrt (to have a > different dl dir) and there isn't any problem with having different > release tar for the same package. I had tried to share dl/ across several worker containers on the same physical machine. But there are race conditions that make it not so easy to do. I fixed one issue [1] but there was another that I couldn't track down. We could use object storage, for instance from DigitalOcean [2]. It would allow all workers to read/write to the same shared storage for download files, and get (hopefully) good download performance. With that in place, we could also prune dl/ very aggressively to save disk space. Baptiste [1] https://git.openwrt.org/d4c957f24b2f76986378c6d9 [2] https://www.digitalocean.com/products/spaces signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Refactoring OpenWrt's build infra
Hi, On 05-10-22, Thibaut wrote: > Hi, > > Following an earlier conversation on IRC with Petr, I’m willing to work on > refactoring our buildbot setup as follows: > > - single master for each stage (images and packages) > - latent workers attached to either master, thus able to build > opportunistically from either master or release branches as needed / as work > becomes available This is a good idea, but I see one main downside: we would probably have to use the same buildbot worker image for all releases. From what I remember, when the worker image was updated from Debian 9 to Debian 10, this seriously broke 19.07 builds. Maybe Petr or Jow will remember the details better. I see two ways to address this: - either buildbot can run latent workers with a different Docker image depending on the build - otherwise, we have to think early about the update strategy. Maybe use the shared buildbot instance for master branch + most recent release only, and move older releases back to a dedicated buildbot instance? > The main upside is that all buildslaves could be pooled, improving overall > throughput and reducing wasted « idle time », thus lowering build times and > operating costs. > > Petr also suggested that extra release workers could be spawned at will > (through e.g. cloud VMs) when a new release is to be tagged; tagged release > could be scheduled only to release workers: this would still work within this > « single master » build scheme. > > NB: I’m aware of the potential performance penalty of having buildslaves > randomly switching between branches, so I would try to come up with a > reasonably smart solution to this issue if it doesn’t conflict with the main > goals. One thing to look for is disk space usage. Full disks is a common cause of build failures. If a single worker goes through builds for different branches, I would expect disk usage to be higher (e.g. more different versions of software in dl/). Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: Don't enable ULA IPv6 addresses by default in new config
On 08-09-22, Michael Richardson wrote: > > >>>>> Baptiste Jonglez writes: > > - there have been various bug reports [1, 2, 3] in 19.07 and 21.02 > > where ULA addresses basically break global IPv6 connectivity. These > > bugs have not been solved in several years, indicating a probable lack > > of interest for ULA from the OpenWrt developer community. > > Seems to be > > a) a bug in MacOS. That's debatable, Linux should probably always use a link-local address as source address for NDP (but I haven't checked whether it's legal or not to use ULA here). > b) a bug reported in french, where my reading is that an he.net tunnel is >involved. I don't see anything about ULAs here. > c) a bug where a client didn't get a GUA, and not surprisingly, couldn't >ping the internet. >"so I suppose IP assignment is fine." >But they weren't because the router didn't assign a v6 prefix to the LAN. Both are actually the same issue. I spent some time with Thibault troubleshooting this issue on his setup, and it does look like a real bug when using both ULAs and global addresses. But since I don't have any use for ULAs, I cannot dedicate time to debug it further and try to fix it. Same for Thibault, he didn't actually have any use for ULA so he ended up disabling them. I suspect this is a rather common way of sidestepping the issue. > Having ULAs available is critical to efforts to do HTTPS to the router. > Please do not change this default. How do ULAs relate to HTTPS? Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: Don't enable ULA IPv6 addresses by default in new config
Hi, On 08-09-22, Michael Richardson wrote: > > >>>>> Baptiste Jonglez writes: > > ULA IPv6 prefixes (Unique Local Addresses, RFC 4193) are not routable > > on the Internet. As such, they have very limited use, and enabling > > them by default causes more problems than it solves: > > > - if an OpenWrt device already has external IPv6 connectivity with > > globally routable addresses, then ULA addresses are not useful. > > That's just not the case. > ULAs are intended to be the IPv6 version of RFC1918, useable for local > communications. > > Please go read RFC7084. > ULAs are required, and OpenWRT has been a leader here. Thanks for the pointer, I had forgotten about this one. I just read it again. ULAs should be supported, but there is no hard requirement to use them by default. Even ULA-1 is a SHOULD, not a MUST, and it's only about generating a ULA prefix. I see two main arguments for ULAs in this RFC: 1) Section 3.2.1: allowing local IPv6 communication when the home router manages several links and there is no global IPv6 connectivity. If there is a single link, then the RFC agrees that "link-local addressing can be used instead". This is a good use-case for ULAs, but I'm not sure whether the multi-link situation is really common, and if there are any applications that can take advantage of ULAs in this specific case. In other words: how can clients coordinate when they are in different links and they have no global connectivity? That does not sound easy. 2) Section 3.1: stability of local addresses, even when the global prefix delegated by the ISP might change. This may work for IPv4 (192.168.1.1 is stable and well-known), but that argument doesn't fly for IPv6: who would use "well-known" raw ULA IPv6 addresses? Stable identifiers belong in the DNS, not in the IP layer. Actually, my main concern about ULA is that they don't get enough exposure among developers and power users, resulting in the kind of bugs I mentioned going unnoticed and unfixed, which is not good for a default-on feature. As a matter of fact, I always disable ULA on my OpenWrt builds (personal taste), and I suspect several other OpenWrt developers do the same. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] base-files: Don't enable ULA IPv6 addresses by default in new config
From: Baptiste Jonglez
ULA IPv6 prefixes (Unique Local Addresses, RFC 4193) are not routable on
the Internet. As such, they have very limited use, and enabling them by
default causes more problems than it solves:
- if an OpenWrt device already has external IPv6 connectivity with
globally routable addresses, then ULA addresses are not useful.
- if an OpenWrt device has no external IPv6 connectivity, then ULA
addresses could be useful for local IPv6 communication on the LAN;
however, link-local IPv6 addresses already provide such a service
without needing any configuration or even the need for a router.
Discovery protocols based on IPv6 multicast and link-local addresses are
becoming more common (e.g. syncthing) and don't need ULA to work.
- users might be confused to see multiple unrelated IPv6 addresses on
their devices. Or they might wrongly conclude that they have IPv6
connectivity thanks to ULA addresses, while in fact ULA addresses are
not globally routable.
- there have been various bug reports [1, 2, 3] in 19.07 and 21.02 where
ULA addresses basically break global IPv6 connectivity. These bugs have
not been solved in several years, indicating a probable lack of interest
for ULA from the OpenWrt developer community.
ULA addresses are still supported, e.g. by setting
network.globals.ula_prefix='auto' in a uci-defaults script that runs
before "12_network-generate-ula", or by directly setting
network.globals.ula_prefix to a /48 prefix.
[1] https://github.com/openwrt/openwrt/issues/5082
[2]
https://forum.openwrt.org/t/router-can-use-ipv6-ok-but-clients-in-lan-cannot/57587
[3] https://lafibre.info/ipv6/saison-2-openwrt-slaac-problemes/
Signed-off-by: Baptiste Jonglez
---
package/base-files/files/bin/config_generate | 7 ---
1 file changed, 7 deletions(-)
diff --git a/package/base-files/files/bin/config_generate
b/package/base-files/files/bin/config_generate
index 596fcf41fa..f0ea4b6eb2 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -45,13 +45,6 @@ generate_static_network() {
set network.loopback.ipaddr='127.0.0.1'
set network.loopback.netmask='255.0.0.0'
EOF
- [ -e /proc/sys/net/ipv6 ] && {
- uci -q batch <<-EOF
- delete network.globals
- set network.globals='globals'
- set network.globals.ula_prefix='auto'
- EOF
- }
if json_is_a dsl object; then
json_select dsl
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07] busybox: sysntpd: option to bind server to iface
On 08-03-21, Alexey Dobrovolsky wrote:
> NTPD in busybox has option -I to bind server to IFACE.
> However, capabilities of the busybox are limited, the -I option cannot be
> repeated and only one interface can be effectively specified in it.
> This option is currently not configurable via UCI.
> The patch adds an interface option to the system config, ntp section.
> Also sort options for uci_load_validate alphabetically.
NACK, this is a new feature: we don't typically backport features at this
stage of a release.
Especially in this case, it's not a trivial feature to get right, and the
subsequent fix is too invasive to be backported in 19.07.
Baptiste
> Signed-off-by: Alexey Dobrovolsky
> (cherry picked from commit e12fcf0fe5597467f7cc21144e5f4da60500ebd2)
> ---
> package/utils/busybox/files/sysntpd | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/package/utils/busybox/files/sysntpd
> b/package/utils/busybox/files/sysntpd
> index 52866ba32a..511561a4bb 100755
> --- a/package/utils/busybox/files/sysntpd
> +++ b/package/utils/busybox/files/sysntpd
> @@ -30,7 +30,12 @@ get_dhcp_ntp_servers() {
>
> validate_ntp_section() {
> uci_load_validate system timeserver "$1" "$2" \
> - 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0'
> 'use_dhcp:bool:1' 'dhcp_interface:list(string)'
> + 'dhcp_interface:list(string)' \
> + 'enable_server:bool:0' \
> + 'enabled:bool:1' \
> + 'interface:string' \
> + 'server:list(host)' \
> + 'use_dhcp:bool:1'
> }
>
> start_ntpd_instance() {
> @@ -49,7 +54,10 @@ start_ntpd_instance() {
>
> procd_open_instance
> procd_set_param command "$PROG" -n -N
> - [ "$enable_server" = "1" ] && procd_append_param command -l
> + if [ "$enable_server" = "1" ]; then
> + procd_append_param command -l
> + [ -n "$interface" ] && procd_append_param command -I $interface
> + fi
> [ -x "$HOTPLUG_SCRIPT" ] && procd_append_param command -S
> "$HOTPLUG_SCRIPT"
> for peer in $server; do
> procd_append_param command -p $peer
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] busybox: sysntpd: add trigger to reload server
On 06-06-21, Alexey Dobrovolsky wrote:
> sysntpd server becomes unavailable if the index of the bound
> interface changes. So let's add an interface trigger to reload sysntpd.
>
> This patch also adds the ability for the sysntpd script to handle
> uci interface name from configuration.
>
> Fixes: 4da60500ebd2 ("busybox: sysntpd: option to bind server to iface")
> Signed-off-by: Alexey Dobrovolsky
Merged, thanks!
Baptiste
> ---
>
> Notes:
> Changes since v1:
> * variables are not sorted alphabetically
> since v2:
> * use config_get_bool to get enable_server
> * set default value for enable_server
> * use integer comparison for enable_server
>
> package/utils/busybox/files/sysntpd | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/package/utils/busybox/files/sysntpd
> b/package/utils/busybox/files/sysntpd
> index c4c311c242..074f14b8f8 100755
> --- a/package/utils/busybox/files/sysntpd
> +++ b/package/utils/busybox/files/sysntpd
> @@ -56,7 +56,14 @@ start_ntpd_instance() {
> procd_set_param command "$PROG" -n -N
> if [ "$enable_server" = "1" ]; then
> procd_append_param command -l
> - [ -n "$interface" ] && procd_append_param command -I $interface
> + [ -n "$interface" ] && {
> + local ifname
> +
> + network_get_device ifname "$interface" || \
> + ifname="$interface"
> + procd_append_param command -I "$ifname"
> + procd_append_param netdev "$ifname"
> + }
> fi
> [ -x "$HOTPLUG_SCRIPT" ] && procd_append_param command -S
> "$HOTPLUG_SCRIPT"
> for peer in $server; do
> @@ -79,11 +86,12 @@ start_ntpd_instance() {
> }
>
> start_service() {
> + . /lib/functions/network.sh
> validate_ntp_section ntp start_ntpd_instance
> }
>
> service_triggers() {
> - local script name use_dhcp
> + local script name use_dhcp enable_server interface
>
> script=$(readlink -f "$initscript")
> name=$(basename ${script:-$initscript})
> @@ -106,5 +114,17 @@ service_triggers() {
> fi
> }
>
> + config_get_bool enable_server ntp enable_server 0
> + config_get interface ntp interface
> +
> + [ $enable_server -eq 1 ] && [ -n "$interface" ] && {
> + local ifname
> +
> + network_get_device ifname "$interface" || \
> + ifname="$interface"
> + procd_add_interface_trigger "interface.*" "$ifname" \
> + /etc/init.d/"$name" reload
> + }
> +
> procd_add_validation validate_ntp_section
> }
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] ipq806x: backport cpufreq changes to 5.4
Hi, On 20-06-21, Shane Synan wrote: > In the time since submitting this, I've continued testing this > change on my ZyXEL NBG6817. I'm reasonably confident this fixes my > issue (11/11 successes), and if there's any further testing that > would help, let me know! Thanks for the patch and testing, I'd like to merge it in the next few days (before 21.02.0 final). I'll update the commit message. Ansuel, do you have any feedback on this backport? It seems to help things. Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uclient] uclient-fetch: allow to overwrite Content-Type header for POST
Hi, On 03-06-21, Andre Heider wrote: > This is required by some APIs, e.g. matrix's media upload [0]. > > [0] > https://matrix.org/docs/spec/client_server/latest#post-matrix-media-r0-upload > @@ -484,6 +485,7 @@ static int usage(const char *progname) > " --user-agent | -U Set HTTP user agent\n" > " --post-data=STRING use the POST method; > send STRING as the data\n" > " --post-file=FILEuse the POST method; > send FILE as the data\n" > + " --content-type=STRING use STRING as > Content-Type for the POST method\n" > " --spider | -s Spider mode - only > check file existence\n" > " --timeout=N | -T N Set connect/request > timeout to N seconds\n" > " --proxy=on | -Y on Enable interpretation > of proxy env vars (default)\n" As far as I can tell, GNU wget does not have such an option. We try to stay compatible whenever possible, so adding a new custom option is not a good idea. How would you solve this problem with GNU wget? Reading the man, --post-data and --post-file are really meant to transmit data in "application/x-www-form-urlencoded" format, not as arbitrary data. But if it is still possible with a custom --header for instance, we should be able to do the same in uclient-fetch. Otherwise, maybe curl will do a better job at this. Regards, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] OpenWrt within a Docker container
Hi, On 17-05-21, Paul Spooren wrote: > Hello, > > after some back and forth I'd like to request some more opinions on what > kind of Docker containers to offer containing the OpenWrt rootfs. This is > not about the SDK or ImageBuilder Docker containers. > > tl;dr: > > Should we ship `slim` containers only, running a OpenWrt shell (ash) and > nothing more? Whoever wants services to run (e.g. ubus) should run > additional containers and glue them together via mounts? Or should we run > /sbin/init or `procd` to have a *OpenWrt-like experience*, with LuCI, ubusd > and friends. It's a matter of use-cases: what do people want to do with OpenWrt in docker? I see two main use-cases: 1) dev / testing 2) running as an actual "virtualized" router I use docker from time to time to quickly test the userspace (musl, busybox, uclient, etc), so it's basically the first use-case and I just need a shell for this. This is the way most "basic" Docker containers work. That being said, my students used Docker for LuCI dev, and I think it relied on the fact that services (procd, ubusd, uhttpd) were already running in the container: https://gricad-gitlab.univ-grenoble-alpes.fr/projet-ter-m1-wic-openwrt/luci/-/blob/docker/docker-compose.yml https://gricad-gitlab.univ-grenoble-alpes.fr/projet-ter-m1-wic-openwrt/luci/-/blob/docker/docker/Dockerfile Maybe we should provide the "official" image with just a shell, and then another image with running services? The second use-case (running as an actual router) does not really fit the way docker works, especially with networking. For this use-case I think it's much better to run OpenWrt in LXC or as a VM, and some people actually do that. But if people really want to use docker for this, they can do it with their own Dockerfile or docker-compose setup. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Backport ipq806x cpufreq change to OpenWrt 21.02?
Hi,
There have been reports of 5.4 kernel crash on ipq806x related to cpufreq:
https://bugs.openwrt.org/index.php?do=details_id=3099
As far as I can tell, you changed the cpufreq driver recently (more
recently than the bug reports):
6e411b8416388 ("ipq806x: backport cpufreq changes to 5.4")
Do you think that it might fix the issue? If so, could you send backport
patches for the 21.02 branch or indicate which commits need to be
backported? Are there other important changes that should be part of the
21.02 release?
Thanks,
Baptiste
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uclient-http: set eof mark when content-length is 0
Merged, thanks for the fix!
On 11-03-21, Youfu Zhang wrote:
> or uclient-fetch will stall until timeout for 2XX (except 204) response
> with content-length of 0
>
> Signed-off-by: Youfu Zhang
> ---
> uclient-http.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/uclient-http.c b/uclient-http.c
> index 349e69c..c2bba6b 100644
> --- a/uclient-http.c
> +++ b/uclient-http.c
> @@ -655,7 +655,8 @@ static void uclient_http_headers_complete(struct
> uclient_http *uh)
> if (uh->eof || seq != uh->uc.seq)
> return;
>
> - if (uh->req_type == REQ_HEAD || uh->uc.status_code == 204) {
> + if (uh->req_type == REQ_HEAD || uh->uc.status_code == 204 ||
> + uh->content_length == 0) {
> uh->eof = true;
> uclient_notify_eof(uh);
> }
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] uqmi: fix network registration loop
On 10-05-21, Florian Eckert wrote:
>
>
> On 2021-05-08 12:33, Baptiste Jonglez wrote:
> > Applied, thanks.
> >
> > Does this need to be backported to 21.02 or even 19.07?
>
> yes that would not be bad at least for openwrt-21.02
> On openwrt-19.07 there are additional commits needed.
Ok, then I won't touch 19.07, unless uqmi support is really broken.
I've backported this patch to 21.02.
> Thanks for take care
>
> >
> > Baptiste
> >
> > On 20-04-21, thomas.rich...@kontron.com wrote:
> > > From: Thomas Richard
> > >
> > > With some debug in qmi.sh using following patch, some errors are
> > > visible
> > > in the registration step
> > > @@ -29,6 +29,7 @@ proto_qmi_init_config() {
> > > }
> > >
> > > proto_qmi_setup() {
> > > + set -x
> > > local interface="$1"
> > > local dataformat connstat plmn_mode mcc mnc
> > > local device apn auth username password pincode delay modes
> > > pdptype
> > > @@ -224,6 +225,8 @@ proto_qmi_setup() {
> > > fi
> > > done
> > >
> > > + registration=$(uqmi -s -d "$device" --get-serving-system)
> > > +
> > > [ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes
> > > "$modes" > /dev/null 2>&1
> > >
> > > echo "Starting network $interface"
> > >
> > > During the boot of the system, modem could not start automatically its
> > > network registration.
> > > netifd: wan (9235): + echo 'Waiting for network registration'
> > > netifd: wan (9235): Waiting for network registration
> > > netifd: wan (9235): + local 'registration_timeout=0'
> > > netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
> > > netifd: wan (9235): + grep '"searching"'
> > > netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
> > > netifd: wan (9235): +
> > > registration='{"registration":"not_registered","plmn_mcc":208,"plmn_mnc":20,"plmn_description":"","roaming":true}'
> > > netifd: wan (9235): + '[' -n ]
> > > netifd: wan (9235): + echo 'Starting network wan'
> > >
> > > As the while loop checks only "searching" pattern, uqmi.sh script
> > > quits
> > > searching loop and continues whereas the modem is not registered
> > >
> > > Other issue, after X seconds modem stops searching.
> > > netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> > > netifd: wan (9213): + grep '"searching"'
> > > netifd: wan (9213): + '[' -e /dev/cdc-wdm0 ]
> > > netifd: wan (9213): + '[' 3 -lt 0 -o 0 '=' 0 ]
> > > netifd: wan (9213): + let registration_timeout++
> > > netifd: wan (9213): + sleep 1
> > > netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> > > netifd: wan (9213): + grep '"searching"'
> > > netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> > > netifd: wan (9213): + registration='{"registration":"not_registered"}'
> > > netifd: wan (9213): + '[' -n ]
> > > netifd: wan (9213): + echo 'Starting network wan'
> > > netifd: wan (9213): Starting network wan
> > >
> > > If registration_timeout is not expired, registration can be restarted
> > >
> > > Signed-off-by: Thomas Richard
> > > ---
> > > package/network/utils/uqmi/Makefile| 2 +-
> > > .../utils/uqmi/files/lib/netifd/proto/qmi.sh | 35
> > > --
> > > 2 files changed, 27 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/package/network/utils/uqmi/Makefile
> > > b/package/network/utils/uqmi/Makefile
> > > index 68958a3729..da54ba0f46 100644
> > > --- a/package/network/utils/uqmi/Makefile
> > > +++ b/package/network/utils/uqmi/Makefile
> > > @@ -1,7 +1,7 @@
> > > include $(TOPDIR)/rules.mk
> > >
> > > PKG_NAME:=uqmi
> > > -PKG_RELEASE:=2
> > > +PKG_RELEASE:=3
> > >
> > > PKG_SOURCE_PROTO:=git
> > > PKG_SOURCE_URL=$(PROJECT_GIT)/project/uqmi.git
> > > diff --git
> > > a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> > > b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> > > index a6c785eb56..
Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core
Hi, On 20-04-21, Bas Mevissen via openwrt-devel wrote: > Date: Tue, 20 Apr 2021 01:08:19 +0200 > From: Bas Mevissen > To: openwrt-devel@lists.openwrt.org > Cc: Bas Mevissen > Subject: [PATCH] Extend checks on build prerequisites for building OpenWRT > core Merged and backported to 21.02 and 19.07, thanks. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] uqmi: fix network registration loop
Applied, thanks.
Does this need to be backported to 21.02 or even 19.07?
Baptiste
On 20-04-21, thomas.rich...@kontron.com wrote:
> From: Thomas Richard
>
> With some debug in qmi.sh using following patch, some errors are visible
> in the registration step
> @@ -29,6 +29,7 @@ proto_qmi_init_config() {
> }
>
> proto_qmi_setup() {
> + set -x
> local interface="$1"
> local dataformat connstat plmn_mode mcc mnc
> local device apn auth username password pincode delay modes pdptype
> @@ -224,6 +225,8 @@ proto_qmi_setup() {
> fi
> done
>
> + registration=$(uqmi -s -d "$device" --get-serving-system)
> +
> [ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes "$modes"
> > /dev/null 2>&1
>
> echo "Starting network $interface"
>
> During the boot of the system, modem could not start automatically its
> network registration.
> netifd: wan (9235): + echo 'Waiting for network registration'
> netifd: wan (9235): Waiting for network registration
> netifd: wan (9235): + local 'registration_timeout=0'
> netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
> netifd: wan (9235): + grep '"searching"'
> netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
> netifd: wan (9235): +
> registration='{"registration":"not_registered","plmn_mcc":208,"plmn_mnc":20,"plmn_description":"","roaming":true}'
> netifd: wan (9235): + '[' -n ]
> netifd: wan (9235): + echo 'Starting network wan'
>
> As the while loop checks only "searching" pattern, uqmi.sh script quits
> searching loop and continues whereas the modem is not registered
>
> Other issue, after X seconds modem stops searching.
> netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> netifd: wan (9213): + grep '"searching"'
> netifd: wan (9213): + '[' -e /dev/cdc-wdm0 ]
> netifd: wan (9213): + '[' 3 -lt 0 -o 0 '=' 0 ]
> netifd: wan (9213): + let registration_timeout++
> netifd: wan (9213): + sleep 1
> netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> netifd: wan (9213): + grep '"searching"'
> netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> netifd: wan (9213): + registration='{"registration":"not_registered"}'
> netifd: wan (9213): + '[' -n ]
> netifd: wan (9213): + echo 'Starting network wan'
> netifd: wan (9213): Starting network wan
>
> If registration_timeout is not expired, registration can be restarted
>
> Signed-off-by: Thomas Richard
> ---
> package/network/utils/uqmi/Makefile| 2 +-
> .../utils/uqmi/files/lib/netifd/proto/qmi.sh | 35
> --
> 2 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/package/network/utils/uqmi/Makefile
> b/package/network/utils/uqmi/Makefile
> index 68958a3729..da54ba0f46 100644
> --- a/package/network/utils/uqmi/Makefile
> +++ b/package/network/utils/uqmi/Makefile
> @@ -1,7 +1,7 @@
> include $(TOPDIR)/rules.mk
>
> PKG_NAME:=uqmi
> -PKG_RELEASE:=2
> +PKG_RELEASE:=3
>
> PKG_SOURCE_PROTO:=git
> PKG_SOURCE_URL=$(PROJECT_GIT)/project/uqmi.git
> diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> index a6c785eb56..c0134f44dd 100755
> --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> @@ -209,19 +209,36 @@ proto_qmi_setup() {
>
> uqmi -s -d "$device" --sync > /dev/null 2>&1
>
> + uqmi -s -d "$device" --network-register > /dev/null 2>&1
> +
> echo "Waiting for network registration"
> + sleep 1
> local registration_timeout=0
> - while uqmi -s -d "$device" --get-serving-system | grep '"searching"' >
> /dev/null; do
> - [ -e "$device" ] || return 1
> - if [ "$registration_timeout" -lt "$timeout" -o "$timeout" = "0"
> ]; then
> - let registration_timeout++
> - sleep 1;
> + local registration_state=""
> + while true; do
> + registration_state=$(uqmi -s -d "$device" --get-serving-system
> 2>/dev/null | jsonfilter -e "@.registration" 2>/dev/null)
> +
> + [ "$registration_state" = "registered" ] && break
> +
> + if [ "$registration_state" = "searching" ] || [
> "$registration_state" = "not_registered" ]; then
> + if [ "$registration_timeout" -lt "$timeout" ] || [
> "$timeout" = "0" ]; then
> + [ "$registration_state" = "searching" ] || {
> + echo "Device stopped network
> registration. Restart network registration"
> + uqmi -s -d "$device" --network-register
> > /dev/null 2>&1
> + }
> + let registration_timeout++
> + sleep 1
> + continue
> + fi
> +
Re: [PATCH v3 1/2] imagebuilder: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archive
On 07-05-21, Sven Roederer wrote: > Baptiste, > > Am Freitag, 7. Mai 2021, 14:12:21 CEST schrieb Baptiste Jonglez: > > > > Since these settings are hidden under "Advanced configuration options (for > > developers)", I don't think it's really necessary to leave this kind of > > implicit information, I would prefer having a valid .config file. > > > > Just sent out v4 of this patch including all the mentioned changes. Thanks, I just applied the v4! Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/2] imagebuilder: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archive
On 06-05-21, Sven Roederer wrote: > Baptiste, > > Am Donnerstag, 6. Mai 2021, 13:13:46 CEST schrieb Baptiste Jonglez: > > > > > > + $(SED) 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER was reset by > > > Imagebuilder/' $(PKG_BUILD_DIR)/.config + $(SED) > > > 's/^CONFIG_DOWNLOAD_FOLDER=.*/# CONFIG_DOWNLOAD_FOLDER was reset by > > > Imagebuilder/' $(PKG_BUILD_DIR)/.config > > Several scripts assume that this exact format is used for disabled config: > > "# CONFIG_FOO is not set" (same as in the kernel). > > > > While your patch works [probably because these scripts are not run when > > using the ImageBuilder], it seems cleaner to stick to the standard format, > > e.g. in case a .config file is copied around from an imagebuilder. > > > > The intention to not use th normal "unset" message was to leave a pointer why > it's unset in contrast to the build-time file, in case someone relies on it. > But I'm happy to us the normal message here. Since these settings are hidden under "Advanced configuration options (for developers)", I don't think it's really necessary to leave this kind of implicit information, I would prefer having a valid .config file. Maybe we should even ignore every setting under this "Advanced configuration options" menu when generating the SDK and Imagebuilder... But these two are a good start. Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/2] imagebuilder: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archive
Hi, On 26-04-21, Sven Roederer wrote: > Using these config-options to customize the folders used at build-time > makes these folder settings appear in generated archive. This causes the > imagebuilder to be not portable, as it's going to use the build-time folders > on the new systems. Errors look like: > > mkdir: cannot create directory '/mnt/build': Permission denied > Makefile:116: recipe for target '_call_image' failed > make[2]: *** [_call_image] Error 1 > Makefile:241: recipe for target 'image' failed > make[1]: *** [image] Error 2 > > The build-time settings of these folders are passed into the archives via > .config file. > The expected behavior is that after unpacking the imagebuilder acts like > these settings have their defaults, using intree folders. So unset the > build-time settings. > > Signed-off-by: Sven Roederer > --- > target/imagebuilder/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile > index f9c08776a8..ef7fd3f25e 100644 > --- a/target/imagebuilder/Makefile > +++ b/target/imagebuilder/Makefile > @@ -29,6 +29,8 @@ $(BIN_DIR)/$(IB_NAME).tar.xz: clean > mkdir -p $(IB_KDIR) $(IB_LDIR) $(PKG_BUILD_DIR)/staging_dir/host/lib \ > $(PKG_BUILD_DIR)/target $(PKG_BUILD_DIR)/scripts $(IB_DTSDIR) > -cp $(TOPDIR)/.config $(PKG_BUILD_DIR)/.config > + $(SED) 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER was reset by > Imagebuilder/' $(PKG_BUILD_DIR)/.config > + $(SED) 's/^CONFIG_DOWNLOAD_FOLDER=.*/# CONFIG_DOWNLOAD_FOLDER was reset > by Imagebuilder/' $(PKG_BUILD_DIR)/.config Several scripts assume that this exact format is used for disabled config: "# CONFIG_FOO is not set" (same as in the kernel). While your patch works [probably because these scripts are not run when using the ImageBuilder], it seems cleaner to stick to the standard format, e.g. in case a .config file is copied around from an imagebuilder. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Hi,
On 26-04-21, Sven Roederer wrote:
> Using these config-options to customize the folders used at build-time makes
> these
> folder settings appear in generated archive. This causes the SDK to be not
> portable, as it's going to use the build-time folders on the new systems.
> The errors vary from passing the build, disk out-of-space to permission
> denied.
>
> The build-time settings of these folders are passed into the archive via
> Config.in
> and Config.build.
> The expected behavior is that the SDK acts after unpacking like these
> settings have
> their defaults, using intree folders.
>
> This addresses the same issue that's fixed in the previous commit for the
> imagebuilder.
>
> Signed-off-by: Sven Roederer
> ---
> target/sdk/Makefile | 1 +
> target/sdk/convert-config.pl | 8 +++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/target/sdk/Makefile b/target/sdk/Makefile
> index 0606621192..5330d14955 100644
> --- a/target/sdk/Makefile
> +++ b/target/sdk/Makefile
> @@ -159,6 +159,7 @@ $(BIN_DIR)/$(SDK_NAME).tar.xz: clean
> $(SED) 's,^# REVISION:=.*,REVISION:=$(REVISION),g'
> $(SDK_BUILD_DIR)/include/version.mk
> $(SED) 's,^#
> SOURCE_DATE_EPOCH:=.*,SOURCE_DATE_EPOCH:=$(SOURCE_DATE_EPOCH),g'
> $(SDK_BUILD_DIR)/include/version.mk
> $(SED) '/LINUX_VERMAGIC:=/ { s,unknown,$(LINUX_VERMAGIC),g }'
> $(SDK_BUILD_DIR)/include/kernel.mk
> + $(SED) 's,default "$(CONFIG_DOWNLOAD_FOLDER)",default "",'
> $(SDK_BUILD_DIR)/Config.in
This is unnecessary: as far as I can tell, this file is just copied
verbatim from target/sdk/files/Config.in and does not contain any
build-time setting.
> find $(SDK_BUILD_DIR) -name .git | $(XARGS) rm -rf
> find $(SDK_BUILD_DIR) -name .svn | $(XARGS) rm -rf
> find $(SDK_BUILD_DIR) -name CVS | $(XARGS) rm -rf
> diff --git a/target/sdk/convert-config.pl b/target/sdk/convert-config.pl
> index f73744af09..08189df95c 100755
> --- a/target/sdk/convert-config.pl
> +++ b/target/sdk/convert-config.pl
> @@ -9,7 +9,13 @@ while (<>) {
> chomp;
> next if /^CONFIG_SIGNED_PACKAGES/;
>
> - if (/^CONFIG_([^=]+)=(.*)$/) {
> + if (/^CONFIG_((BINARY)|(DOWNLOAD))_FOLDER=(.*)$/) {
> + # We don't want to preserve the build setting of
> + # BINARY_FOLDER and DOWNLOAD_FOLDER.
> + $var = "$1_FOLDER";
> + $val = '""';
> + $type = "string";
> + } elsif (/^CONFIG_([^=]+)=(.*)$/) {
> $var = $1;
> $val = $2;
>
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH opkg] libopkg: pkg_hash: print unresolved dependencies
Hi,
On 02-05-21, Hauke Mehrtens wrote:
> When a package is not installed because it has unresolved dependencies
> normally we get only an error message like this:
> * pkg_hash_fetch_best_installation_candidate: Packages for ltq-vdsl-app
> found, but incompatible with the architectures configured
> * opkg_install_cmd: Cannot install package ltq-vdsl-app.
>
> Log in addition the following error message:
> * pkg_hash_check_unresolved: can not find dependency ltq-dsl-base for
> ltq-vdsl-app
Since the error has probably nothing to do with "architectures", wouldn't
it make more sense to remove or improve the first error message? Or
understand why it fails for seemingly unrelated reasons.
> Signed-off-by: Hauke Mehrtens
> ---
>
> I am not sure if this would happen in normal cases too and spam the
> error log, I only saw this in an error case.
>
> libopkg/pkg_hash.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
> index a07a25e..6c04ab2 100644
> --- a/libopkg/pkg_hash.c
> +++ b/libopkg/pkg_hash.c
> @@ -263,8 +263,10 @@ pkg_hash_check_unresolved(pkg_t *maybe)
> if (unresolved) {
> res = 1;
> tmp = unresolved;
> - while (*tmp)
> + while (*tmp) {
> + opkg_msg(ERROR, "can not find dependency %s for %s\n",
> *tmp, maybe->name);
> free(*(tmp++));
> + }
> free(unresolved);
> }
> pkg_vec_free(depends);
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipq40xx: fix hard_config partition size on MikroTik hAP-ac2
From: Baptiste Jonglez
The routerbootparts driver dynamically discovers the location of MikroTik
partitions, but it cannot determine their size (except by extending them
up to the start of the next discovered partition).
The hard_config partition has a default size of 0x1000 in the driver,
while it actually takes 0x2000 on the hAP-ac2. Set the correct size in
the hAP-ac2 DTS.
On most devices, this isn't a problem as the actual data fits in 0x1000
bytes. However, some devices have larger data that doesn't fit in 0x1000
bytes. In any case, all devices seen so far have enough space for a
0x2000 hard_config partition before the start of the dtb_config partition.
With the current 0x1000 size:
0xe000-0xf000 : "hard_config"
0x0001-0x00017bbc : "dtb_config"
With this patch extending the size to 0x2000:
0xe000-0x0001 : "hard_config"
0x0001-0x00017bbc : "dtb_config"
Other ipq40xx boards may need the same fix but it needs testing.
References: https://forum.openwrt.org/t/support-for-mikrotik-hap-ac2/2/324
Signed-off-by: Baptiste Jonglez
---
.../ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-hap-ac2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-hap-ac2.dts
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-hap-ac2.dts
index e1e6326ae9..d03409b556 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-hap-ac2.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-hap-ac2.dts
@@ -191,6 +191,7 @@
hard_config {
read-only;
+ size = <0x2000>;
};
dtb_config {
--
2.30.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Fix URL validation for more than one URLs.
Hi,
On 02-05-21, fabian.bauma...@mailbox.org wrote:
> That's my first contribution for OpenWRT, if something's not right, please
> let me know.
The patch is a good start (comments below), thanks a lot for your first
contribution!
There are a few formal issues with your patch. See
https://openwrt.org/submitting-patches#submission_guidelines for
guidelines, but in short:
- your email subject should start with "[PATCH uclient]" or even "[PATCH
uclient v2]" for a follow-up patch. You can just edit the email
manually before sending it with git-send-email.
- the commit message should start with "uclient-fetch: XXX"
- you're missing the Signed-off-by:
- don't forget to add "Fixes: FS#3559" when you have worked out the other
issue (a single patch for both reported issues is fine, it's the same
code that needs fixing)
> Until now, uclient-fetch only validates the first URL. If the second URL
> is invalid, it uses the first URL again.
> This patch catches the return value -1 of uclient_set_url and provides the
> user with an error message.
This should be part of the commit message description, and focus more on
the "why" than the "how".
> diff --git a/uclient-fetch.c b/uclient-fetch.c
> index 282092e..d046100 100644
> --- a/uclient-fetch.c
> +++ b/uclient-fetch.c
> @@ -384,14 +384,23 @@ static void request_done(struct uclient *cl)
> if (n_urls) {
> proxy_url = get_proxy_url(*urls);
> if (proxy_url) {
> - uclient_set_url(cl, proxy_url, NULL);
> + error_ret = uclient_set_url(cl, proxy_url, NULL);
> uclient_set_proxy_url(cl, *urls, auth_str);
> } else {
> - uclient_set_url(cl, *urls, auth_str);
> + error_ret = uclient_set_url(cl, *urls, auth_str);
> }
As far as I understand it, error_ret is meant as the global exit code of
the program, and it aims to be somewhat compatible with GNU wget (hence
the hard-coded values 4 and 8 throughout the code, see the end of "man
wget" for the codes used by GNU wget).
So, you should use a separate variable for error checking, and then set
error_ret to the appropriate value if the error needs to be communicated
through the exit code. I agree that the same function already abuses
error_ret but it seems wrong.
There's the question of what the exit code should be when one of the URL
is incorrect but the other ones are OK. I think we should again have the
same behaviour as wget for compatibility. Also, if one URL is invalid, we
should probably continue with the next one (if wget does that).
Thanks,
Baptiste
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
routerbootpart: hard_config partition can be larger than a single block on MikroTik devices
Hi Thibault, I was debugging why OpenWrt could not find the radio calibration data on one of my hAP-ac2 devices: the /sys/firmware/mikrotik/hard_config/wlan_data/ directory is created but stays empty. It turns out that the compressed data does not fit in a single block (i.e. 4 KB), and the hard_config partition spans two blocks. However, the routerbootpart parser assumes that this partition only spans a single block. As a result, the rb_hardconfig drivers tries to parse the compressed blob, see that it extends beyond the (wrongly assumed) boundary of the hard_config partition, and aborts here: /* Caller ensure tlen > 0. tofs is aligned */ if ((tofs + tlen) > hc_buflen) return -EIO; Here, hc_buflen is 4096 (the wrongly assumed size of the hard_config partition), while the offset is 0x144 and the length of the blob is x0fbc. As a result, tofs + tlen = 4352 and the check fails. Here is the mtd mapping as computed by the kernel: [0.746135] spi-nor spi0.0: w25q128jv (16384 Kbytes) [0.746199] 3 fixed-partitions partitions found on MTD device spi0.0 [0.751062] Creating 3 MTD partitions on "spi0.0": [0.757427] 0x-0x0008 : "Qualcomm" [0.763004] 0x0008-0x0010 : "RouterBoot" [0.772971] 3 routerbootpart partitions found on MTD device RouterBoot [0.773003] Creating 3 MTD partitions on "RouterBoot": [0.778977] 0xe000-0xf000 : "hard_config" [0.784993] 0x0001-0x00017bbc : "dtb_config" [0.790390] 0x0003d000-0x0003e000 : "soft_config" [0.795860] 0x0010-0x0100 : "firmware" The hard_config partition should actually span 0xe000-0x0001 in this case. Do you see a clean way to support this without breaking support for other boards? Do you think we can determine this size from somewhere else in the flash, or should I just set "size = <0x2000>" in the DTS and hope that it's valid for all hap-ac2 boards? Thanks, Baptiste PS: for reference, this hap-ac2 board was bought on 2019-10-29, is labeled /939/r2, and has a MAC starting with 74:4D:28. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
On 21-04-21, Perry wrote: > Now that openwrt-21.02-rc1 is tagged, would it be possible to have an > "openwrt-21.02" section for the Reported Version on bugs.openwrt.org? > While at it, why is it still possible to file bug reports for lede-17.01? Good catch, thanks. I have just added openwrt-21.02 to the bug tracker and disabled the possibility to use 17.01 and 18.06 for new bugs. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH buildbot] phase1, phase2: don't mark the build failed if a non-critical step fails
From: Baptiste Jonglez
Some steps are informative or optional (haltOnFailure=False), so it makes
no sense to mark the whole build as failed if such a step fails.
Depending on the case, we either mark the build as "warning"
(warnOnFailure=True) or as successful (warnOnFailure=False).
Signed-off-by: Baptiste Jonglez
---
phase1/master.cfg | 6 ++
phase2/master.cfg | 18 +++---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/phase1/master.cfg b/phase1/master.cfg
index 725d55e..a1f7dea 100644
--- a/phase1/master.cfg
+++ b/phase1/master.cfg
@@ -1350,6 +1350,8 @@ for target in targets:
command=["../rsync.sh", "--delete", "--delay-updates",
"--partial-dir=.~tmp~%s~%s" %(ts[0], ts[1]), "-a"] + rsync_bin_defopts +
["bin/packages/", "%s/packages/" %(rsync_bin_url)],
env={'RSYNC_PASSWORD': rsync_bin_key},
haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = True,
logEnviron = False,
))
@@ -1361,6 +1363,8 @@ for target in targets:
command=["../rsync.sh", "--delete", "--delay-updates",
"--partial-dir=.~tmp~%s~%s" %(ts[0], ts[1]), "-az"] + rsync_bin_defopts +
["logs/", "%s/logs/%s/%s/" %(rsync_bin_url, ts[0], ts[1])],
env={'RSYNC_PASSWORD': rsync_bin_key},
haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = True,
alwaysRun = True,
logEnviron = False,
))
@@ -1371,6 +1375,8 @@ for target in targets:
command=["df", "-h", "."],
env={'LC_ALL': 'C'},
haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = False,
alwaysRun = True
))
diff --git a/phase2/master.cfg b/phase2/master.cfg
index 7b103e8..b5050e5 100644
--- a/phase2/master.cfg
+++ b/phase2/master.cfg
@@ -604,7 +604,9 @@ for arch in arches:
description = "Clearing failure logs",
workdir = "build/sdk",
command = ["rm", "-rf", "logs/package/error.txt", "faillogs/"],
- haltOnFailure = False
+ haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = True,
))
factory.addStep(ShellCommand(
@@ -701,7 +703,9 @@ for arch in arches:
description = "Finding failure logs",
workdir = "build/sdk/logs/package/feeds",
command = ["sh", "-c", "sed -ne 's!^ *ERROR:
package/feeds/\\([^ ]*\\) .*$!\\1!p' ../error.txt | sort -u | xargs -r find >
../../../logs.txt"],
- haltOnFailure = False
+ haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = True,
))
factory.addStep(ShellCommand(
@@ -709,7 +713,9 @@ for arch in arches:
description = "Collecting failure logs",
workdir = "build/sdk",
command = ["rsync", "-av", "--files-from=logs.txt",
"logs/package/feeds/", "faillogs/"],
- haltOnFailure = False
+ haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = True,
))
factory.addStep(ShellCommand(
@@ -719,6 +725,8 @@ for arch in arches:
command = ["rsync", "-4", "--progress", "--delete",
"--delay-updates", "--partial-dir=.~tmp~%s" %(arch[0]), "-avz", "faillogs/",
WithProperties("%s/faillogs%%(suffix)s/%s/" %(rsync_bin_url, arch[0]),
suffix=GetDirectorySuffix)],
env={'RSYNC_PASSWORD': rsync_bin_key},
haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = True,
logEnviron = False
))
@@ -739,6 +747,8 @@ for arch in arches:
WithProperties("--partial-dir=.~tmp~%s~%%(workername)s" %(arch[0])), "-avz",
"dl/", "%s/" %(rsync_src_url)],
env={'RSYNC_PASSWORD': rsync_src_key},
haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = True,
logEnviron = False
))
@@ -748,6 +758,8 @@ for arch in arches:
command=["df", "-h", "."],
env={'LC_ALL': 'C'},
haltOnFailure = False,
+ flunkOnFailure = False,
+ warnOnFailure = False,
alwaysRun = True
))
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH buildbot v2] phase1, phase2: exclude temporary source files from sourceupload step
From: Baptiste Jonglez When the dl/ directory is shared with several workers, there can be temporary "*.hash" and "*.dl" files being created by other workers. These files should be excluded from the sourceupload step, otherwise it can cause a failure when rsync tries to read them. See for example: https://buildbot.openwrt.org/master/packages/#/builders/14/builds/18/steps/39/logs/stdio Signed-off-by: Baptiste Jonglez --- phase1/master.cfg | 2 +- phase2/master.cfg | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/phase1/master.cfg b/phase1/master.cfg index 363d77e..725d55e 100644 --- a/phase1/master.cfg +++ b/phase1/master.cfg @@ -1329,7 +1329,7 @@ for target in targets: factory.addStep(ShellCommand( name = "sourcelist", description = "Finding source archives to upload", - command = "find dl/ -maxdepth 1 -type f -not -size 0 -not -name '.*' -newer .config -printf '%f\\n' > sourcelist", + command = "find dl/ -maxdepth 1 -type f -not -size 0 -not -name '.*' -not -name '*.hash' -not -name '*.dl' -newer .config -printf '%f\\n' > sourcelist", haltOnFailure = True )) diff --git a/phase2/master.cfg b/phase2/master.cfg index 4d5e595..7b103e8 100644 --- a/phase2/master.cfg +++ b/phase2/master.cfg @@ -727,7 +727,7 @@ for arch in arches: name = "sourcelist", description = "Finding source archives to upload", workdir = "build/sdk", - command = "find dl/ -maxdepth 1 -type f -not -size 0 -not -name '.*' -newer ../sdk.archive -printf '%f\\n' > sourcelist", + command = "find dl/ -maxdepth 1 -type f -not -size 0 -not -name '.*' -not -name '*.hash' -not -name '*.dl' -newer ../sdk.archive -printf '%f\\n' > sourcelist", haltOnFailure = True )) -- 2.30.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH buildbot] phase2: exclude temporary files from sourceupload step
From: Baptiste Jonglez When the dl/ directory is shared with several workers, there can be temporary "*.hash" and "*.dl" files being created by other workers. These files should be excluded from the sourceupload step, otherwise it can cause a failure when rsync tries to read them. See for example: https://buildbot.openwrt.org/master/packages/#/builders/14/builds/18/steps/39/logs/stdio Signed-off-by: Baptiste Jonglez --- phase2/master.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/phase2/master.cfg b/phase2/master.cfg index 4d5e595..7b103e8 100644 --- a/phase2/master.cfg +++ b/phase2/master.cfg @@ -727,7 +727,7 @@ for arch in arches: name = "sourcelist", description = "Finding source archives to upload", workdir = "build/sdk", - command = "find dl/ -maxdepth 1 -type f -not -size 0 -not -name '.*' -newer ../sdk.archive -printf '%f\\n' > sourcelist", + command = "find dl/ -maxdepth 1 -type f -not -size 0 -not -name '.*' -not -name '*.hash' -not -name '*.dl' -newer ../sdk.archive -printf '%f\\n' > sourcelist", haltOnFailure = True )) -- 2.30.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 19.07.7 service release
Hi, The OpenWrt community is proud to announce the seventh service release of OpenWrt 19.07. It fixes security issues, improves device support, and brings a few bug fixes. The main changes from OpenWrt 19.07.6 are: Security fixes == * Security Advisory 2021-02-02-1 - netifd and odhcp6c routing loop on IPv6 point to point links (CVE-2021-22161) * Security Advisory 2021-02-02-2 - wolfSSL heap buffer overflow in RsaPad_PSS (CVE-2020-36177) Major bug fixes === * Fix dnsmasq error messages such as "failed to send packet: Network unreachable" or "failed to send packet: Address family not supported by protocol" that could be filling up logs. This was a regression caused by the dnsmasq update in 19.07.6. * Fix opkg so that it purges obsolete packages from its local cache. This fixes a long-standing issue in the ImageBuilder where a manual cleanup was needed before rebuilding. Device support == * Improve stability of mediatek Ethernet switch (affects many mt7621 devices) * Fix Wi-Fi band detection on some Broadcom-based devices * Fix poor 2.4 GHz Wi-Fi performance on TP-Link Archer C50 v4 due to a missing EEPROM chip ID * Make initramfs image usable out-of-the-box on Turris Omnia * Use full flash size on Nucom R5010UN v2 * Fix support for TP-Link TL-WR810N v1 in ath79 * Remove broken factory image for TP-Link Archer C2 v1 * Fix unintended failsafe mode during boot on Netgear EX6150 Various fixes and improvements == * The ImageBuilder no longer requires compilers (gcc, g++) and libncurses-dev. This was partially implemented in 19.07.6 but one part was missing to make it actually work. * Update to a new major version of ksmbd to fix several bugs. This breaks compatibility with previous versions of OpenWrt (19.07.0 to 19.07.6): it is no longer possible to install a working version of ksmbd-tools on previous versions of OpenWrt. Existing installations will keep working, but ksmbd-tools should not be upgraded with opkg. Unfortunately, this ksmbd update introduced a regression: the kernel module package for ksmbd depends on the non-existant kmod-crypto-arc4. If you are affected by this issue, see https://openwrt.org/releases/19.07/notes-19.07.7#regressions for a workaround. LuCI web interface == * Fix array sorting on Chrome * Add nextdns.io and quad 101 providers to luci-app-https-dns-proxy package Core components === * Update Linux kernel from 4.14.215 to 4.14.221 * Update wolfssl from 4.5.0 to 4.6.0 Full release notes and upgrade instructions are available at https://openwrt.org/releases/19.07/notes-19.07.7 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/19.07/notes-19.07.7#regressions For a very detailed list of all changes since 19.07.6, refer to https://openwrt.org/releases/19.07/changelog-19.07.7 For latest information about the 19.07 series, refer to the wiki at: https://openwrt.org/releases/19.07/ To download a OpenWrt 19.07.7 firmware image for your device, head to the Table of Hardware: https://openwrt.org/toh/start Or use the new firmware selector: https://firmware-selector.openwrt.org/ You can also navigate directly in the list of firmware images: https://downloads.openwrt.org/releases/19.07.6/targets/ As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming 19.07.7 release
On 08-02-21, Etan Kissling (IC) wrote: > I have posted a few backports to 19.07 from master a few weeks back, with > these subjects: > > 1. [PATCH 19.07] mbedtls: add config option to compile with hkdf > 2. [PATCH 19.07] hostapd: add multicast_to_unicast and per_sta_vif > 3. [PATCH 19.07] hostapd: enable CTRL_IFACE_MIB for hostapd-full > 4. [PATCH 19.07] nf-conntrack: allow querying conntrack info in nfqueue > 5. [PATCH 19.07] libnetfilter-queue: update to 1.0.5 > > My patches don't end up in Patchwork for some reason. It seems to be caused by DMARC, maybe try with another email address. > If those are acceptable, be sure to take the latest submission for the > patches that were submitted multiple times. They didn't make into 19.07.7. This is not my area of expertise, but at first glance it looks too ambitious for a backport. We typically only backport bug fixes and sometimes device support; backporting new features would need a very good reason, especially in core software like hostapd. I haven't looked at your patches in details though. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming 19.07.7 release
On 07-02-21, Jaap Buurman wrote: > Are we sure disabling TSO is the actual fix though? There are a few > reasons I am doubting that assessment: > > 1. Here is a user that is reporting he has always been running with > TSO disabled, yet he does experience the bug: > https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/5/389?u=mushoz > 2. TSO seems fine with the master branch according to user reports. > 3. The user "mrakotiq" suggested a patch to disable TSO in the bug > report you linked to, but this bug report also disables > NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX. The reason that was > given was that he was seeing packets getting tagged that shouldn't > have (at least that's what I am understanding from his post on the bug > report). So there's obviously also something wrong with this > functionality, and it might not surprise me if this change is the > thing that seems to fix this issue. I took time to reproduce this using data from mrakotiq. I could reproduce the crash, it takes a few hours. Also, disabling NETIF_F_TSO and NETIF_F_TSO6 indeed makes the crash disappear, at least with this specific test. With the patch, performance is a bit lower when forwarding small TCP packets, but it's still fast enough to reach around 1 Gbit/s with full-size packets (80 kpps). Overall, I wouldn't be surprised if the issue is still lurking, but the patch does seem to improve stability. I'm running a few more tests and I will add it for the next 19.07 release. The master branch is fine, but it's using a different driver. It's an upstream driver, so it probably received more scrutiny than the one used in 19.07. It should be more reliable to run these devices with 21.02 when it's out. > Having said that, this bug is age-old and is affecting a lot of users, > me included. So I'd really like to get fixed. If there are no > regression with this approach, the best way forward might be to simply > adapt the patch he suggested as a workaround until we're on 21.xx with > the DSA driver. Especially since this user is reporting no more issues > with 75 (!) mt7621 routers in his production network, which is a > rather large sample size. Thoughts? > > Jaap signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming 19.07.7 release
On 05-02-21, Jaap Buurman wrote: > > Hi, > > > > We are planning a new 19.07 release in about a week (probably next > > week-end). > > > > If you are aware of changes that need to be integrated, now is the time to > > do it or mention it here! > > > > I plan to test & integrate a workaround for this ramips stability issue: > > https://bugs.openwrt.org/index.php?do=details_id=2628 > > > > Baptiste > > > > PS: please don't ask about 21.XX > > Dear Baptiste, > > Out of interest, what workaround for the RAMIPS stability issue are > you planning on using? Is it the disabling of TSO as discussed in the > bug report you have linked to? Yes, that's the idea, if it turns out to be not too intrusive. It's clearly a workaround from some other issue: as stated in the bug report, we use another driver in 5.4 and this one has no issue with TSO. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Upcoming 19.07.7 release
Hi, We are planning a new 19.07 release in about a week (probably next week-end). If you are aware of changes that need to be integrated, now is the time to do it or mention it here! I plan to test & integrate a workaround for this ramips stability issue: https://bugs.openwrt.org/index.php?do=details_id=2628 Baptiste PS: please don't ask about 21.XX signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Backporting opkg fixes to 19.07
Hi, I've just pushed this to my (brand new) staging tree: https://git.openwrt.org/?p=openwrt/staging/zorun.git;a=shortlog;h=refs/heads/openwrt-19.07 If there are no objections, I will merge that in a couple of days. Baptiste On 24-01-21, Baptiste Jonglez wrote: > Hi, > > I would like to backport the opkg fix for > https://bugs.openwrt.org/index.php?do=details_id=2690 > to 19.07. > > The opkg package in 19.07 is a bit old, it's using: > > f2166a8 libopkg: implement lightweight package listing logic > > Since there were several other changes in opkg master, I would create a > new openwrt-19.07 branch in opkg based on f2166a8, and backport these commits: > > 61b3c62 opkg_verify_integrity: better logging and error conditions > f73d42f download: purge cached packages that have incorrect checksum > 1c1480e download: factor out the logic for building cache filenames > 293b1ce libopkg: factor out checksum and size verification > a786e25 download: remove compatibility with old cache naming scheme > > And maybe also this fix for another issue: > > 66f458d libopkg: fix md5sum calculation > > As far as I can tell, it shouldn't cause issues such as ABI breakage, but > I prefer if somebody can double-check... > > Thanks, > Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Backporting opkg fixes to 19.07
Hi, I would like to backport the opkg fix for https://bugs.openwrt.org/index.php?do=details_id=2690 to 19.07. The opkg package in 19.07 is a bit old, it's using: f2166a8 libopkg: implement lightweight package listing logic Since there were several other changes in opkg master, I would create a new openwrt-19.07 branch in opkg based on f2166a8, and backport these commits: 61b3c62 opkg_verify_integrity: better logging and error conditions f73d42f download: purge cached packages that have incorrect checksum 1c1480e download: factor out the logic for building cache filenames 293b1ce libopkg: factor out checksum and size verification a786e25 download: remove compatibility with old cache naming scheme And maybe also this fix for another issue: 66f458d libopkg: fix md5sum calculation As far as I can tell, it shouldn't cause issues such as ABI breakage, but I prefer if somebody can double-check... Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Persistent HTTP(S) connections in opkg
Hi, On 31-12-20, Hauke Mehrtens wrote: > > I looked into performance problems of LuCI when using https some time ago. > > > > The slow part was the handshake, the normal stream cipher is relatively > > fast, even very slow devices should be able to do multiple MB/s. > > > > On the server side the ECC handshake was much faster, I think I measured > > values like 1 second (RSA) vs. 0.3 seconds (ECC) for the handshake on a > > Lantiq MIPS 24Kec CPU with mbedtls, the RSA handshake was much faster > > (0.5 seconds) with openssl. > > > > We should activate support for ECC certificates on > > https://downloads.openwrt.org, I think it is possible to use both RSA > > and ECC on the server and then decide based on what the client supports > > and wants. In OpenWrt we could use then ECC to authenticate the server. > > The crypto parts should already be there as we need ECDH for SAE in > > hostapd. > > > > We could use TLS Session Resumption, the SSL libraries should support > > it, this way we can easily reuse the same session for the next download. > > Browsers do this to only do one SSL handshake and then have multiple TCP > > connections to the server to download the material in parallel. > > > > Hauke > > The changes I did are here: > https://git.openwrt.org/f2c8f6dc3249b506b915741d12905402dfffe162 > https://git.openwrt.org/e8a1469 > > These are only for mbedtls and not for openssl/wolfssl it could be that this > causes some problems. I would also assume that openssl is much faster than > wolfssl, so we do not see these problems so much with openssl. Thanks for the hints and the links. I assume that the TLS session cache is only kept in memory? This makes sense for a server process, but it is less useful on the client side. Especially because currently opkg forks to call uclient-fetch individually for each package download. It would be useful when downloading several files with one uclient-fetch invocation, but this feature is broken. In any case, you're right: it's a good idea to benchmark before trying to optimize something. Once I fixed my test devices, I will run performance tests with client-side TLS. Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uclient] uclient-fetch: document missing options
From: Baptiste Jonglez Missing ones were: --no-proxy, --quiet, --continue / -c Also improved readability of several options. Signed-off-by: Baptiste Jonglez --- uclient-fetch.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/uclient-fetch.c b/uclient-fetch.c index 958f756..282092e 100644 --- a/uclient-fetch.c +++ b/uclient-fetch.c @@ -475,17 +475,20 @@ static int usage(const char *progname) "Options:\n" " -4 Use IPv4 only\n" " -6 Use IPv6 only\n" - " -q Turn off status messages\n" " -ORedirect output to file (use \"-\" for stdout)\n" " -P Set directory for output files\n" + " --quiet | -qTurn off status messages\n" + " --continue | -c Continue a partially-downloaded file\n" " --user= HTTP authentication username\n" " --password= HTTP authentication password\n" - " --user-agent|-USet HTTP user agent\n" + " --user-agent | -U Set HTTP user agent\n" " --post-data=STRING use the POST method; send STRING as the data\n" " --post-file=FILEuse the POST method; send FILE as the data\n" - " --spider|-s Spider mode - only check file existence\n" - " --timeout=N|-T NSet connect/request timeout to N seconds\n" - " --proxy=on|off|-Y on|offEnable/disable env var configured proxy\n" + " --spider | -s Spider mode - only check file existence\n" + " --timeout=N | -T N Set connect/request timeout to N seconds\n" + " --proxy=on | -Y on Enable interpretation of proxy env vars (default)\n" + " --proxy=off | -Y off |\n" + " --no-proxy Disable interpretation of proxy env vars\n" "\n" "HTTPS options:\n" " --ca-certificate= Load CA certificates from file \n" -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Persistent HTTP(S) connections in opkg
Following the discussion in http://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032297.html There are basically two options to implement persistent connections in opkg: 1) keep calling "wget", but pass the list of all packages to download at once. On the host, wget already implements persistent connections. For devices, we would need to implement persistent connections in uclient-fetch (which is what "wget" actually points to). 2) switch to using a HTTP library (libuclient or libcurl), so that we can keep some TCP/TLS/HTTP context between downloads. The first solution has a major drawback on devices: all packages would need to be downloaded to /tmp, which will consume memory. Currently, opkg processes packages individually, so only one package at a time is stored in /tmp. The second solution adds a new library dependency, and we need to make sure that it works both on the host and on targets. Currently, we don't make libuclient available to the host build system. We would need to build it for the host and link opkg statically against it (like it's done for libubox). Overall, I think the second solution makes more sense and is easier to integrate. I would go with libuclient because we already have it available on devices. Any thoughts? Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build/prereq: merge ifndef IB block together
Hi,
On 29-12-20, Paul Spooren wrote:
> Multiple prereq checks are only required within the build system but not
> for the ImageBuilder. These checks are excluded by using ifndef IB.
>
> This commit merges the three ifndef IB blocks together.
To clarify, this is only cosmetic, right?
I just saw the last changes that avoid requiring build dependencies for
the imagebuilder, this is good news. It makes sense to backport them
(4a1a58a3e2d236 & ae12a747cae3d & this one) for openwrt-19.07.
Thanks,
Baptiste
> diff --git a/include/prereq-build.mk b/include/prereq-build.mk
> index ad204e95e8..3a51c4cd70 100644
> --- a/include/prereq-build.mk
> +++ b/include/prereq-build.mk
> @@ -38,9 +38,7 @@ $(eval $(call TestHostCommand,working-gcc, \
> it appears to be broken, \
> echo 'int main(int argc, char **argv) { return 0; }' | \
> gcc -x c -o $(TMP_DIR)/a.out -))
> -endif
>
> -ifndef IB
> $(eval $(call SetupHostCommand,g++, \
> Please install the GNU C++ Compiler (g++) 4.8 or later, \
> $(CXX) -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?|10\.?)', \
> @@ -53,14 +51,12 @@ $(eval $(call TestHostCommand,working-g++, \
> echo 'int main(int argc, char **argv) { return 0; }' | \
> g++ -x c++ -o $(TMP_DIR)/a.out - -lstdc++ && \
> $(TMP_DIR)/a.out))
> -endif
>
> -ifndef IB
> $(eval $(call TestHostCommand,ncurses, \
> Please install ncurses. (Missing libncurses.so or ncurses.h), \
> echo 'int main(int argc, char **argv) { initscr(); return 0; }' | \
> gcc -include ncurses.h -x c -o $(TMP_DIR)/a.out - -lncurses))
> -endif
> +endif # IB
>
> ifeq ($(HOST_OS),Linux)
>zlib_link_flags := -Wl,-Bstatic -lz -Wl,-Bdynamic
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ramips mt7621 kernel crash related to TSO on 19.07
Hi, OpenWrt 19.07 on mt7621 can sometimes crash under load. It does not trigger often so it might go unnoticed, but there are multiple reports of this issue and I also experienced it on a device. Here is an example crash log: https://bugs.openwrt.org/index.php?getfile=1116 Somebody managed to workaround the issue by disabling TSO in the ethernet driver: https://bugs.openwrt.org/index.php?do=details_id=2628 Does that sound like a proper fix, or would it rather be a symptom for another issue? As far as I understand, the mt7621 ethernet driver in 19.07 is not the same as the one in master. The upstream driver used in master seems to enable TSO support: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/mediatek/mtk_eth_soc.h?h=linux-5.4.y#n36 Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Upcoming 19.07.6 release plan
___ 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
Security Advisory 2020-12-09-1 - Linux kernel - ICMP rate limiting can be used to facilitate DNS poisoning attack (CVE-2020-25705)
https://openwrt.org/advisory/2020-12-09-1 DESCRIPTION A flaw has been found in the ICMP rate limiting algorithm of the Linux kernel. This flaw allows an off-path attacker to quickly determine open ephemeral ports that are used by applications making outbound connections. This can be exploited by an off-path attacker to more easily perform a DNS cache poisoning attack. Such an attack normally involves trying all possible values of the UDP source port and the DNS transaction ID, which is considered difficult to do. With this flaw, the attacker can quickly guess the UDP source port, and then it only has to try all possible values of the DNS transaction ID, which is easier to do: the transaction ID only has 16 bits. It should be noted that the attacker also needs to know the actual query sent by the resolver. IMPACT ON OPENWRT OpenWrt is affected in its default configuration. By default, dnsmasq is used to perform DNS resolution and the firewall allows the kernel to reply with ICMP errors when hosts on the Internet send packets to closed UDP ports. An off-path attacker may use this flaw to more easily perform a DNS cache poisining attack on dnsmasq. AFFECTED VERSIONS OpenWrt versions 18.06.0 to 18.06.8 and versions 19.07.0 to 19.07.4 are affected. The issue has been fixed in the following versions of OpenWrt: OpenWrt 18.06.9 (fixed by updating the Linux kernel to 4.9.243 and 4.14.206) OpenWrt 19.07.5 (fixed by updating the Linux kernel to 4.14.206) OpenWrt master as of 2020-11-01 (fixed by updating the Linux kernel to 5.4.73) Older versions of OpenWrt (e.g. OpenWrt 15.05 and LEDE 17.01) are end of life and not supported any more. MITIGATION It is recommended to upgrade to the latest 18.06 or 19.07 release of OpenWrt. If upgrading is not possible, the flaw can be mitigated on older versions of OpenWrt by disabling ICMP errors on the WAN firewall zone. This can be achieved by changing the input policy from REJECT to DROP in the WAN firewall zone and reloading the firewall configuration. Users that have upgraded to 18.06.9 or 19.07.5 do not need to apply this mitigation. CREDITS AND REFERENCES The issue was disclosed by Keyu Man et al. from the University of California as the “SAD DNS” attack. https://www.saddns.net/ Fix in linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b38e7819cae946e2edf869e604af1e65a5d241c5 CVE description at NIST: https://nvd.nist.gov/vuln/detail/CVE-2020-25705 CVE description at Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-25705 signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Lightweight policy-based routing
On 04-12-20, Philip Prindeville wrote: > But I’m trying: > > config rule > option src '192.168.3.6' > option lookup 200 > > Per the cheatsheet and it’s resulting in: > > root@OpenWrt2:~# ip rule ls > 0:from all lookup local > 1:from all lookup 200 > 32766:from all lookup main > 32767:from all lookup default > > i.e. the ’src’ is being ignored. Several years ago (probably with LEDE 17.01) I was using this configuration and it worked: config rule option in 'lan' option src '172.23.184.111/32' option lookup '666' Try with the /32. If it still doesn't work, then it's a regression. > Also trying: > > config route > option target '151.101.0.0/16' > option interface ‘xfrm0' > option gateway '192.168.1.252' > option table 200 > option proto ‘static' > > But that works great. > > > > On Dec 4, 2020, at 1:00 PM, Jo-Philipp Wich wrote: > > > > Hi Philip, > > > > ip rules are possible in uci, but not sure if all the bits you require are > > covered: > > > > https://openwrt.org/docs/guide-user/network/ucicheatsheet#ip_rules_for_both_rule_and_rule6 > > > > `config route` sections allow specifying `option table` as well to stage the > > routes in the non-main rttable. > > > > Since the device options for uci rules and routes require logical networks > > and > > not Linux network device names, you might need to declare a dummy interface > > for xfrm0, like this: > > > > config interface vpn > > option proto static > > option ifname xfrm0 > > > > It might be that netifd will clear out any IP addresses on the xfrm0 > > interface, so you would need to encode those in uci as well: > > > > config interface vpn > > option proto static > > option ifname xfrm0 > > option ipaddr 192.168.1.0/24 > > option table 200 # will instruct netifd to put any related routes into > > table 200 > > > > > > Netifd understands aliases set up in /etc/iproute2/rt_tables but there is no > > uci way to declare new symbolic aliases. So either you need to manage that > > file externally or you stick to numeric table IDs. > > > > ~ Jo > > > > ___ > > 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 signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
Hi, On 06-12-20, Sven Roederer wrote: > Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as they > work quite well for basic usage (including full LuCI). > On some projects with advanced features (e.g. Freifunk) the lack of RAM turns > them into unstable devices. Mostly caused by several OOM problems per day. > This series tries to prolong the usage of these boards by moving them to the > ath79-tiny target. Indeed it makes these boards available on ath79-tiny in > addition to the current ath79-generic variant. Can't you just move the boards instead of duplicating them? > To improve the low RAM situation the default kernel-config for the tiny sub- > target will also disable some uncommon features. So the kernel image becomes > smaller, which results in lower flash- and RAM-footprint. Some of the patches below have broken SoB. > [RFC PATCH 1/5] ath79: put some 8/32MB devices to tiny subtarget > [RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny > [RFC PATCH 3/5] ath79: deactivate PARTITION_ADVANCED > [RFC PATCH 4/5] kernel: ath79-tiny deactivate usually not needed features Can you provide an overview of kernel memory consumption before and after? /proc/vmstat just after boot would give an idea. > [RFC PATCH 5/5] kernel: ath79-tiny: enable CONFIG_BLOCK What does this do? Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SAD DNS cache poisoning attack
On 05-12-20, Alexander 'lynxis' Couzens wrote: > Hi, > > I'm wondering is dnsmasq also vulnerable as forwarder? Or > only as recursive resolver? Yes, as forwarder. I don't think dnsmasq implements a real recursive resolver. > Did someone tested it? Is there a public poc? I tested the basic behaviour used by the attack (ICMP errors when hitting a closed port, nothing when hitting a open port and spoofing the peer address) and it worked. I did not reproduce the full attack but since we are not customizing this part of the kernel it should work. I am not aware of a public PoC. Successful cache poisoning is not straightforward to pull off because you still have to guess the transaction ID and you have limited time to do so. But a motivated attacker can definitely do it, it does not require significant resources. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Revert "build: switch VERSION_REPO to HTTPS"
Hi, On 25-11-20, Petr Štetiar wrote: > Paul Spooren [2020-11-24 22:29:00]: > > Hi, > > > Using HTTPS for opkg dramatically slows down download of packages and reload > > of indexes. > > do you've such dramatic numbers handy? For the imagebuilder, it increases the *total* build time (not just download time!) by +50%: http://lists.openwrt.org/pipermail/openwrt-devel/2020-September/031406.html On a device, I suspect it will be much worse but I can't currently test that. It shouldn't be too hard, just make sure to clean opkg files between each test to have a proper apple-to-apple comparison. The main problem is the lack of persistent connection, which means doing a full expensive TLS exchange for each separate file download, however small it is. It's a lot of crypto for a small CPU on devices, and if it's widely deployed it will also impact the load on the download server. Thus, it's not reasonable to have this by default in a release. I'm working on adding persistent connection support to opkg but it's not straightforward. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
Hi, On 20-11-20, Adrian Schmutzler wrote: > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Baptiste Jonglez > > Sent: Freitag, 20. November 2020 11:21 > > To: openwrt-devel@lists.openwrt.org; John Crispin > > Cc: Baptiste Jonglez > > Subject: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double > > tagging" > > > > From: Baptiste Jonglez > > > > This change has been causing several issues on ipq40xx devices, including: > > this seems to lack a Signed-off-by? You're totally right, thanks for spotting this. I've just sent a v2. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07 v2] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
From: Baptiste Jonglez
This change has been causing several issues on ipq40xx devices, including:
- VLAN tagging no longer works correctly:
https://bugs.openwrt.org/index.php?do=details_id=3239
- poor performance with tagged VLANs:
https://bugs.openwrt.org/index.php?do=details_id=3457
See also
https://forum.openwrt.org/t/vlan-tagging-on-ipq40xx-gl-b1300-no-longer-works/69569
There are have been discussions on ways to fix the issue in the links
above (including switching to DSA), but nothing that can realistically
be introduced in the 19.07 branch.
This reverts commit 8c191712558c ("ipq40xx: fix ethernet vlan double
tagging")
Note that it's not a clean revert because this patch was touched in
148d59c67edd ("kernel: update kernel 4.14 to version 4.14.193") even
though the semantic of the patch was left unchanged.
Fixes: FS#3239
Fixes: FS#3457
Fixes: 8c191712558c ("ipq40xx: fix ethernet vlan double tagging")
Signed-off-by: Baptiste Jonglez
---
.../716-essedma-vlan-double-tag.patch | 128 --
1 file changed, 128 deletions(-)
delete mode 100644
target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
diff --git
a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
b/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
deleted file mode 100644
index e268351273..00
--- a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-From: Sven Eckelmann
-Date: Wed, 8 Feb 2017 16:26:00 +0100
-Subject: [PATCH] ipq40xx: Fix ar40xx port separation
-
-It is currently not possible to submit (or receive) VLAN tagged frames over
-the ar40xx PHY switch and the edma ethernet device.
-
-This can be worked around by disabling enable_vlan. The separation of the
-eth0 and eth1 ports is then done by the vlan_tag information from the
-device tree. But the ar40xx PHY switch then also has to parse the word3
-port bitmap (word3) from the TDP when data was received from the CPU port
-(0).
-
-IssueID: #2857
-
-Forwarded: no
- The ar40xx.c change was forwarded to Xiaofei Shen
- (QCA). But John Crispin will rewrite the driver anyway and we have to check
- later if this change is required in his driver too.
- drivers/net/phy/ar40xx.c | 6 +-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
a/drivers/net/phy/ar40xx.c
-+++ b/drivers/net/phy/ar40xx.c
-@@ -1200,7 +1200,11 @@ ar40xx_init_port(struct ar40xx_priv *pri
- ar40xx_rmw(priv, AR40XX_REG_PORT_STATUS(port),
- AR40XX_PORT_AUTO_LINK_EN, 0);
-
-- ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-+ /* CPU port is setting headers to limit output ports */
-+ if (port == 0)
-+ ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0x8);
-+ else
-+ ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), 0);
-
-@@ -1243,6 +1247,10 @@ ar40xx_init_globals(struct ar40xx_priv *
- t = (AR40XX_PORT0_FC_THRESH_ON_DFLT << 16) |
- AR40XX_PORT0_FC_THRESH_OFF_DFLT;
- ar40xx_write(priv, AR40XX_REG_PORT_FLOWCTRL_THRESH(0), t);
-+
-+ /* set service tag to 802.1q */
-+ t = ETH_P_8021Q | AR40XX_ESS_SERVICE_TAG_STAG;
-+ ar40xx_write(priv, AR40XX_ESS_SERVICE_TAG, t);
- }
-
- static void
-@@ -1568,7 +1576,11 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- u32 pvid = priv->vlan_id[priv->pvid[port]];
-
- if (priv->vlan) {
-- egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
-+ if (priv->vlan_tagged & BIT(port))
-+ egress = AR40XX_PORT_VLAN1_OUT_MODE_TAG;
-+ else
-+ egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
-+
- ingress = AR40XX_IN_SECURE;
- } else {
- egress = AR40XX_PORT_VLAN1_OUT_MODE_UNTOUCH;
-@@ -1579,8 +1591,17 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- t |= pvid << AR40XX_PORT_VLAN0_DEF_CVID_S;
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), t);
-
-- t = AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
-- t |= egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+ t = egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+
-+ /* set CPU port to core port */
-+ if (port == 0)
-+ t |= AR40XX_PORT_VLAN1_CORE_PORT;
-+
-+ if (priv->vlan_tagged & BIT(port))
-+ t |= AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
-+ else
-+ t |= AR40XX_PORT_VLAN1_PORT_TLS_MODE;
-+
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN1(port), t);
-
- t = members;
a/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-+++ b/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-@@ -970,7 +970,6 @@ static int edma_axi_probe(struct platfor
- edma_netdev[i]->netdev_ops = _axi_netdev_ops;
- edma_netdev[i]->max_mtu
Re: [PATCH opkg 0/5] Purge packages from cache when they have incorrect checksum
Hi, Any news on this patch series? It should definitely be considered before the 20.XX branching because it fixes FS#2690 (bug related to imagebuilder), and I would like to backport it to 19.07 at some point. Thanks, Baptiste On 25-08-20, Baptiste Jonglez wrote: > From: Baptiste Jonglez > > The motivation of this patch series is to fix FS#2690. Because packages > are continuously rebuilt, the ImageBuilder ends up with old packages in > its cache, and fails because checksums don't match with the new package > index from the download server. > > The approach to solve this problem is the following. Before using a package > from the cache, verify its size and checksum against the package index, and > delete the package from the cache if they don't match. The install process > will then proceed to download the "fixed" package as usual. > > The main patch is "download: purge cached packages that have incorrect > checksum". The other ones are either cleanup or refactoring to prepare > for the main change. > > Baptiste Jonglez (5): > download: remove compatibility with old cache naming scheme > libopkg: factor out checksum and size verification > download: factor out the logic for building cache filenames > download: purge cached packages that have incorrect checksum > opkg_verify_integrity: better logging and error conditions > > libopkg/opkg_download.c | 123 > libopkg/opkg_download.h | 1 + > libopkg/opkg_install.c | 76 +++-- > 3 files changed, 108 insertions(+), 92 deletions(-) > > -- > 2.27.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
From: Baptiste Jonglez
This change has been causing several issues on ipq40xx devices, including:
- VLAN tagging no longer works correctly:
https://bugs.openwrt.org/index.php?do=details_id=3239
- poor performance with tagged VLANs:
https://bugs.openwrt.org/index.php?do=details_id=3457
See also
https://forum.openwrt.org/t/vlan-tagging-on-ipq40xx-gl-b1300-no-longer-works/69569
There are have been discussions on ways to fix the issue in the links
above (including switching to DSA), but nothing that can realistically
be introduced in the 19.07 branch.
This reverts commit 8c191712558ce94 ("ipq40xx: fix ethernet vlan
double tagging")
Note that it's not a clean revert because this patch was touched in
148d59c67edd5 ("kernel: update kernel 4.14 to version 4.14.193") even
though the semantic of the patch was left unchanged.
Fixes: FS#3239
Fixes: FS#3457
---
.../716-essedma-vlan-double-tag.patch | 128 --
1 file changed, 128 deletions(-)
delete mode 100644
target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
diff --git
a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
b/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
deleted file mode 100644
index e268351273..00
--- a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-From: Sven Eckelmann
-Date: Wed, 8 Feb 2017 16:26:00 +0100
-Subject: [PATCH] ipq40xx: Fix ar40xx port separation
-
-It is currently not possible to submit (or receive) VLAN tagged frames over
-the ar40xx PHY switch and the edma ethernet device.
-
-This can be worked around by disabling enable_vlan. The separation of the
-eth0 and eth1 ports is then done by the vlan_tag information from the
-device tree. But the ar40xx PHY switch then also has to parse the word3
-port bitmap (word3) from the TDP when data was received from the CPU port
-(0).
-
-IssueID: #2857
-
-Forwarded: no
- The ar40xx.c change was forwarded to Xiaofei Shen
- (QCA). But John Crispin will rewrite the driver anyway and we have to check
- later if this change is required in his driver too.
- drivers/net/phy/ar40xx.c | 6 +-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
a/drivers/net/phy/ar40xx.c
-+++ b/drivers/net/phy/ar40xx.c
-@@ -1200,7 +1200,11 @@ ar40xx_init_port(struct ar40xx_priv *pri
- ar40xx_rmw(priv, AR40XX_REG_PORT_STATUS(port),
- AR40XX_PORT_AUTO_LINK_EN, 0);
-
-- ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-+ /* CPU port is setting headers to limit output ports */
-+ if (port == 0)
-+ ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0x8);
-+ else
-+ ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), 0);
-
-@@ -1243,6 +1247,10 @@ ar40xx_init_globals(struct ar40xx_priv *
- t = (AR40XX_PORT0_FC_THRESH_ON_DFLT << 16) |
- AR40XX_PORT0_FC_THRESH_OFF_DFLT;
- ar40xx_write(priv, AR40XX_REG_PORT_FLOWCTRL_THRESH(0), t);
-+
-+ /* set service tag to 802.1q */
-+ t = ETH_P_8021Q | AR40XX_ESS_SERVICE_TAG_STAG;
-+ ar40xx_write(priv, AR40XX_ESS_SERVICE_TAG, t);
- }
-
- static void
-@@ -1568,7 +1576,11 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- u32 pvid = priv->vlan_id[priv->pvid[port]];
-
- if (priv->vlan) {
-- egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
-+ if (priv->vlan_tagged & BIT(port))
-+ egress = AR40XX_PORT_VLAN1_OUT_MODE_TAG;
-+ else
-+ egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
-+
- ingress = AR40XX_IN_SECURE;
- } else {
- egress = AR40XX_PORT_VLAN1_OUT_MODE_UNTOUCH;
-@@ -1579,8 +1591,17 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- t |= pvid << AR40XX_PORT_VLAN0_DEF_CVID_S;
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), t);
-
-- t = AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
-- t |= egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+ t = egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+
-+ /* set CPU port to core port */
-+ if (port == 0)
-+ t |= AR40XX_PORT_VLAN1_CORE_PORT;
-+
-+ if (priv->vlan_tagged & BIT(port))
-+ t |= AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
-+ else
-+ t |= AR40XX_PORT_VLAN1_PORT_TLS_MODE;
-+
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN1(port), t);
-
- t = members;
a/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-+++ b/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-@@ -970,7 +970,6 @@ static int edma_axi_probe(struct platfor
- edma_netdev[i]->netdev_ops = _axi_netdev_ops;
- edma_netdev[i]->max_mtu = 9000;
- edma_netdev[i]->features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM
--| NETIF_F_HW_VLAN_CTAG_TX
Re: SAD DNS cache poisoning attack
On 15-11-20, Baptiste Jonglez wrote: > There are two solutions to fix/workaround the problem: > > 1) randomize ICMP rate limiting (done in upstream kernel, there are >already OpenWrt patches to update it) I just checked, here are stable kernel versions containing the fix: - 4.9.241 - 4.14.203 - 4.19.153 - 5.4.73 And here are our current kernel versions: - 18.06: 4.9.243 and 4.14.206 - 19.07: 4.14.202 - master: 5.4.75 So, only 19.07 needs a kernel bump (which is already in progress), and then the fix can go in new stable releases. > 2) don't send these ICMP messages on WAN for closed ports (change the >default rule to DROP instead of REJECT, at least for UDP) For the record, to do this, the input option of the WAN zone needs to be changed to "DROP" in /etc/config/firewall: config zone option name wan ... option inputDROP ... and then call "/etc/init.d/firewall reload". To automate the change (warning: this will remove all comments in your firewall configuration, and it assumes WAN is the last zone): uci get firewall.@zone[-1].name # Check that it's indeed "wan" uci set firewall.@zone[-1].input=DROP uci commit firewall /etc/init.d/firewall reload signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
SAD DNS cache poisoning attack
Hi, There is a new generic cache poisoning attack for DNS: https://www.saddns.net/ It's a bit tricky, but the general idea is that an attacker can guess the ephemeral port used by a DNS resolver make a DNS query (that's dnsmasq in our case). The attacker then "just" has to guess the transaction ID which is only 16 bits. So, it's not trivial to actually exploit this problem to do cache poisoning, but it's definitely made a lot easier. The attack is relying on ICMP port unreachable messages being sent by the kernel when hitting an unused UDP port. The problem is how these messages are rate-limited by the kernel. From a quick look, OpenWrt is vulnerable because firewall3 has a "REJECT" firewall rule for WAN that generates ICMP unreachable messages. There are two solutions to fix/workaround the problem: 1) randomize ICMP rate limiting (done in upstream kernel, there are already OpenWrt patches to update it) 2) don't send these ICMP messages on WAN for closed ports (change the default rule to DROP instead of REJECT, at least for UDP) Solution 1) should go in stable releases, and we can suggest how to apply solution 2) on running systems to mitigate the issue for people that can't upgrade. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming 19.07.4 and 18.07.9 stable releases
On 11-11-20, Hauke Mehrtens wrote: > Hi, > > Currently 18.06 looks good for me and I would really like to do the final > release and call it then officially end of life. > > I would wait for the build bot results and then do it at the weekend. Yes, I fully agree, it's ready. Looking at buildbot, only layerscape/armv8_64b fails to build, but it seems to have been broken for a long time. I have updated the release notes at https://openwrt.org/releases/18.06/notes-18.06.9 > Should we also do an other 19.07 release now? I agree with Adrian, this ath79 switch driver issue was a long-standing issue and it's very good news that it's fixed. However, there were 3 regressions identified in 19.07.4, one has been fixed but two of them are still there: https://openwrt.org/releases/19.07/notes-19.07.4#regressions For the VLAN tagging issue, I think the offending commit needs to be reverted. For the ramips stability issue (frequent device reboot on several different models), does anybody have an idea? Maybe a kernel issue? Or could it be the same issue as FS#3332 that could cause crashes? Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k-ct all hash values are different?
Hi, All versions of the firmware are mirrored here http://sources.openwrt.org/ It's just that the build system somehow fails to fallback to this mirror like it does for regular downloads (in other words: it's a bug) Ben, could you re-upload all versions so that older builds can still work? This should work: wget -r --accept-regex "/QCA*" "http://sources.openwrt.org/; Thanks, Baptiste On 08-11-20, Ben Greear wrote: > I have uploaded latest, please see if this works. > > greearb@ww2 downloads]$ ~/bin/fw_lede.bash > 988x > H988XFC=398e4380e7e55105f3da0f78af29d1e437404ed3a82597aa4b6daaa7dce1a38e > firmware-2-ct-full-community-22.bin.lede.022 > H988XFCH=990d9cbf79dd81f141257a289f89808bd7726406c9ed845a7e49e5167002ffde > firmware-2-ct-full-htt-mgt-community-22.bin.lede.022 > /home/greearb/candela_html/downloads > 9887 > H9887FC=a526cb44560da569781e10bf608194b1eff29b250e9887dba6d4d9a15c921c1e > firmware-2-ct-full-community-22.bin.lede.022 > H9887FCH=0b60fc558b773e9cbd5c2df903c894a030872fdb96390b0cca4b23b7fc7b881f > firmware-2-ct-full-htt-mgt-community-22.bin.lede.022 > /home/greearb/candela_html/downloads > 9980 > H9980FC=578ad67976b61a393eb820a05e8eae70ec95f6b803bedbe952b8ff573eb09abe > firmware-5-ct-full-community-12.bin-lede.022 > H9980FCH=8ea5c9f27c048796d406706a9c8471cd070f5aeb768622bb334a04853d557a4d > firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 > H9980CH=7b0b7545114e8dc0f2c70dc8a43a5a48d84d37f2a4673977a692c5f3361445c6 > firmware-5-ct-htt-mgt-community-12.bin-lede.022 > H9980FHQ=267b4f435cf10eeefb9f7ee1bd574fd8ec6b4d8cfc007d7f8c95852d0332 > firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 > /home/greearb/candela_html/downloads > 9984 > H9984FC=7bfe5bf7c38532fa57db62ebc56ec625583928d5d4736475d5dec4d4ae031154 > firmware-5-ct-full-community-12.bin-lede.022 > H9984FCH=672be40c4d987d7e8e309341262a37cda7baf925416d1dc651284b6d2bd30969 > firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 > H9984CH=a24e887f13aca4358ab2b6a42a7212d066e4d19e29b00bb26f9681b1dc8d0eb0 > firmware-5-ct-htt-mgt-community-12.bin-lede.022 > H9984FHQ=dbdfd3fdf8c3b43b7aa1b487c5269169845c221cb8dfaad1a0a133951482e221 > firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 > /home/greearb/candela_html/downloads > 4019 > H4019FC=503956d9bf09d603e4cf36ac080fa5b5a22032166204e3c15ae898647bc50df3 > firmware-5-ct-full-community-12.bin-lede.022 > H4019FCH=591bf9ed00fb540d7ba034453f17696e8dd91a4b7d81f7cc1ec41f447fa74831 > firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 > H4019CH=06e58a283ff90d021ff7cb58684cbf39750bd71cf91c56b32add64253133929c > firmware-5-ct-htt-mgt-community-12.bin-lede.022 > H4019FHQ=16c4bcadc97425428773826bb1e72005508a2535e0c54954f4d852a744abb298 > firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 > /home/greearb/candela_html/downloads > 9888 > H9888FC=82ff5afcf0c9dcdb03b0b40c6eddc81e11b18e4f522f681935b5ec42537972ee > firmware-5-ct-full-community-12.bin-lede.022 > H9888FCH=1a741f2cf43fbea24ed831b4e76cbb114b525d1ee9b917ce916cbcc42f92 > firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 > H9888CH=34bf07912a2f3fce4a5887c690848bb06d339bd1c86541b0b57b9c45eccc88e4 > firmware-5-ct-htt-mgt-community-12.bin-lede.022 > H9888FHQ=983deaa2bf71b48a48fde534b8c325f7ec0ecaf9a76be43ca36b4e52614b3e55 > firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 > /home/greearb/candela_html/downloads > > Thanks, > Ben > > On 11/7/20 1:40 PM, Nick wrote: > > It is the firmware that is broken and just contains 0s. > > > > On 11/7/20 6:54 PM, Nick wrote: > > > I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573 > > > Not sure why the hash is suddenly different for all firmware files? > > > > > > ___ > > > 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 > > > > > -- > 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 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: ar8216: make switch register access atomic
Hi,
Thanks a lot for fixing this!
Can you backport it to openwrt-19.07? ath79 is also affected there.
Regards,
Baptiste
On 21-09-20, Chuanhong Guo wrote:
> reg accesses on integrated ar8229 sometimes fails. As a result, phy read
> got incorrect port status and wan link goes down and up mysteriously.
> After comparing ar8216 with the old driver, these local_irq_save/restore
> calls are the only meaningful differences I could find and it does fix
> the issue.
> The same changes were added in svn r26856 by Gabor Juhos:
> ar71xx: ag71xx: make switch register access atomic
>
> As I can't find the underlying problem either, this hack is broght
> back to fix the unstable link issue.
> This hack is only suitable for ath79 mdio and may easily break the
> driver on other platform. Limit it to ath79-only as a target patch.
>
> Fixes: FS#2216
> Fixes: FS#3226
> Signed-off-by: Chuanhong Guo
> ---
> .../930-ar8216-make-reg-access-atomic.patch | 61 +++
> 1 file changed, 61 insertions(+)
> create mode 100644
> target/linux/ath79/patches-5.4/930-ar8216-make-reg-access-atomic.patch
>
> diff --git
> a/target/linux/ath79/patches-5.4/930-ar8216-make-reg-access-atomic.patch
> b/target/linux/ath79/patches-5.4/930-ar8216-make-reg-access-atomic.patch
> new file mode 100644
> index 00..42f3305195
> --- /dev/null
> +++ b/target/linux/ath79/patches-5.4/930-ar8216-make-reg-access-atomic.patch
> @@ -0,0 +1,61 @@
> +From b3797d1a92afe97c173b00fdb7824cedba24eef0 Mon Sep 17 00:00:00 2001
> +From: Chuanhong Guo
> +Date: Sun, 20 Sep 2020 01:00:45 +0800
> +Subject: [PATCH] ath79: ar8216: make switch register access atomic
> +
> +due to some unknown reason these register accesses sometimes fail
> +on the integrated switch without this patch.
> +
> +THIS ONLY WORKS ON ATH79 AND MAY BREAK THE DRIVER ON OTHER PLATFORMS!
> +The mdio bus on ath79 works in polling mode and doesn't rely on
> +any interrupt. This patch breaks the driver on any mdio master
> +with interrupts used.
> +
> +---
> +--- a/drivers/net/phy/ar8216.c
> b/drivers/net/phy/ar8216.c
> +@@ -253,12 +253,14 @@ ar8xxx_mii_write32(struct ar8xxx_priv *p
> + u32
> + ar8xxx_read(struct ar8xxx_priv *priv, int reg)
> + {
> ++unsigned long flags;
> + struct mii_bus *bus = priv->mii_bus;
> + u16 r1, r2, page;
> + u32 val;
> +
> + split_addr((u32) reg, , , );
> +
> ++local_irq_save(flags);
> + mutex_lock(>mdio_lock);
> +
> + bus->write(bus, 0x18, 0, page);
> +@@ -266,6 +268,7 @@ ar8xxx_read(struct ar8xxx_priv *priv, in
> + val = ar8xxx_mii_read32(priv, 0x10 | r2, r1);
> +
> + mutex_unlock(>mdio_lock);
> ++local_irq_restore(flags);
> +
> + return val;
> + }
> +@@ -273,11 +276,13 @@ ar8xxx_read(struct ar8xxx_priv *priv, in
> + void
> + ar8xxx_write(struct ar8xxx_priv *priv, int reg, u32 val)
> + {
> ++unsigned long flags;
> + struct mii_bus *bus = priv->mii_bus;
> + u16 r1, r2, page;
> +
> + split_addr((u32) reg, , , );
> +
> ++local_irq_save(flags);
> + mutex_lock(>mdio_lock);
> +
> + bus->write(bus, 0x18, 0, page);
> +@@ -285,6 +290,7 @@ ar8xxx_write(struct ar8xxx_priv *priv, i
> + ar8xxx_mii_write32(priv, 0x10 | r2, r1, val);
> +
> + mutex_unlock(>mdio_lock);
> ++local_irq_restore(flags);
> + }
> +
> + u32
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 18.06] ar71xx: mikrotik: bypass id check in __rb_get_wlan_data()
From: Thibaut VARÈNE
The id parameter in __rb_get_wlan_data() was incorrectly used on the
assumption that id "0" would always be tied to ath9k with RLE encoding
and positive id (in fact, only id "1" was valid) would always be tied to
("external") ath10k with LZO encoding.
Newer hardware revisions of supported devices prove this assumption to
be invalid, with ath9k caldata being now wrapped in MAGIC_ERD and LZO
compressed, so disable this check to allow newer hardware to correctly
decode caldata for ath9k.
Note: this patch assumes that ath9k caldata is never stored with the new
"LZOR" encoding scheme found on some ath10k devices.
Signed-off-by: Thibaut VARÈNE
(cherry picked from commit 1c6990fe6d198718850b6a37998416cac69f6f53)
[keep publishing ath10k caldata in sysfs: it's the way it's done on 18.06]
Signed-off-by: Baptiste Jonglez
Tested-by: Baptiste Jonglez [Mikrotik RB941-2nD r3]
---
target/linux/ar71xx/files/arch/mips/ath79/routerboot.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/routerboot.c
b/target/linux/ar71xx/files/arch/mips/ath79/routerboot.c
index 76776e1d84..945894f823 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/routerboot.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/routerboot.c
@@ -206,10 +206,7 @@ __rb_get_wlan_data(u16 id)
u8 *erd_data;
u16 erd_len;
- if (id == 0)
- goto err_free;
-
- err = routerboot_find_tag(tag, tag_len, id,
+ err = routerboot_find_tag(tag, tag_len, 0x1,
_data, _len);
if (err) {
pr_err("no ERD data found for id %u\n", id);
@@ -224,9 +221,6 @@ __rb_get_wlan_data(u16 id)
goto err_free;
}
} else {
- if (id != 0)
- goto err_free;
-
err = rle_decode((char *) tag, tag_len, buf, RB_ART_SIZE,
_done, _done);
if (err) {
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Regressions in 19.07.4
Hi, FYI, there have been several regressions reported in 19.07.4: https://openwrt.org/releases/19.07/notes-19.07.4#regressions The third one (instability/reboot on ramips) might be a kernel issue, devices from different ramips subtargets are affected. Other than that, feedback has been positive: https://forum.openwrt.org/t/openwrt-19-07-4-service-release/73829 Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
HTTPS performance issue with opkg (Was: [PATCH 3/3] build: switch VERSION_REPO to HTTPS)
On 27-08-20, Paul Spooren wrote: > The variable VERSION_REPO is used by opkg to download package(list)s. > Now that the default installation support encrypted HTTP opkg should > make use of it. I wonder what is the performance impact of this? Opkg forks a new wget process to download each package, so the HTTPS connection is never reused. Running a simple "time make image PROFILE=mikrotik_routerboard-921gs-5hpacd-15s" with the ath79/mikrotik imagebuilder results in a 50% increase of running time: - with HTTPS: 32 seconds - with HTTP: 22 seconds (timing for the second run is shown, and dl/ is cleaned up before each run) The overhead might be even more significant on a device, and the download server probably sees more load from the large number of key exchange. Anybody got any figures? With HTTPS, opkg would really need connection reuse. I don't think the current situation is acceptable for a stable release, if only to avoid high load on the download server. Baptiste > Suggested-by: Petr Štetiar > Suggested-by: Baptiste Jonglez > Signed-off-by: Paul Spooren > --- > include/version.mk | 2 +- > package/base-files/image-config.in | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/version.mk b/include/version.mk > index 7d3c1ad640..b7f42e13bb 100644 > --- a/include/version.mk > +++ b/include/version.mk > @@ -32,7 +32,7 @@ VERSION_CODE:=$(call qstrip,$(CONFIG_VERSION_CODE)) > VERSION_CODE:=$(if $(VERSION_CODE),$(VERSION_CODE),$(REVISION)) > > VERSION_REPO:=$(call qstrip,$(CONFIG_VERSION_REPO)) > -VERSION_REPO:=$(if > $(VERSION_REPO),$(VERSION_REPO),http://downloads.openwrt.org/snapshots) > +VERSION_REPO:=$(if > $(VERSION_REPO),$(VERSION_REPO),https://downloads.openwrt.org/snapshots) > > VERSION_DIST:=$(call qstrip,$(CONFIG_VERSION_DIST)) > VERSION_DIST:=$(if $(VERSION_DIST),$(VERSION_DIST),OpenWrt) > diff --git a/package/base-files/image-config.in > b/package/base-files/image-config.in > index 4bace77db0..bfa3055cc8 100644 > --- a/package/base-files/image-config.in > +++ b/package/base-files/image-config.in > @@ -183,7 +183,7 @@ if VERSIONOPT > config VERSION_REPO > string > prompt "Release repository" > - default "http://downloads.openwrt.org/snapshots; > + default "https://downloads.openwrt.org/snapshots; > help > This is the repository address embedded in the image, > it defaults > to the trunk snapshot repo; the url may contain the > following placeholders: signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] imagebuilder: add package signature verification
Hi, Thanks for the patch, it looks good but comments below: On 25-08-20, Paul Spooren wrote: > The ImageBuilder downloads pre-built packages and adds them to images. > This process uses `opkg` which has the capability to verify package list > signatures, as enabled per default on running OpenWrt devices. > > Until now this was disabled for ImageBuilders because neither the OPKG > keys nor the `opkg-add` script was present during first packagelist > update. > > To harden the ImageBuilder against *drive-by-download-attacks* both keys > and verification script are added to the ImageBuilder allowing OPKG to > verify downloaded package indices. > > This commit adds `opkg-add` to the IB scripts folder, as it is just a > shell script. The keys folder is added to IBs TOPDIR to have an obvious > place for users to store their own keys. The `option check_signature` is > appended to the repositories.conf file. With this patch, the imagebuilder gives an error while trying to fetch a signature for the local package index: Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/base/Packages.gz Updated list of available packages in /tmp/openwrt-imagebuilder-ath79-generic.Linux-x86_64/build_dir/target-mips_24kc_musl/root-ath79/../../../../../tmp/openwrt-imagebuilder-ath79-generic.Linux-x86_64/dl/openwrt_base Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/base/Packages.sig Signature check passed. Downloading file:packages/Packages Updated list of available packages in /tmp/openwrt-imagebuilder-ath79-generic.Linux-x86_64/build_dir/target-mips_24kc_musl/root-ath79/../../../../../tmp/openwrt-imagebuilder-ath79-generic.Linux-x86_64/dl/imagebuilder Downloading file:packages/Packages.sig Signature file download failed. Remove wrong Signature file. Collected errors: * copy_file: packages/Packages.sig: No such file or directory. * file_copy: Failed to copy file packages/Packages.sig to /tmp/openwrt-imagebuilder-ath79-generic.Linux-x86_64/build_dir/target-mips_24kc_musl/root-ath79/../../../../../tmp/openwrt-imagebuilder-ath79-generic.Linux-x86_64/dl/imagebuilder.sig. However, it works fine in the end: I think packages coming from a local repository are special-cased when it comes to verifying signature. It's not possible to sign this package file, because it is generated locally by the imagebuilder and we don't have access to any usign private key. Signing a locally-generated file doesn't make much sense anyway. So, it probably needs to be fixed in opkg. > All of the above only happens if the Buildbot runs with the > SIGNED_PACKAGES option. As far as I can tell, you don't actually rely on the package index signatures that are generated on the host? You are using the usign keys from the openwrt-keyring package as well as the locally-generated build key, both of which are enabled by SIGNED_PACKAGES. This is far from trivial and should be added to the commit message or as a comment. I'm asking because my first idea was to depend on SIGNATURE_CHECK. It seems more logical but it's actually not relevant: SIGNATURE_CHECK enables signature checking in the target device opkg configuration, so it's completely unrelated to what should happen in the imagebuilder. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH opkg 0/5] Purge packages from cache when they have incorrect checksum
Hi, Any feedback on this patch series? It fixes this annoying bug in the imagebuilder: https://bugs.openwrt.org/index.php?do=details_id=2690 Since the changes are somewhat significant, I would like some exposure in master for a few weeks/months before it can be backported to 18.06 and 19.07. Thanks, Baptiste On 25-08-20, Baptiste Jonglez wrote: > From: Baptiste Jonglez > > The motivation of this patch series is to fix FS#2690. Because packages > are continuously rebuilt, the ImageBuilder ends up with old packages in > its cache, and fails because checksums don't match with the new package > index from the download server. > > The approach to solve this problem is the following. Before using a package > from the cache, verify its size and checksum against the package index, and > delete the package from the cache if they don't match. The install process > will then proceed to download the "fixed" package as usual. > > The main patch is "download: purge cached packages that have incorrect > checksum". The other ones are either cleanup or refactoring to prepare > for the main change. > > Baptiste Jonglez (5): > download: remove compatibility with old cache naming scheme > libopkg: factor out checksum and size verification > download: factor out the logic for building cache filenames > download: purge cached packages that have incorrect checksum > opkg_verify_integrity: better logging and error conditions > > libopkg/opkg_download.c | 123 > libopkg/opkg_download.h | 1 + > libopkg/opkg_install.c | 76 +++-- > 3 files changed, 108 insertions(+), 92 deletions(-) signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH opkg] libopkg: fix md5sum calculation
From: Alexander Ryzhov
This regression prevents MD5 checksums from being checked. Packages are
still installed, but this raises several issues:
- if only MD5 checksums are provided in the package list, it is trivial
for an attacker to modify the content of a package, since checksum
verification is bypassed. If both MD5 and SHA256 checksums are
provided, then SHA256 is correctly verified and the attack is not
possible.
- future efforts to harden checksum verification would prevent package
installation.
Note that OpenWrt has switched to SHA256 for all its packages several
years ago. As a result, this bug does not affect OpenWrt packages from the
official package feeds.
However, custom package repositories that only use MD5 are affected.
Initially submitted at https://github.com/openwrt/openwrt/pull/3087
Fixes: 33f7b80aa325 ("libopkg: drop custom md5 implementation,
unconditionally enable sha256 support")
Signed-off-by: Alexander Ryzhov
[Add commit description]
Signed-off-by: Baptiste Jonglez
---
libopkg/file_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libopkg/file_util.c b/libopkg/file_util.c
index 3a1761e..8e698cc 100644
--- a/libopkg/file_util.c
+++ b/libopkg/file_util.c
@@ -153,7 +153,7 @@ char *file_md5sum_alloc(const char *file_name)
len = md5sum(file_name, md5sum_bin);
- if (len) {
+ if (len < 0) {
opkg_msg(ERROR, "Could't compute md5sum for %s.\n", file_name);
return NULL;
}
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 19.07.4 service release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, The OpenWrt community is proud to announce the newest service release in the 19.07 stable series: OpenWrt 19.07.4. It focuses on stability and device support. Selected highlights of this service release are: * fix regression in libubox causing some services to fail to start * fix regression in the LuCI web interface: the menu was not showing newly installed opkg packages * fix a bug in musl that could crash applications in rare circumstances. Fastd, a VPN daemon, seems to be particularly affected by this bug * fix support for several devices that failed to boot * many other fixes and improvements to device support * update core components (linux kernel, mac80211, ath10k-ct-firmware) Full release notes and upgrade instructions are available at https://openwrt.org/releases/19.07/notes-19.07.4 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/19.07/notes-19.07.4#regressions For a very detailed list of all changes since 19.07.3, refer to https://openwrt.org/releases/19.07/changelog-19.07.4 We now have a forum topic where you can report your upgrading experience: https://forum.openwrt.org/t/openwrt-19-07-4-service-release/73829 - --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact - --- For latest information about the 19.07 series, refer to the wiki at: https://openwrt.org/releases/19.07/ To download a OpenWrt 19.07.4 firmware image for your device, head to the Table of Hardware: https://openwrt.org/toh/start Or navigate directly in the list of firmware images: https://downloads.openwrt.org/releases/19.07.4/targets/ As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEjVflzZuxNlVFbt5QvgHsIqBOLkYFAl9Zyn0ACgkQvgHsIqBO LkZQ/g/+LwZqKZuw/9S64ZpLT5ZDJcYnqv9DkoEVlg85YteGmZOMs+M/4BTUuxRc 4wl+nJFmMbXrV8HRG97tHa3ZCVhjCS/yka/EATdn2ixLqe2VSffJYdq9wRmWk3bN SlDT0ihmWEk5ZM1OW8KKMAn4l3Z0rR1vmUI6il6ft69AfBpxJClgD6pW2+aMn3pt YsTu+RY1VquvKEasLR8kZ5TRvxflbxWKHe/SITIWpEukdiNXQp3DBkMcdKrc76jX rJY78N/kXzlZRBywSNWhNjAl3hZrYMRzy4PqF84lwSXIRVZG8QcUdAqWK496oqvj FSm8LuqsdLBjJ5EeX1BnroYtKAEWkNqx/kfe8IOd+BwWUE3KsaoPlkaXmXk4qCaZ wNS1dD6oHHIE2BFYDQ/s+hlVhK13Z7IuyeMM73W1bOeuRygXMJ/W61WOfeSYFTZT PDZl4imgk/iEO4qSGj/6XXcYFMbI7+3/9rkdmxz1JHQT3EIDqgePgt6KhlHSvNbn vY8iihd1qsVC8qArdQmpWN1NQV/fiW4B9tg6nPfaeM8ymE4Hpo9EaKv+3PxmMwhX iZj8MJw1eLpoAOiLfCIPyj6yBk3sCqC0OJNLlFtZv4fLhAafv6TRyoPH34VUwYJ/ o1AJUpx0U9EMbh/wOuhJd5NzPqGle41KrgHLltbSZBHa6A+X/vU= =V3bj -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming 19.07.4 and 18.07.9 stable releases
Hi, Images for 19.07.4 have been built. Thomas, could you update the ToH accordingly? When the download page is also updated, I will announce it, probably tomorrow. 18.06.9 will follow soon. Thanks, Baptiste On 30-07-20, Baptiste Jonglez wrote: > Hi, > > New point releases for 19.07 and 18.06 are starting to be overdue, and I > would like to help 19.07.4 and 18.06.9 get released somewhere around > mid-August. > > The main motivation are fixes for a libubox regression and for the musl > synchronisation bug, as well as a LuCI regression (see "release goals" > below). But there are many other fixes, mostly device-related, that also > motivate these new point releases. If you have more fixes to backport, > please consider doing so soon, especially for 18.06.9 which will likely be > the last release for 18.06. > > > The following links can be useful to track changes for 19.07: > > - release goals for 19.07.4 (mostly high-level): > https://openwrt.org/docs/guide-developer/releases/goals/19.07.4 > > - current release notes for 19.07.4: > https://openwrt.org/releases/19.07/notes-19.07.4 > > - pending patches on patchwork for 19.07: > https://patchwork.ozlabs.org/project/openwrt/list/?q=19.07 > > - pending patches on github for 19.07: > https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F19.07 > > - open bug reports for 19.07: > https://bugs.openwrt.org/index.php?do=tasklist=2%5B0%5D=open%5B%5D=10=severity=desc > > > And for 18.06 (overall, things are obviously more quiet): > > - current release notes for 18.06.9: > https://openwrt.org/releases/18.06/notes-18.06.9 > > - pending patches on patchwork for 18.06: > https://patchwork.ozlabs.org/project/openwrt/list/?q=18.06 > > - pending patches on github for 18.06: > https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F18.06 > > - open bug reports for 18.06: > https://bugs.openwrt.org/index.php?do=tasklist=2%5B0%5D=open%5B%5D=8=severity=desc > > > While everything is mostly ready, the actual release will need somebody > with the rights to "push the button": > https://openwrt.org/docs/guide-developer/releases/making-service-release > > Regards, > Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07 v2 6/6] ath10k-ct-firmware: update firmware images
Tested-by: Baptiste Jonglez [QCA9886, QCA9887]
On 03-09-20, Baptiste Jonglez wrote:
> From: Michael Yartys
>
> Not a large change from last time, but should fix at least one rare wave-2
> crash.
>
> Tested on Netgear R7800.
>
> Signed-off-by: Michael Yartys
> Signed-off-by: Álvaro Fernández Rojas
> (cherry picked from commit 91aab77bf1ce91b0e60e720eb147c94a02c1f2fd)
> [adapt variables and package names]
> [remove changes to non-full htt-mgt variants because we did not backport
> a882bfce052e ("ath10k-ct-firmware: add htt-mgt variants")]
> Signed-off-by: Baptiste Jonglez
> ---
> package/firmware/ath10k-ct-firmware/Makefile | 42 ++--
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/package/firmware/ath10k-ct-firmware/Makefile
> b/package/firmware/ath10k-ct-firmware/Makefile
> index 6fe8ea6d3b..12fb031f8f 100644
> --- a/package/firmware/ath10k-ct-firmware/Makefile
> +++ b/package/firmware/ath10k-ct-firmware/Makefile
> @@ -1,7 +1,7 @@
> include $(TOPDIR)/rules.mk
>
> PKG_NAME:=ath10k-ct-firmware
> -PKG_VERSION:=2020-04-24
> +PKG_VERSION:=2020-07-02
> PKG_RELEASE:=1
>
> include $(INCLUDE_DIR)/package.mk
> @@ -88,14 +88,14 @@ define Download/ct-firmware-htt
>URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
> endef
>
> -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
> +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
> define Download/ath10k-firmware-qca988x-ct
>$(call Download/ct-firmware,QCA988X,)
>HASH:=8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126
> endef
> $(eval $(call Download,ath10k-firmware-qca988x-ct))
>
> -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
> +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019
> define Download/ath10k-firmware-qca988x-ct-htt
>$(call Download/ct-firmware-htt,QCA988X,)
>HASH:=a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7
> @@ -103,14 +103,14 @@ endef
> $(eval $(call Download,ath10k-firmware-qca988x-ct-htt))
>
>
> -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
> +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
> define Download/ath10k-firmware-qca9887-ct
>$(call Download/ct-firmware,QCA9887,ath10k-9887)
>HASH:=459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b
> endef
> $(eval $(call Download,ath10k-firmware-qca9887-ct))
>
> -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
> +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019
> define Download/ath10k-firmware-qca9887-ct-htt
>$(call Download/ct-firmware-htt,QCA9887,ath10k-9887)
>HASH:=fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098
> @@ -118,62 +118,62 @@ endef
> $(eval $(call Download,ath10k-firmware-qca9887-ct-htt))
>
>
> -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
> +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
> define Download/ath10k-firmware-qca99x0-ct
>$(call Download/ct-firmware,QCA99X0,ath10k-10-4b)
> - HASH:=cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42
> + HASH:=7dc934f934bc4973c9273a4f22cfead8e26ec6f579647af31b718a860eca0a4b
> endef
> $(eval $(call Download,ath10k-firmware-qca99x0-ct))
>
> -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
> +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019
> define Download/ath10k-firmware-qca99x0-ct-htt
>$(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b)
> - HASH:=e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc
> + HASH:=71a27b245a382fe009938d2826d5c97a90dceb10ddf638325268df91837ea302
> endef
> $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt))
>
>
> -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
> +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
> define Download/ath10k-firmware-qca9984-ct
>$(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b)
> - HASH:=a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1
> + HASH:=32d13f432691fe759ded7d027052e925233adb436cd8f729f85ec3d19ccd1dfd
> endef
> $(eval $(call Download,ath10k-firmware-qca9984-ct))
>
> -QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
> +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019
> define Download/ath10k-firmware-qca9984-ct-htt
>$(call Download/ct-firmware-htt,QCA9984,ath1
Re: Upcoming 19.07.4 and 18.07.9 stable releases
On 03-09-20, Nick Lowe wrote: > It seems there is an important ath10k patch included in the 4.4.235, > 4.9.235, 4.14.196 and 4.19.143, 5.4.62 LTS kernels that is applicable > for OpenWRT users who are not using an up to date CT driver with Wave > 2 QCA 802.11ac generation hardware, it is already merged for CT. Do you mean that it affects both ath10k and ath10k-ct in the 19.07 branch? > It resolves a PCIe hang seen due to the DMA burst size value meaning > different things between Wave 1 and Wave 2 hardware. > > The issue resolved is that a value of 0 for the DMA burst size has a > different meaning and instruction depending on the generation. Do you have more details, references? A commit? > Cheers, > > Nick > > On Sun, Aug 30, 2020 at 1:45 PM Baptiste Jonglez > wrote: > > > > On 29-08-20, Baptiste Jonglez wrote: > > > On 28-08-20, Hauke Mehrtens wrote: > > > > Hi, > > > > > > > > I would like to do a 19.07.4 and a 18.06.9 release on Sunday or > > > > beginning of next week. > > > > > > Cool, looks good to me. > > > > > > > Is there something missing in the current branches which should get into > > > > this release? > > > > > > There's the ath10k-ct-firmware bump for 19.07: > > > https://patchwork.ozlabs.org/project/openwrt/list/?q=19.07 > > > > > > I plan to look at the LuCI issue mentioned here: > > > https://openwrt.org/docs/guide-developer/releases/goals/19.07.4 > > > > I backported a fix for the LuCI issue, the pull request needs to be merged > > before the 19.07.4 release: https://github.com/openwrt/luci/pull/4402 > > > > Thanks, > > Baptiste > > ___ > > 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 signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07 7/8] ath10k-ct-firmware: add htt-mgt variants
Hi, On 03-09-20, Adrian Schmutzler wrote: > > > These HTT firmwares are not used in default openwrt images, but they > > > could be used downstream: it does not seem wise to distribute a > > > different firmware variant under the same package name. > > > > Those compiled out features are not used by any ath10k driver as far as I > > know. > > If the driver doesn't use it, I don't see how anything else could... > > > > Its still worth testing, but I think that diet variant is probably the best > > choice. Yes, introducing that diet variant in master seems like a good idea. It will be part of the next 20.XX stable release. As Adrian also pointed out, the problem is backporting it to the 19.07 branch: it might break user expectations. > My point mainly was that it's against the idea of a stable branch to suddenly > rename firmware variants in a .4 revision. > > So, it would be better to use patches 1-4, drop the htt renames (5,7) and > then just rebase patches 6 and 8 for the 19.07 branch. I've sent a v2 with this approach, everything works fine on a QCA9886. I will try to test it a bit more on different hardware this week-end. More testing is welcome. Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07 v2 4/6] ath10k-firmware: move CT firmwares to new package
From: Álvaro Fernández Rojas Signed-off-by: Álvaro Fernández Rojas (cherry picked from commit 658e68f85c2645e0132edc6b30a9c76cc17292de) --- package/firmware/ath10k-ct-firmware/Makefile | 524 +++ package/firmware/ath10k-firmware/Makefile| 446 2 files changed, 524 insertions(+), 446 deletions(-) create mode 100644 package/firmware/ath10k-ct-firmware/Makefile diff --git a/package/firmware/ath10k-ct-firmware/Makefile b/package/firmware/ath10k-ct-firmware/Makefile new file mode 100644 index 00..79bdeeec4f --- /dev/null +++ b/package/firmware/ath10k-ct-firmware/Makefile @@ -0,0 +1,524 @@ +include $(TOPDIR)/rules.mk + +PKG_NAME:=ath10k-ct-firmware +PKG_VERSION:=2020-03-25 +PKG_RELEASE:=1 + +include $(INCLUDE_DIR)/package.mk + +ATH10K_FIRMWARE_REV:=d622d160e9f552ead68d9ae81b715422892dc2ef +ATH10K_FIRMWARE_URL:=@GITHUB/kvalo/ath10k-firmware/$(ATH10K_FIRMWARE_REV) + +QCA9887_BOARD_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca9887-board.bin +define Download/qca9887-board + FILE:=$(QCA9887_BOARD_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA9887/hw1.0 + URL_FILE:=board.bin + HASH:=cf4df099f6ee05c181f55ce17297a1d32c61d725eb96246fd315ad5587c42426 +endef +$(eval $(call Download,qca9887-board)) + +QCA988X_BOARD_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca988x-board.bin +define Download/qca988x-board + FILE:=$(QCA988X_BOARD_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA988X/hw2.0 + URL_FILE:=board.bin + HASH:=5b5b380333c2dd3b6ce67f30e2f7008f4020bf594970d3b464fd8d4a80fcd880 +endef +$(eval $(call Download,qca988x-board)) + +QCA99X0_BOARD_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca99x0-board.bin +define Download/qca99x0-board + FILE:=$(QCA99X0_BOARD_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA99X0/hw2.0 + URL_FILE:=boardData_AR900B_CUS239_5G_v2_001.bin + HASH:=3bf7561ee373b369025dcd366d276d038a97d3397ccae41ce841d98a58b30aff +endef +$(eval $(call Download,qca99x0-board)) + +QCA99X0_BOARD2_REV:=ddcec9efd245da9365c474f513a855a55f3ac7fe +QCA99X0_BOARD2_FILE:=ath10k-firmware-$(QCA99X0_BOARD2_REV)-qca99x0-board-2.bin +define Download/qca99x0-board2 + FILE:=$(QCA99X0_BOARD2_FILE) + URL:=https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA99X0/hw2.0 + URL_FILE:=board-2.bin?id=$(QCA99X0_BOARD2_REV) + HASH:=03711ac21e60ef59d3815e235eb721c0c22851b5410299411085aa6f2af45401 +endef +$(eval $(call Download,qca99x0-board2)) + +QCA9984_BOARD2_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca9984-board-2.bin +define Download/qca9984-board2 + FILE:=$(QCA9984_BOARD2_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA9984/hw1.0 + URL_FILE:=board-2.bin + HASH:=0d6d46cf0467185e3959ce3cb69e2415be6e48ab8a4bee3eb400edbe48cb9c25 +endef +$(eval $(call Download,qca9984-board2)) + +QCA4019_BOARD2_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca4019-board-2.bin +define Download/qca4019-board2 + FILE:=$(QCA4019_BOARD2_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA4019/hw1.0 + URL_FILE:=board-2.bin + HASH:=94b66aa4ddbed5110a96364d3c7b4ebcb320e3ac4e8697660b277e76077bc338 +endef +$(eval $(call Download,qca4019-board2)) + +QCA9888_BOARD2_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca9888-board-2.bin +define Download/qca9888-board2 + FILE:=$(QCA9888_BOARD2_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA9888/hw2.0 + URL_FILE:=board-2.bin + HASH:=5b871bb567f64525ca45adb88063211de472015d09e0f9aa3fa61ab71c8fdfd3 +endef +$(eval $(call Download,qca9888-board2)) + +CT_FIRMWARE_FILE = $(1)-$($(1)_FIRMWARE_FILE_CT) +CT_FIRMWARE_FILE_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_HTT) + +define Download/ct-firmware + URL:=https://www.candelatech.com/downloads/$(2) + FILE:=$(call CT_FIRMWARE_FILE,$(1)) + URL_FILE:=$($(1)_FIRMWARE_FILE_CT) +endef + +define Download/ct-firmware-htt + URL:=https://www.candelatech.com/downloads/$(2) + FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1)) + URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) +endef + +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 +define Download/ath10k-firmware-qca988x-ct + $(call Download/ct-firmware,QCA988X,) + HASH:=2f0bf766e400a4c5726e77b128eb8c141ebaa778526fe2c7c5083f3b17659dbf +endef +$(eval $(call Download,ath10k-firmware-qca988x-ct)) + +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 +define Download/ath10k-firmware-qca988x-ct-htt + $(call Download/ct-firmware-htt,QCA988X,) + HASH:=5e4285d5c6eee159a25ca14c6ce26022c32380bd7bafaedfc0c5de1510119007 +endef +$(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) + + +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 +define Download/ath10k-firmware-qca9887-ct + $(call Download/ct-firmware,QCA9887,ath10k-9887) + HASH:=4fa30e0e1972ca3b06225a731df0f93a1b73ac67fea5bf54bb55dea3bbc0da6a +endef +$(eval $(call Download,ath10k-firmware-qca9887-ct)) + +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 +define Download/ath10k-firmware-qca9887-ct-htt + $(call
[PATCH 18.06] scripts: getver.sh: Fix version when running on local 18.06 branch
From: Baptiste Jonglez
When building from a local branch based off the "openwrt-18.06" branch,
version computation is wrong, for instance:
r6907+1154-7e15e21766
The number of local commits (1154 in this case) is wrong because it is
computed against master. As a result, it wrongly counts *all* commits
since the beginning of the openwrt-18.06 branch as local commits.
The fix is to compare to the openwrt-18.06 branch instead, which gives the
expected result such as:
r8060+1-1238a22316
Signed-off-by: Baptiste Jonglez
---
scripts/getver.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/getver.sh b/scripts/getver.sh
index 9175f411db..dbd3292343 100755
--- a/scripts/getver.sh
+++ b/scripts/getver.sh
@@ -26,7 +26,7 @@ try_git() {
*)
BRANCH="$(git rev-parse --abbrev-ref HEAD)"
ORIGIN="$(git rev-parse --verify --symbolic-full-name
${BRANCH}@{u} 2>/dev/null)"
- [ -n "$ORIGIN" ] || ORIGIN="$(git rev-parse --verify
--symbolic-full-name master@{u} 2>/dev/null)"
+ [ -n "$ORIGIN" ] || ORIGIN="$(git rev-parse --verify
--symbolic-full-name openwrt-18.06@{u} 2>/dev/null)"
REV="$(git rev-list ${REBOOT}..$GET_REV | wc -l | awk '{print
$1}')"
if [ -n "$ORIGIN" ]; then
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07] scripts: getver.sh: Fix version when running on local 19.07 branch
From: Baptiste Jonglez
When building from a local branch based off the "openwrt-19.07" branch,
version computation is wrong, for instance:
r10194+1004-c53f62b111
The number of local commits (1004 in this case) is wrong because it is
computed against master. As a result, it wrongly counts *all* commits
since the beginning of the openwrt-19.07 branch as local commits.
The fix is to compare to the openwrt-19.07 branch instead, which gives the
expected result such as:
r11192+6-8b0278a17e
Signed-off-by: Baptiste Jonglez
---
scripts/getver.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/getver.sh b/scripts/getver.sh
index 9175f411db..a0063505c3 100755
--- a/scripts/getver.sh
+++ b/scripts/getver.sh
@@ -26,7 +26,7 @@ try_git() {
*)
BRANCH="$(git rev-parse --abbrev-ref HEAD)"
ORIGIN="$(git rev-parse --verify --symbolic-full-name
${BRANCH}@{u} 2>/dev/null)"
- [ -n "$ORIGIN" ] || ORIGIN="$(git rev-parse --verify
--symbolic-full-name master@{u} 2>/dev/null)"
+ [ -n "$ORIGIN" ] || ORIGIN="$(git rev-parse --verify
--symbolic-full-name openwrt-19.07@{u} 2>/dev/null)"
REV="$(git rev-list ${REBOOT}..$GET_REV | wc -l | awk '{print
$1}')"
if [ -n "$ORIGIN" ]; then
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07 v2 5/6] ath10k-ct-firmware: update firmware images
From: Álvaro Fernández Rojas
No release notes this time.
Signed-off-by: Álvaro Fernández Rojas
(cherry picked from commit 06f510df6e2aa0b1e40124bbd758672458d01482)
[adapt variables and package names because we did not backport
2e5e9b459ed5 ("ath10k-ct-firmware: rename ct-htt packages")]
Signed-off-by: Baptiste Jonglez
---
package/firmware/ath10k-ct-firmware/Makefile | 50 ++--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/package/firmware/ath10k-ct-firmware/Makefile
b/package/firmware/ath10k-ct-firmware/Makefile
index 79bdeeec4f..6fe8ea6d3b 100644
--- a/package/firmware/ath10k-ct-firmware/Makefile
+++ b/package/firmware/ath10k-ct-firmware/Makefile
@@ -1,7 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=ath10k-ct-firmware
-PKG_VERSION:=2020-03-25
+PKG_VERSION:=2020-04-24
PKG_RELEASE:=1
include $(INCLUDE_DIR)/package.mk
@@ -88,92 +88,92 @@ define Download/ct-firmware-htt
URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
endef
-QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017
+QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
define Download/ath10k-firmware-qca988x-ct
$(call Download/ct-firmware,QCA988X,)
- HASH:=2f0bf766e400a4c5726e77b128eb8c141ebaa778526fe2c7c5083f3b17659dbf
+ HASH:=8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126
endef
$(eval $(call Download,ath10k-firmware-qca988x-ct))
-QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017
+QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
define Download/ath10k-firmware-qca988x-ct-htt
$(call Download/ct-firmware-htt,QCA988X,)
- HASH:=5e4285d5c6eee159a25ca14c6ce26022c32380bd7bafaedfc0c5de1510119007
+ HASH:=a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7
endef
$(eval $(call Download,ath10k-firmware-qca988x-ct-htt))
-QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017
+QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
define Download/ath10k-firmware-qca9887-ct
$(call Download/ct-firmware,QCA9887,ath10k-9887)
- HASH:=4fa30e0e1972ca3b06225a731df0f93a1b73ac67fea5bf54bb55dea3bbc0da6a
+ HASH:=459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b
endef
$(eval $(call Download,ath10k-firmware-qca9887-ct))
-QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017
+QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
define Download/ath10k-firmware-qca9887-ct-htt
$(call Download/ct-firmware-htt,QCA9887,ath10k-9887)
- HASH:=dc681b6b1e45956e7c2e418ab05eee5c943d13e775209196d9bd931ff6493935
+ HASH:=fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098
endef
$(eval $(call Download,ath10k-firmware-qca9887-ct-htt))
-QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017
+QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
define Download/ath10k-firmware-qca99x0-ct
$(call Download/ct-firmware,QCA99X0,ath10k-10-4b)
- HASH:=289ea845d4bbae6f36b3af2a13a5eaa07097f52d10f7b7306cfc9e2dd394f889
+ HASH:=cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42
endef
$(eval $(call Download,ath10k-firmware-qca99x0-ct))
-QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017
+QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
define Download/ath10k-firmware-qca99x0-ct-htt
$(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b)
- HASH:=adedcd3d379a910bc3a5257d75f8970e11319f4cd9c1b34440d35821602a8b9c
+ HASH:=e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc
endef
$(eval $(call Download,ath10k-firmware-qca99x0-ct-htt))
-QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017
+QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
define Download/ath10k-firmware-qca9984-ct
$(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b)
- HASH:=8175be5b3946bddc042be018ff7713e67b41b59374ef4cdd183185b59274c91a
+ HASH:=a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1
endef
$(eval $(call Download,ath10k-firmware-qca9984-ct))
-QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017
+QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
define Download/ath10k-firmware-qca9984-ct-htt
$(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b)
- HASH:=eb8b894cfe0d1aaa87f130bb7fd1815ef07b951c14df8a2ceaeb780df8f640e0
+ HASH:=96060227e372b3b210badccbe6b0bd75d9a35335a7a0f2966964e9e89f66b00f
endef
$(eval $(call Download,ath10k-firmware-qca9984-ct-htt))
-QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017
+QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
define Download/ath10k-firmware-qca4019-ct
$(call Download/ct-firmware,QCA4019,ath10k-4019-10-4
[PATCH 19.07 v2 3/6] ath10k-firmware: update ath10k-ct firmware images
From: Álvaro Fernández Rojas Release notes for 017: Wave-1: * March 19, 2020: Fix problem where power-save was not enabled when going off-channel to scan. The problem was a boolean logic inversion in the chmgr code, a regression I introduced a long time ago. * March 19, 2020: When scanning only on current working channel, do not bother with disable/enable powersave. This should make an on-channel scan less obtrusive than it was previously. * March 23, 2020: Fix channel-mgr use-after-free problem that caused crashes in some cases. The crash was exacerbated by recent power-save changes. * March 23, 2020: Fix station-mode power-save related crash: backported the fix from 10.2 QCA firmware. * March 23, 2020: Attempt to better clean up power-save objects and state, especially in station mode. Release notes for 016: Wave-1 changes, some debugging code for a crash someone reported, plus: * February 28, 2020: Fix custom-tx path when sending in 0x0 for rate-code. Have tries == 0 mean one try but NO-ACK (similar to how wave-2 does it). wave-2: * Fixed some long-ago regressions related to powersave and/or multicast. Maybe fix some additional multicast and/or tx-scheduling bugs. Signed-off-by: Álvaro Fernández Rojas Acked-by: Petr Štetiar (cherry picked from commit 84f4a783c6987fd9d67c089a76e2f90b7491f446) --- package/firmware/ath10k-firmware/Makefile | 48 +++ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index af883e6f03..6eb7cf9a99 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -64,92 +64,92 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.015 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) - HASH:=a3a760d0d72707feffa496b6d2266bd9195f09806553b36420b60c0f12b8b87e + HASH:=2f0bf766e400a4c5726e77b128eb8c141ebaa778526fe2c7c5083f3b17659dbf endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 define Download/ath10k-firmware-qca988x-ct-htt $(call Download/ct-firmware-htt,QCA988X,) - HASH:=3114a54103d2b492fa1ef903769721f59953c829020d62502a1ec411ab4146d5 + HASH:=5e4285d5c6eee159a25ca14c6ce26022c32380bd7bafaedfc0c5de1510119007 endef $(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.015 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) - HASH:=71e8b76dfd7c786d2f57bb7df207dcd13a91d3b492cfbd28916f084d0d1bb5e7 + HASH:=4fa30e0e1972ca3b06225a731df0f93a1b73ac67fea5bf54bb55dea3bbc0da6a endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 define Download/ath10k-firmware-qca9887-ct-htt $(call Download/ct-firmware-htt,QCA9887,ath10k-9887) - HASH:=b085e5d2239727b72bc647a76864431b8ac48438e6a33b1d55edc468f6ff + HASH:=dc681b6b1e45956e7c2e418ab05eee5c943d13e775209196d9bd931ff6493935 endef $(eval $(call Download,ath10k-firmware-qca9887-ct-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=edebe2f6f169cdd05c81a8a78156fb3426a66f415e7946af2ae4b7310fca5fe3 + HASH:=289ea845d4bbae6f36b3af2a13a5eaa07097f52d10f7b7306cfc9e2dd394f889 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 define Download/ath10k-firmware-qca99x0-ct-htt $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) - HASH:=1ef67fb07da9082886e4dd554dfc19256e10b500faf9e4b2a5774d0238130bae + HASH:=adedcd3d379a910bc3a5257d75f8970e11319f4cd9c1b34440d35821602a8b9c endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) -
[PATCH 19.07 v2 6/6] ath10k-ct-firmware: update firmware images
From: Michael Yartys
Not a large change from last time, but should fix at least one rare wave-2
crash.
Tested on Netgear R7800.
Signed-off-by: Michael Yartys
Signed-off-by: Álvaro Fernández Rojas
(cherry picked from commit 91aab77bf1ce91b0e60e720eb147c94a02c1f2fd)
[adapt variables and package names]
[remove changes to non-full htt-mgt variants because we did not backport
a882bfce052e ("ath10k-ct-firmware: add htt-mgt variants")]
Signed-off-by: Baptiste Jonglez
---
package/firmware/ath10k-ct-firmware/Makefile | 42 ++--
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/package/firmware/ath10k-ct-firmware/Makefile
b/package/firmware/ath10k-ct-firmware/Makefile
index 6fe8ea6d3b..12fb031f8f 100644
--- a/package/firmware/ath10k-ct-firmware/Makefile
+++ b/package/firmware/ath10k-ct-firmware/Makefile
@@ -1,7 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=ath10k-ct-firmware
-PKG_VERSION:=2020-04-24
+PKG_VERSION:=2020-07-02
PKG_RELEASE:=1
include $(INCLUDE_DIR)/package.mk
@@ -88,14 +88,14 @@ define Download/ct-firmware-htt
URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
endef
-QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
+QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
define Download/ath10k-firmware-qca988x-ct
$(call Download/ct-firmware,QCA988X,)
HASH:=8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126
endef
$(eval $(call Download,ath10k-firmware-qca988x-ct))
-QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
+QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019
define Download/ath10k-firmware-qca988x-ct-htt
$(call Download/ct-firmware-htt,QCA988X,)
HASH:=a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7
@@ -103,14 +103,14 @@ endef
$(eval $(call Download,ath10k-firmware-qca988x-ct-htt))
-QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
+QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
define Download/ath10k-firmware-qca9887-ct
$(call Download/ct-firmware,QCA9887,ath10k-9887)
HASH:=459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b
endef
$(eval $(call Download,ath10k-firmware-qca9887-ct))
-QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
+QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019
define Download/ath10k-firmware-qca9887-ct-htt
$(call Download/ct-firmware-htt,QCA9887,ath10k-9887)
HASH:=fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098
@@ -118,62 +118,62 @@ endef
$(eval $(call Download,ath10k-firmware-qca9887-ct-htt))
-QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
+QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
define Download/ath10k-firmware-qca99x0-ct
$(call Download/ct-firmware,QCA99X0,ath10k-10-4b)
- HASH:=cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42
+ HASH:=7dc934f934bc4973c9273a4f22cfead8e26ec6f579647af31b718a860eca0a4b
endef
$(eval $(call Download,ath10k-firmware-qca99x0-ct))
-QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
+QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019
define Download/ath10k-firmware-qca99x0-ct-htt
$(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b)
- HASH:=e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc
+ HASH:=71a27b245a382fe009938d2826d5c97a90dceb10ddf638325268df91837ea302
endef
$(eval $(call Download,ath10k-firmware-qca99x0-ct-htt))
-QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
+QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
define Download/ath10k-firmware-qca9984-ct
$(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b)
- HASH:=a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1
+ HASH:=32d13f432691fe759ded7d027052e925233adb436cd8f729f85ec3d19ccd1dfd
endef
$(eval $(call Download,ath10k-firmware-qca9984-ct))
-QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
+QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019
define Download/ath10k-firmware-qca9984-ct-htt
$(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b)
- HASH:=96060227e372b3b210badccbe6b0bd75d9a35335a7a0f2966964e9e89f66b00f
+ HASH:=e8ab69777bd00b5fc6b1b7acccb55b903553a99932a5b0351602b5f690106588
endef
$(eval $(call Download,ath10k-firmware-qca9984-ct-htt))
-QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
+QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
define Download/ath10k-firmware-qca4019-ct
$(call Download/ct-firmware,QCA4019,ath10k-4019-10-4b)
- HASH:=46d8f8f1e780813299dc8780eedcfceda103c6b4d8908589ad1adbef921714
[PATCH 19.07 v2 0/6] Update ath10k-ct firmware
From: Baptiste Jonglez
This backports all recent ath10k-ct firmware bumps from master, and also
backports moving these firmwares to a new package. Opkg package names remain
unchanged.
v2: don't backport the following changes:
2e5e9b459ed5 ("ath10k-ct-firmware: rename ct-htt packages")
a882bfce052e ("ath10k-ct-firmware: add htt-mgt variants")
Applied together, these changes would basically change the firmware
variant that we distribute in the "ath10k-firmware-*-ct-htt" packages
from the "full" version to the "diet / non-full" version.
Even though these ath10k-ct-htt firmwares are not used in default OpenWrt
images, this change would not be acceptable for a backport. Downstream users
might rely on these variants.
As a result, we don't backport the "diet / non-full" variant at all.
Michael Yartys (2):
ath10k-firmware: update ath10k-ct firmware
ath10k-ct-firmware: update firmware images
Stefan Lippers-Hollmann (1):
ath10k-firmware: update Candela Tech firmware images
Álvaro Fernández Rojas (3):
ath10k-firmware: update ath10k-ct firmware images
ath10k-firmware: move CT firmwares to new package
ath10k-ct-firmware: update firmware images
package/firmware/ath10k-ct-firmware/Makefile | 524 +++
package/firmware/ath10k-firmware/Makefile| 446
2 files changed, 524 insertions(+), 446 deletions(-)
create mode 100644 package/firmware/ath10k-ct-firmware/Makefile
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07 v2 2/6] ath10k-firmware: update ath10k-ct firmware
From: Michael Yartys This supports better per-chain noise floor reporting, which in turn allows for better RSSI reporting in the driver. Wave-2 fixes a long-standing rate-ctrl problem when connected to xbox (and probably other devices). Wave-2 has fix for crash likely related to rekeying. Wave-1 has some debugging code added where a user reported a crash. Tested-by: Stefan Lippers-Hollmann [ipq806x+qca9984,ipq4019+qca9986] Signed-off-by: Michael Yartys (cherry picked from commit 18622638831707038556b9b8bd5a0b4d4a53ce53) --- package/firmware/ath10k-firmware/Makefile | 48 +++ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 9f1e7e676b..af883e6f03 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -64,92 +64,92 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.014 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.015 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) - HASH:=19db86003509dedb8ace339c183813ca637d65af24d00666411d1590efe33e13 + HASH:=a3a760d0d72707feffa496b6d2266bd9195f09806553b36420b60c0f12b8b87e endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 define Download/ath10k-firmware-qca988x-ct-htt $(call Download/ct-firmware-htt,QCA988X,) - HASH:=454e67dab545e720369a07be2fee16de008c76db4ab3119e7760bf9f7504c066 + HASH:=3114a54103d2b492fa1ef903769721f59953c829020d62502a1ec411ab4146d5 endef $(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.014 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.015 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) - HASH:=b3c738328427e124701a5735d65cde0f60e4172ae5bc23b00e5b16df7995dbd4 + HASH:=71e8b76dfd7c786d2f57bb7df207dcd13a91d3b492cfbd28916f084d0d1bb5e7 endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 define Download/ath10k-firmware-qca9887-ct-htt $(call Download/ct-firmware-htt,QCA9887,ath10k-9887) - HASH:=4432ccee23133bbaa4a5552e50a1e7e889b257362603e05530e751b67c29b7b5 + HASH:=b085e5d2239727b72bc647a76864431b8ac48438e6a33b1d55edc468f6ff endef $(eval $(call Download,ath10k-firmware-qca9887-ct-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=9a908f743604a468b651a5f73c49e6b0ba11a05c677b9726fbf041b849d88b25 + HASH:=edebe2f6f169cdd05c81a8a78156fb3426a66f415e7946af2ae4b7310fca5fe3 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 define Download/ath10k-firmware-qca99x0-ct-htt $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) - HASH:=800dd0816702aaca75f3eb5436c2ea724a6c24833838cd54399b9286b4d4fbe8 + HASH:=1ef67fb07da9082886e4dd554dfc19256e10b500faf9e4b2a5774d0238130bae endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) - HASH:=a8b12dba478e8c9d4a215f82324382c7554a900e83c31775f8511af84e59fef7 + HASH:=c2f04da3285aad37baef9c37c9905a31927175dd234cd4378fd56c106e5c9379 endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 define Download/ath10k-firmware-qca9984-ct-htt $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b) - HASH:=d185651b5d3d1f0082720bc6c2bbe43b2a00cdb6333403fac9336a720b1d93ae + HASH:=0c9ede1036750d68885e6481fa84f3cb72192b8440b47719344f7327a030f05d endef $(eval $(call Download,ath10k-firmware-qca9984-ct-htt)) -QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 +QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 define Download/ath10k-firmware-qca4019-ct $(call Download/ct-firmware,QCA4019,ath10k-4019-10-4b) -
[PATCH 19.07 v2 1/6] ath10k-firmware: update Candela Tech firmware images
From: Stefan Lippers-Hollmann The release notes since last time for wave-1: * No changes to wave-1, but I make a version .014 copy anyway to keep the makefile in sync. The release notes since last time for wave-2: * December 16, 2019: Wave-2 has a fix to make setting txpower work better. Before setting the power was ignored at least some of the time (it also appeared to work mostly, so I guess it was being correctly set in other ways). Signed-off-by: Stefan Lippers-Hollmann (cherry picked from commit 65982642668e859540b21c2bd3bf907493df830a) --- package/firmware/ath10k-firmware/Makefile | 40 +++ 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index b6a7c94e89..9f1e7e676b 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -64,14 +64,14 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.013 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.014 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) HASH:=19db86003509dedb8ace339c183813ca637d65af24d00666411d1590efe33e13 endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.013 +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 define Download/ath10k-firmware-qca988x-ct-htt $(call Download/ct-firmware-htt,QCA988X,) HASH:=454e67dab545e720369a07be2fee16de008c76db4ab3119e7760bf9f7504c066 @@ -79,14 +79,14 @@ endef $(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.013 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.014 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) HASH:=b3c738328427e124701a5735d65cde0f60e4172ae5bc23b00e5b16df7995dbd4 endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.013 +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 define Download/ath10k-firmware-qca9887-ct-htt $(call Download/ct-firmware-htt,QCA9887,ath10k-9887) HASH:=4432ccee23133bbaa4a5552e50a1e7e889b257362603e05530e751b67c29b7b5 @@ -94,62 +94,62 @@ endef $(eval $(call Download,ath10k-firmware-qca9887-ct-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.013 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=6fa74a3fc87cba97dbc4a7213b760f8d997cd9c5f11900d47d387b23764cf20a + HASH:=9a908f743604a468b651a5f73c49e6b0ba11a05c677b9726fbf041b849d88b25 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 define Download/ath10k-firmware-qca99x0-ct-htt $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) - HASH:=68e92820c51270eba4f68b24654c4a9408902b2600762b70204f4cb5419bb714 + HASH:=800dd0816702aaca75f3eb5436c2ea724a6c24833838cd54399b9286b4d4fbe8 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.013 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) - HASH:=08aeb883bd2d9258e8f1907cca8a0d2eda1c559a66e228dadffd6798f6877c7d + HASH:=a8b12dba478e8c9d4a215f82324382c7554a900e83c31775f8511af84e59fef7 endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 define Download/ath10k-firmware-qca9984-ct-htt $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b) - HASH:=38ed59a2b3c66c10926706a21ae2d3aeaf83e589f19345a8f48d6520522e4fde + HASH:=d185651b5d3d1f0082720bc6c2bbe43b2a00cdb6333403fac9336a720b1d93ae endef $(eval $(call Download,ath10k-firmware-qca9984-ct-htt)) -QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.013 +QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 define Download/ath10k-firmware-qca4019-ct $(call Download/ct-firmware,QCA4019,ath10k-4019-10-4b) - HASH:=feca75fe89af9a3e998047f85ff3428676f4d574b770d51773bb419d0dd98e5a + HASH:=4c2e48835219f420b18dc58e31d1387dae0da70d8170c3fc5e7bce39c06cf355 endef
Re: [PATCH 19.07 7/8] ath10k-ct-firmware: add htt-mgt variants
Adrian pointed out a possible issue with these backpots: combining patches
5/8 and 7/8 basically mean that a different firmware variant will be
distributed in "ath10k-firmware-*-ct-htt" packages.
Currently in 19.07 the ath10k-firmware-*-ct-htt packages bundle this
firmware variant: firmware-{2,5}-ct-full-htt-mgt-community
With patch 5/8 and 7/8, the same ath10k-firmware-*-ct-htt packages would
instead bundle this firmware variant: firmware-{2,5}-ct-htt-mgt-community
The description of this new firmware variant is copied below:
The non-full one (hence forth 'diet') compiles out a lot of firmware
features that ath10k does not use. This saves a lot of resources and
lets one configure more stations/vdevs/etc using fwcfg.
These HTT firmwares are not used in default openwrt images, but they could
be used downstream: it does not seem wise to distribute a different
firmware variant under the same package name.
I will send a v2 fixing this.
On 25-08-20, Baptiste Jonglez wrote:
> From: Álvaro Fernández Rojas
>
> For wave-2, there is now a new variant: htt-mgt-community (vs the old
> full-htt-mgt-community).
>
> The non-full one (hence forth 'diet') compiles out a lot of firmware features
> that ath10k does not use. This saves a lot of resources and lets one
> configure more stations/vdevs/etc using fwcfg.
>
> Signed-off-by: Álvaro Fernández Rojas
> (cherry picked from commit a882bfce052e78bd344dcbd36efb32acf1340d7a)
> ---
> package/firmware/ath10k-ct-firmware/Makefile | 155 ++-
> 1 file changed, 154 insertions(+), 1 deletion(-)
>
> diff --git a/package/firmware/ath10k-ct-firmware/Makefile
> b/package/firmware/ath10k-ct-firmware/Makefile
> index 6a35e9c75c..18370b7d85 100644
> --- a/package/firmware/ath10k-ct-firmware/Makefile
> +++ b/package/firmware/ath10k-ct-firmware/Makefile
> @@ -2,7 +2,7 @@ include $(TOPDIR)/rules.mk
>
> PKG_NAME:=ath10k-ct-firmware
> PKG_VERSION:=2020-04-24
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>
> include $(INCLUDE_DIR)/package.mk
>
> @@ -75,6 +75,7 @@ $(eval $(call Download,qca9888-board2))
>
> CT_FIRMWARE_FILE = $(1)-$($(1)_FIRMWARE_FILE_CT)
> CT_FIRMWARE_FILE_FULL_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_FULL_HTT)
> +CT_FIRMWARE_FILE_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_HTT)
>
> define Download/ct-firmware
>URL:=https://www.candelatech.com/downloads/$(2)
> @@ -88,6 +89,12 @@ define Download/ct-firmware-full-htt
>URL_FILE:=$($(1)_FIRMWARE_FILE_CT_FULL_HTT)
> endef
>
> +define Download/ct-firmware-htt
> + URL:=https://www.candelatech.com/downloads/$(2)
> + FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1))
> + URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
> +endef
> +
> QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
> define Download/ath10k-firmware-qca988x-ct
>$(call Download/ct-firmware,QCA988X,)
> @@ -132,6 +139,13 @@ define Download/ath10k-firmware-qca99x0-ct-full-htt
> endef
> $(eval $(call Download,ath10k-firmware-qca99x0-ct-full-htt))
>
> +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018
> +define Download/ath10k-firmware-qca99x0-ct-htt
> + $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b)
> + HASH:=4d4f74afca487d452f244cd48304cf9710d8941eb97a6346a949ed6b6877d657
> +endef
> +$(eval $(call Download,ath10k-firmware-qca99x0-ct-htt))
> +
>
> QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
> define Download/ath10k-firmware-qca9984-ct
> @@ -147,6 +161,13 @@ define Download/ath10k-firmware-qca9984-ct-full-htt
> endef
> $(eval $(call Download,ath10k-firmware-qca9984-ct-full-htt))
>
> +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018
> +define Download/ath10k-firmware-qca9984-ct-htt
> + $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b)
> + HASH:=ee593fb5724d75c372de02ac7894e1630ee9f909fcb2e2bbf17aadef67cb9d43
> +endef
> +$(eval $(call Download,ath10k-firmware-qca9984-ct-htt))
> +
>
> QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
> define Download/ath10k-firmware-qca4019-ct
> @@ -162,6 +183,13 @@ define Download/ath10k-firmware-qca4019-ct-full-htt
> endef
> $(eval $(call Download,ath10k-firmware-qca4019-ct-full-htt))
>
> +QCA4019_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018
> +define Download/ath10k-firmware-qca4019-ct-htt
> + $(call Download/ct-firmware-htt,QCA4019,ath10k-4019-10-4b)
> + HASH:=51fe06f66365771647d16039cca8b541de3d642c45271977a4cfd433c2c5d45b
> +endef
> +$(eval $(call Download,ath10k-firmware-qca4019-ct-htt))
> +
>
> QCA9888_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
> define Download/ath10k-firmware-qca9888-ct
> @@ -177,6 +205,
Re: [PATCH] build: opkg-key variable key folder
Sorry, forgot to reply: On 31-08-20, Daniel Golle wrote: > On Wed, Aug 26, 2020 at 11:57:55AM -1000, Paul Spooren wrote: > > > > On 26.08.20 09:17, Baptiste Jonglez wrote: > > > On 25-08-20, Paul Spooren wrote: > > > > The key folder is used by `opkg` and `usign` to store and retrieve > > > > trusted public keys. Using `opkg-key` outside a running device is > > > > unfeasible as the key folder is hard coded to `/etc/opkg/keys`. > > > > > > > > This commit adds a variable OPKG_KEYS which defaults to `/etc/opkg/keys` > > > > if unset, however allows set arbitrary key folder locations. > > > > > > > > Arbitrary key folder locations are useful to add signature verification > > > > to the ImageBuilders. > > > It should be noted that this increases the attack surface. > > > > > > Especially env variables are easy to set and hard to notice. This could > > > allow an attacker to provide a rogue keyring to opkg by just setting an > > > environment variable, and this would be quite hard to trace. > > > > The `opkg` process likely runs as root user, so you have so sneak in env > > variables to a root process, which from my understanding root privileges. Sure, but most services run as root on OpenWrt. Dnsmasq is a notable exception. > > Also the current script uses a relative path to `usign`, which means instead > > of providing your own fake keys via OPKG_KEYS, you could just modify the > > PATH variable to have a fake version of `usign` running, returning a > > successful exit code to anything. Once somebody finds a way to exploit a network-facing daemon, there are indeed many ways to escalate. My concern is to limit the attack surface if possible, and make it easier to spot any tampering that could have taken place. Spotting a modified PATH is easier than spotting a custom env variable being set. > > > I would prefer one of two alternatives: > > > > > > 1) take a cmdline argument > > > > Where would that cmdline be added? From the ImageBuilder Makefile? In that > > case it'd go through `opkg` to then be passed to `opkg-key`. This would > > somewhat force you to use that specific script, while there exists also a > > `gnupg` version[1]. You're right, it would need further modification in opkg, it's not a good idea. > > [1]: > > https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=utils/opkg-key;h=266bb6628a9cae8096f482c4b1d78fe3c3bcb2ca;hb=HEAD > > > > > 2) provide different opkg-key scripts for device and host usage. Each > > > script can use a ~hard-coded path to the expected key location > > > (possibly > > > using $TOPDIR etc). > > > > > > While solution 2) would still use env variables for host usage, it would > > > only apply to this host usage of opkg: we do not compromise the security > > > of device-based opkg. > > > > I'm somewhat against maintaining two scripts if not really necessary. If we > > go that road we need absolute path for usign, cat, zcat etc. > > I agree with Paul's arguments and was about to pull this change in. > Any objections? While I am still slightly uncomfortable with it, it's not a huge issue (well, I hope so ;) ) and I don't have a better suggestion. So pulling this is fine with me. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming 19.07.4 and 18.07.9 stable releases
On 29-08-20, Baptiste Jonglez wrote: > On 28-08-20, Hauke Mehrtens wrote: > > Hi, > > > > I would like to do a 19.07.4 and a 18.06.9 release on Sunday or > > beginning of next week. > > Cool, looks good to me. > > > Is there something missing in the current branches which should get into > > this release? > > There's the ath10k-ct-firmware bump for 19.07: > https://patchwork.ozlabs.org/project/openwrt/list/?q=19.07 > > I plan to look at the LuCI issue mentioned here: > https://openwrt.org/docs/guide-developer/releases/goals/19.07.4 I backported a fix for the LuCI issue, the pull request needs to be merged before the 19.07.4 release: https://github.com/openwrt/luci/pull/4402 Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 18.06] mac80211: Backport fixes for Kr00k vulnerabilities
On 29-08-20, Hauke Mehrtens wrote:
> On 8/29/20 2:02 PM, Baptiste Jonglez wrote:
> > On 28-08-20, Hauke Mehrtens wrote:
> >> This backports some fixes from kernel 5.6 and 4.14.175.
> >
> > Thanks, I will give this a try.
> >
> > It's missing two fixes though:
> >
> > 5981fe5b0529 ("mac80211: fix misplaced while instead of if")
I tested 18.06 with your 3 patches + 4cf1d191f77f8 (the 4.19 backport of
5981fe5b0529). Everything worked normally on a RB941-2nD with ath9k.
Tested-By: Baptiste Jonglez
> I will add this one to 18.06 and 19.07. The others should be in 19.07
> already.
>
> > a0761a301746 ("mac80211: drop data frames without key on encrypted links")
>
> This does not apply to kernel < 5.4, see here:
> https://lore.kernel.org/linux-wireless/20200327150342.252af20...@mail.kernel.org/
Ah, thanks, that explains it. In that case it makes sense to wait for
this patch to be backported properly, if it's needed at all.
FYI, I tried to trigger the vulnerability on 18.06.7 with ath9k, which
should be vulnerable, but it did not trigger. Either I'm doing it wrong,
or it's hard/impossible to trigger.
Baptiste
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 18.06] mac80211: Backport fixes for Kr00k vulnerabilities
On 28-08-20, Hauke Mehrtens wrote:
> This backports some fixes from kernel 5.6 and 4.14.175.
Thanks, I will give this a try.
It's missing two fixes though:
5981fe5b0529 ("mac80211: fix misplaced while instead of if")
a0761a301746 ("mac80211: drop data frames without key on encrypted links")
The second one has strangely not been backported to stable kernels, even
though it says "Cc: sta...@vger.kernel.org". I'm not sure what we should
do with it.
Baptiste
> Signed-off-by: Hauke Mehrtens
> ---
> ...ation-unauthorized-before-key-remova.patch | 42 +++
> ...ort-authorization-in-the-ieee80211_t.patch | 54 +++
> ...-fix-authentication-with-iwlwifi-mvm.patch | 34
> 3 files changed, 130 insertions(+)
> create mode 100644
> package/kernel/mac80211/patches/480-mac80211-mark-station-unauthorized-before-key-remova.patch
> create mode 100644
> package/kernel/mac80211/patches/481-mac80211-Check-port-authorization-in-the-ieee80211_t.patch
> create mode 100644
> package/kernel/mac80211/patches/482-mac80211-fix-authentication-with-iwlwifi-mvm.patch
>
> diff --git
> a/package/kernel/mac80211/patches/480-mac80211-mark-station-unauthorized-before-key-remova.patch
>
> b/package/kernel/mac80211/patches/480-mac80211-mark-station-unauthorized-before-key-remova.patch
> new file mode 100644
> index 00..012b6cae15
> --- /dev/null
> +++
> b/package/kernel/mac80211/patches/480-mac80211-mark-station-unauthorized-before-key-remova.patch
> @@ -0,0 +1,42 @@
> +From 1ec47ff0525c4a530dc7783cb28044179334a4cc Mon Sep 17 00:00:00 2001
> +From: Johannes Berg
> +Date: Thu, 26 Mar 2020 15:51:35 +0100
> +Subject: [PATCH] mac80211: mark station unauthorized before key removal
> +
> +commit b16798f5b907733966fd1a558fca823b3c67e4a1 upstream.
> +
> +If a station is still marked as authorized, mark it as no longer
> +so before removing its keys. This allows frames transmitted to it
> +to be rejected, providing additional protection against leaking
> +plain text data during the disconnection flow.
> +
> +Cc: sta...@vger.kernel.org
> +Link:
> https://lore.kernel.org/r/20200326155133.ccb4fb0bb356.If48f0f0504efdcf16b8921f48c6d3bb2cb763c99@changeid
> +Signed-off-by: Johannes Berg
> +Signed-off-by: Greg Kroah-Hartman
> +---
> + net/mac80211/sta_info.c | 6 ++
> + 1 file changed, 6 insertions(+)
> +
> +--- a/net/mac80211/sta_info.c
> b/net/mac80211/sta_info.c
> +@@ -3,6 +3,7 @@
> + * Copyright 2006-2007 Jiri Benc
> + * Copyright 2013-2014 Intel Mobile Communications GmbH
> + * Copyright (C) 2015 - 2017 Intel Deutschland GmbH
> ++ * Copyright (C) 2018-2020 Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> +@@ -976,6 +977,11 @@ static void __sta_info_destroy_part2(str
> + might_sleep();
> + lockdep_assert_held(>sta_mtx);
> +
> ++while (sta->sta_state == IEEE80211_STA_AUTHORIZED) {
> ++ret = sta_info_move_state(sta, IEEE80211_STA_ASSOC);
> ++WARN_ON_ONCE(ret);
> ++}
> ++
> + /* now keys can no longer be reached */
> + ieee80211_free_sta_keys(local, sta);
> +
> diff --git
> a/package/kernel/mac80211/patches/481-mac80211-Check-port-authorization-in-the-ieee80211_t.patch
>
> b/package/kernel/mac80211/patches/481-mac80211-Check-port-authorization-in-the-ieee80211_t.patch
> new file mode 100644
> index 00..1867e809be
> --- /dev/null
> +++
> b/package/kernel/mac80211/patches/481-mac80211-Check-port-authorization-in-the-ieee80211_t.patch
> @@ -0,0 +1,54 @@
> +From 07dc42ff9b9c38eae221b36acda7134ab8670af8 Mon Sep 17 00:00:00 2001
> +From: Jouni Malinen
> +Date: Thu, 26 Mar 2020 15:51:34 +0100
> +Subject: [PATCH] mac80211: Check port authorization in the
> + ieee80211_tx_dequeue() case
> +
> +commit ce2e1ca703071723ca2dd94d492a5ab6d15050da upstream.
> +
> +mac80211 used to check port authorization in the Data frame enqueue case
> +when going through start_xmit(). However, that authorization status may
> +change while the frame is waiting in a queue. Add a similar check in the
> +dequeue case to avoid sending previously accepted frames after
> +authorization change. This provides additional protection against
> +potential leaking of frames after a station has been disconnected and
> +the keys for it are being removed.
> +
> +Cc: sta...@vger.kernel.org
> +Signed-off-by: Jouni Malinen
> +Link:
> https://lore.kernel.org/r/20200326155133.ced84317ea29.I34d4c47cd8cc8a4042b38a76f16a601fbcbfd9b3@changeid
> +Signed-off-by: Johannes Berg
> +Signed-off-by: Greg Kroah-Hartman
> +---
> + net/mac80211/tx.c | 19 ++-
> + 1 file changed, 18 insertions(+), 1 deletion(-)
> +
> +--- a/net/mac80211/tx.c
> b/net/mac80211/tx.c
> +@@ -3496,8 +3496,25 @@ begin:
> + tx.sdata = vif_to_sdata(info->control.vif);
> + tx.hdrlen = ieee80211_padded_hdrlen(hw, hdr->frame_control);
> +
> +-
Re: Upcoming 19.07.4 and 18.07.9 stable releases
On 28-08-20, Hauke Mehrtens wrote: > Hi, > > I would like to do a 19.07.4 and a 18.06.9 release on Sunday or > beginning of next week. Cool, looks good to me. > Is there something missing in the current branches which should get into > this release? There's the ath10k-ct-firmware bump for 19.07: https://patchwork.ozlabs.org/project/openwrt/list/?q=19.07 I plan to look at the LuCI issue mentioned here: https://openwrt.org/docs/guide-developer/releases/goals/19.07.4 Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVE-2020-3702: Firmware updates for ath9k and ath10k chips
Hi,
Cross-posting to openwrt-devel because we are backporting the necessary fixes.
On 12-08-20, Jouni Malinen wrote:
> On Wed, Aug 12, 2020 at 11:17:47AM +0200, Toke H?iland-J?rgensen wrote:
> > Pali Roh?r writes:
> > > Could somebody react and provide some details when fixes would be
> > > available for ath9k and ath10k Linux drivers? And what is current state
> > > of this issue for Linux?
> > >
> > > I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
> > > there any change which could be related to CVE-2020-3702.
> >
> > How about these, from March:
> >
> > a0761a301746 ("mac80211: drop data frames without key on encrypted links")
> > ce2e1ca70307 ("mac80211: Check port authorization in the
> > ieee80211_tx_dequeue() case")
> > b16798f5b907 ("mac80211: mark station unauthorized before key removal")
>
> Those cover most of the identified issues for drivers using mac80211
> (e.g., ath9k and ath10k; though, I don't remember whether I actually
> ever managed to reproduce this with ath10k in practice). I have couple
> of additional ath9k-specific patches that cover additional lower layer
> paths for this. I hope to get those out after confirming they work with
> the current kernel tree snapshot.
I could find linux-stable backports for ce2e1ca70307 and b16798f5b907, but
not for a0761a301746. Is it intended? From the commit message, it looks
like it does fix an important issue.
Also, for the sake of completeness, this subsequent commit is also related
to CVE-2020-3702 (and already backported):
5981fe5b0529 ("mac80211: fix misplaced while instead of if")
Thanks,
Baptiste
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] build: switch VERSION_REPO to HTTPS
Thanks :) Acked-by: Baptiste Jonglez On 27-08-20, Paul Spooren wrote: > The variable VERSION_REPO is used by opkg to download package(list)s. > Now that the default installation support encrypted HTTP opkg should > make use of it. > > Suggested-by: Petr Štetiar > Suggested-by: Baptiste Jonglez > Signed-off-by: Paul Spooren > --- > include/version.mk | 2 +- > package/base-files/image-config.in | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/version.mk b/include/version.mk > index 7d3c1ad640..b7f42e13bb 100644 > --- a/include/version.mk > +++ b/include/version.mk > @@ -32,7 +32,7 @@ VERSION_CODE:=$(call qstrip,$(CONFIG_VERSION_CODE)) > VERSION_CODE:=$(if $(VERSION_CODE),$(VERSION_CODE),$(REVISION)) > > VERSION_REPO:=$(call qstrip,$(CONFIG_VERSION_REPO)) > -VERSION_REPO:=$(if > $(VERSION_REPO),$(VERSION_REPO),http://downloads.openwrt.org/snapshots) > +VERSION_REPO:=$(if > $(VERSION_REPO),$(VERSION_REPO),https://downloads.openwrt.org/snapshots) > > VERSION_DIST:=$(call qstrip,$(CONFIG_VERSION_DIST)) > VERSION_DIST:=$(if $(VERSION_DIST),$(VERSION_DIST),OpenWrt) > diff --git a/package/base-files/image-config.in > b/package/base-files/image-config.in > index 4bace77db0..bfa3055cc8 100644 > --- a/package/base-files/image-config.in > +++ b/package/base-files/image-config.in > @@ -183,7 +183,7 @@ if VERSIONOPT > config VERSION_REPO > string > prompt "Release repository" > - default "http://downloads.openwrt.org/snapshots; > + default "https://downloads.openwrt.org/snapshots; > help > This is the repository address embedded in the image, > it defaults > to the trunk snapshot repo; the url may contain the > following placeholders: signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] treewide: switch to HTTPS by default
On 25-08-20, Paul Spooren wrote: > From: Petr Štetiar > > As there is now wolfSSL included by default due to SAE/WPA3 we can > finally switch to TLS/SSL in other parts as well. The commit message needs improvement, especially "treewide: switch to HTTPS by default". What is switched to HTTPS exactly? It could be source download URL, package download URL on the device, package download URL on the imagebuilder... What parts of OpenWrt are expected to be impacted by this? Other comments below: > --- a/include/target.mk > +++ b/include/target.mk > @@ -13,13 +13,41 @@ __target_inc=1 > DEVICE_TYPE?=router > > # Default packages - the really basic set > -DEFAULT_PACKAGES:=base-files libc libgcc busybox dropbear mtd uci opkg > netifd fstools uclient-fetch logd urandom-seed urngd > +DEFAULT_PACKAGES:=\ > + base-files \ > + busybox \ > + ca-bundle \ > + dropbear \ > + fstools \ > + libc \ > + libgcc \ > + logd \ > + mtd \ > + netifd \ > + opkg \ > + uci \ > + uclient-fetch \ > + urandom-seed \ > + urngd This is hard to read, please drop the cosmetic changes or move them to a separate commit. Also, it seems it's missing the actual change, i.e. libustream-wolfssl? > --- a/include/version.mk > +++ b/include/version.mk > @@ -32,7 +32,7 @@ VERSION_CODE:=$(call qstrip,$(CONFIG_VERSION_CODE)) > VERSION_CODE:=$(if $(VERSION_CODE),$(VERSION_CODE),$(REVISION)) > > VERSION_REPO:=$(call qstrip,$(CONFIG_VERSION_REPO)) > -VERSION_REPO:=$(if > $(VERSION_REPO),$(VERSION_REPO),http://downloads.openwrt.org/snapshots) > +VERSION_REPO:=$(if > $(VERSION_REPO),$(VERSION_REPO),https://downloads.openwrt.org/snapshots) > > VERSION_DIST:=$(call qstrip,$(CONFIG_VERSION_DIST)) > VERSION_DIST:=$(if $(VERSION_DIST),$(VERSION_DIST),OpenWrt) VERSION_REPO needs to be updated as well in package/base-files/image-config.in It's not used by default (because it's guarded by IMAGEOPT and VERSIONOPT) but it can be used to customize the download URL. So it's more logical if it starts with the same value as the default download URL. Also, several scripts will need adaptation: - makebranch.sh in maintainer-tools - maketag.sh in maintainer-tools. This one should be adapted carefully so that it still works for 19.07.X. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: opkg-key variable key folder
On 25-08-20, Paul Spooren wrote:
> The key folder is used by `opkg` and `usign` to store and retrieve
> trusted public keys. Using `opkg-key` outside a running device is
> unfeasible as the key folder is hard coded to `/etc/opkg/keys`.
>
> This commit adds a variable OPKG_KEYS which defaults to `/etc/opkg/keys`
> if unset, however allows set arbitrary key folder locations.
>
> Arbitrary key folder locations are useful to add signature verification
> to the ImageBuilders.
It should be noted that this increases the attack surface.
Especially env variables are easy to set and hard to notice. This could
allow an attacker to provide a rogue keyring to opkg by just setting an
environment variable, and this would be quite hard to trace.
I would prefer one of two alternatives:
1) take a cmdline argument
2) provide different opkg-key scripts for device and host usage. Each
script can use a ~hard-coded path to the expected key location (possibly
using $TOPDIR etc).
While solution 2) would still use env variables for host usage, it would
only apply to this host usage of opkg: we do not compromise the security
of device-based opkg.
Baptiste
> Signed-off-by: Paul Spooren
> ---
> package/system/opkg/files/opkg-key | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/package/system/opkg/files/opkg-key
> b/package/system/opkg/files/opkg-key
> index ae5e8a4591..51d1857ad5 100755
> --- a/package/system/opkg/files/opkg-key
> +++ b/package/system/opkg/files/opkg-key
> @@ -1,5 +1,7 @@
> #!/bin/sh
>
> +OPKG_KEYS="${OPKG_KEYS:-/etc/opkg/keys}"
> +
> usage() {
> cat < Usage: $0
> @@ -19,7 +21,7 @@ opkg_key_verify() {
> (
> zcat "$msgfile" 2>/dev/null ||
> cat "$msgfile" 2>/dev/null
> - ) | usign -V -P /etc/opkg/keys -q -x "$sigfile" -m -
> + ) | usign -V -P "$OPKG_KEYS" -q -x "$sigfile" -m -
> }
>
> opkg_key_add() {
> @@ -27,8 +29,8 @@ opkg_key_add() {
> [ -n "$key" ] || usage
> [ -f "$key" ] || echo "Cannot open file $1"
> local fingerprint="$(usign -F -p "$key")"
> - mkdir -p "/etc/opkg/keys"
> - cp "$key" "/etc/opkg/keys/$fingerprint"
> + mkdir -p "$OPKG_KEYS"
> + cp "$key" "$OPKG_KEYS/$fingerprint"
> }
>
> opkg_key_remove() {
> @@ -36,7 +38,7 @@ opkg_key_remove() {
> [ -n "$key" ] || usage
> [ -f "$key" ] || echo "Cannot open file $1"
> local fingerprint="$(usign -F -p "$key")"
> - rm -f "/etc/opkg/keys/$fingerprint"
> + rm -f "$OPKG_KEYS/$fingerprint"
> }
>
> case "$1" in
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH opkg] opkg: allow to configure the path to the signature verification script
On 25-08-20, Paul Spooren wrote: > On 24.08.20 05:07, Baptiste Jonglez wrote: > > From: Baptiste Jonglez > > > > Currently, package index signatures are only checked when opkg runs on the > > OpenWrt device. The verification script is hard-coded to a path in > > /usr/sbin/. > > > > Making this path configurable is a first step to implement signature > > verification in host builds of opkg (e.g. in the imagebuilder). > > > > Signed-off-by: Baptiste Jonglez > > Great, I was just looking for something like that! Thank you very much. > > Tested via an ImageBuilder moving a `exit 0` script to the host machine at > `/usr/sbin/opkg-key` and afterwards defining a custom place, both worked > fine. Thanks for testing. > The openwrt.git/opkg-key (not opkg.git/opkg-key) script uses currently a > hard coded key position (`/etc/opkg/keys`) which should be patched next. Yes, several more changes need to be done in the openwrt build system. But for opkg this change should be enough to get things going. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07 4/8] ath10k-firmware: move CT firmwares to new package
From: Álvaro Fernández Rojas Signed-off-by: Álvaro Fernández Rojas (cherry picked from commit 658e68f85c2645e0132edc6b30a9c76cc17292de) --- package/firmware/ath10k-ct-firmware/Makefile | 524 +++ package/firmware/ath10k-firmware/Makefile| 446 2 files changed, 524 insertions(+), 446 deletions(-) create mode 100644 package/firmware/ath10k-ct-firmware/Makefile diff --git a/package/firmware/ath10k-ct-firmware/Makefile b/package/firmware/ath10k-ct-firmware/Makefile new file mode 100644 index 00..79bdeeec4f --- /dev/null +++ b/package/firmware/ath10k-ct-firmware/Makefile @@ -0,0 +1,524 @@ +include $(TOPDIR)/rules.mk + +PKG_NAME:=ath10k-ct-firmware +PKG_VERSION:=2020-03-25 +PKG_RELEASE:=1 + +include $(INCLUDE_DIR)/package.mk + +ATH10K_FIRMWARE_REV:=d622d160e9f552ead68d9ae81b715422892dc2ef +ATH10K_FIRMWARE_URL:=@GITHUB/kvalo/ath10k-firmware/$(ATH10K_FIRMWARE_REV) + +QCA9887_BOARD_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca9887-board.bin +define Download/qca9887-board + FILE:=$(QCA9887_BOARD_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA9887/hw1.0 + URL_FILE:=board.bin + HASH:=cf4df099f6ee05c181f55ce17297a1d32c61d725eb96246fd315ad5587c42426 +endef +$(eval $(call Download,qca9887-board)) + +QCA988X_BOARD_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca988x-board.bin +define Download/qca988x-board + FILE:=$(QCA988X_BOARD_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA988X/hw2.0 + URL_FILE:=board.bin + HASH:=5b5b380333c2dd3b6ce67f30e2f7008f4020bf594970d3b464fd8d4a80fcd880 +endef +$(eval $(call Download,qca988x-board)) + +QCA99X0_BOARD_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca99x0-board.bin +define Download/qca99x0-board + FILE:=$(QCA99X0_BOARD_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA99X0/hw2.0 + URL_FILE:=boardData_AR900B_CUS239_5G_v2_001.bin + HASH:=3bf7561ee373b369025dcd366d276d038a97d3397ccae41ce841d98a58b30aff +endef +$(eval $(call Download,qca99x0-board)) + +QCA99X0_BOARD2_REV:=ddcec9efd245da9365c474f513a855a55f3ac7fe +QCA99X0_BOARD2_FILE:=ath10k-firmware-$(QCA99X0_BOARD2_REV)-qca99x0-board-2.bin +define Download/qca99x0-board2 + FILE:=$(QCA99X0_BOARD2_FILE) + URL:=https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA99X0/hw2.0 + URL_FILE:=board-2.bin?id=$(QCA99X0_BOARD2_REV) + HASH:=03711ac21e60ef59d3815e235eb721c0c22851b5410299411085aa6f2af45401 +endef +$(eval $(call Download,qca99x0-board2)) + +QCA9984_BOARD2_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca9984-board-2.bin +define Download/qca9984-board2 + FILE:=$(QCA9984_BOARD2_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA9984/hw1.0 + URL_FILE:=board-2.bin + HASH:=0d6d46cf0467185e3959ce3cb69e2415be6e48ab8a4bee3eb400edbe48cb9c25 +endef +$(eval $(call Download,qca9984-board2)) + +QCA4019_BOARD2_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca4019-board-2.bin +define Download/qca4019-board2 + FILE:=$(QCA4019_BOARD2_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA4019/hw1.0 + URL_FILE:=board-2.bin + HASH:=94b66aa4ddbed5110a96364d3c7b4ebcb320e3ac4e8697660b277e76077bc338 +endef +$(eval $(call Download,qca4019-board2)) + +QCA9888_BOARD2_FILE:=ath10k-firmware-$(ATH10K_FIRMWARE_REV)-qca9888-board-2.bin +define Download/qca9888-board2 + FILE:=$(QCA9888_BOARD2_FILE) + URL:=$(ATH10K_FIRMWARE_URL)/QCA9888/hw2.0 + URL_FILE:=board-2.bin + HASH:=5b871bb567f64525ca45adb88063211de472015d09e0f9aa3fa61ab71c8fdfd3 +endef +$(eval $(call Download,qca9888-board2)) + +CT_FIRMWARE_FILE = $(1)-$($(1)_FIRMWARE_FILE_CT) +CT_FIRMWARE_FILE_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_HTT) + +define Download/ct-firmware + URL:=https://www.candelatech.com/downloads/$(2) + FILE:=$(call CT_FIRMWARE_FILE,$(1)) + URL_FILE:=$($(1)_FIRMWARE_FILE_CT) +endef + +define Download/ct-firmware-htt + URL:=https://www.candelatech.com/downloads/$(2) + FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1)) + URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) +endef + +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 +define Download/ath10k-firmware-qca988x-ct + $(call Download/ct-firmware,QCA988X,) + HASH:=2f0bf766e400a4c5726e77b128eb8c141ebaa778526fe2c7c5083f3b17659dbf +endef +$(eval $(call Download,ath10k-firmware-qca988x-ct)) + +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 +define Download/ath10k-firmware-qca988x-ct-htt + $(call Download/ct-firmware-htt,QCA988X,) + HASH:=5e4285d5c6eee159a25ca14c6ce26022c32380bd7bafaedfc0c5de1510119007 +endef +$(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) + + +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 +define Download/ath10k-firmware-qca9887-ct + $(call Download/ct-firmware,QCA9887,ath10k-9887) + HASH:=4fa30e0e1972ca3b06225a731df0f93a1b73ac67fea5bf54bb55dea3bbc0da6a +endef +$(eval $(call Download,ath10k-firmware-qca9887-ct)) + +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 +define Download/ath10k-firmware-qca9887-ct-htt + $(call
[PATCH 19.07 5/8] ath10k-ct-firmware: rename ct-htt packages
From: Álvaro Fernández Rojas Signed-off-by: Álvaro Fernández Rojas (cherry picked from commit 2e5e9b459ed53b42f8938294a98e2546be976c85) --- package/firmware/ath10k-ct-firmware/Makefile | 130 +-- target/linux/ath79/image/generic.mk | 2 +- 2 files changed, 66 insertions(+), 66 deletions(-) diff --git a/package/firmware/ath10k-ct-firmware/Makefile b/package/firmware/ath10k-ct-firmware/Makefile index 79bdeeec4f..959bfa975b 100644 --- a/package/firmware/ath10k-ct-firmware/Makefile +++ b/package/firmware/ath10k-ct-firmware/Makefile @@ -2,7 +2,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-ct-firmware PKG_VERSION:=2020-03-25 -PKG_RELEASE:=1 +PKG_RELEASE:=2 include $(INCLUDE_DIR)/package.mk @@ -74,7 +74,7 @@ endef $(eval $(call Download,qca9888-board2)) CT_FIRMWARE_FILE = $(1)-$($(1)_FIRMWARE_FILE_CT) -CT_FIRMWARE_FILE_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_HTT) +CT_FIRMWARE_FILE_FULL_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_FULL_HTT) define Download/ct-firmware URL:=https://www.candelatech.com/downloads/$(2) @@ -82,10 +82,10 @@ define Download/ct-firmware URL_FILE:=$($(1)_FIRMWARE_FILE_CT) endef -define Download/ct-firmware-htt +define Download/ct-firmware-full-htt URL:=https://www.candelatech.com/downloads/$(2) - FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1)) - URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) + FILE:=$(call CT_FIRMWARE_FILE_FULL_HTT,$(1)) + URL_FILE:=$($(1)_FIRMWARE_FILE_CT_FULL_HTT) endef QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 @@ -95,12 +95,12 @@ define Download/ath10k-firmware-qca988x-ct endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 -define Download/ath10k-firmware-qca988x-ct-htt - $(call Download/ct-firmware-htt,QCA988X,) +QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 +define Download/ath10k-firmware-qca988x-ct-full-htt + $(call Download/ct-firmware-full-htt,QCA988X,) HASH:=5e4285d5c6eee159a25ca14c6ce26022c32380bd7bafaedfc0c5de1510119007 endef -$(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) +$(eval $(call Download,ath10k-firmware-qca988x-ct-full-htt)) QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 @@ -110,12 +110,12 @@ define Download/ath10k-firmware-qca9887-ct endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 -define Download/ath10k-firmware-qca9887-ct-htt - $(call Download/ct-firmware-htt,QCA9887,ath10k-9887) +QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 +define Download/ath10k-firmware-qca9887-ct-full-htt + $(call Download/ct-firmware-full-htt,QCA9887,ath10k-9887) HASH:=dc681b6b1e45956e7c2e418ab05eee5c943d13e775209196d9bd931ff6493935 endef -$(eval $(call Download,ath10k-firmware-qca9887-ct-htt)) +$(eval $(call Download,ath10k-firmware-qca9887-ct-full-htt)) QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 @@ -125,12 +125,12 @@ define Download/ath10k-firmware-qca99x0-ct endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 -define Download/ath10k-firmware-qca99x0-ct-htt - $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) +QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 +define Download/ath10k-firmware-qca99x0-ct-full-htt + $(call Download/ct-firmware-full-htt,QCA99X0,ath10k-10-4b) HASH:=adedcd3d379a910bc3a5257d75f8970e11319f4cd9c1b34440d35821602a8b9c endef -$(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) +$(eval $(call Download,ath10k-firmware-qca99x0-ct-full-htt)) QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 @@ -140,12 +140,12 @@ define Download/ath10k-firmware-qca9984-ct endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 -define Download/ath10k-firmware-qca9984-ct-htt - $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b) +QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 +define Download/ath10k-firmware-qca9984-ct-full-htt + $(call Download/ct-firmware-full-htt,QCA9984,ath10k-9984-10-4b) HASH:=eb8b894cfe0d1aaa87f130bb7fd1815ef07b951c14df8a2ceaeb780df8f640e0 endef -$(eval $(call Download,ath10k-firmware-qca9984-ct-htt)) +$(eval $(call Download,ath10k-firmware-qca9984-ct-full-htt)) QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 @@ -155,12 +155,12 @@ define Download/ath10k-firmware-qca4019-ct endef $(eval $(call Download,ath10k-firmware-qca4019-ct)) -QCA4019_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 -define Download/ath10k-firmware-qca4019-ct-htt - $(call
[PATCH 19.07 8/8] ath10k-ct-firmware: update firmware images
From: Michael Yartys Not a large change from last time, but should fix at least one rare wave-2 crash. The htt-mgt-community builds are trimmed for supporting lots of stations (typically 150+ stations per radio). Tested on Netgear R7800. Signed-off-by: Michael Yartys Signed-off-by: Álvaro Fernández Rojas (cherry picked from commit 91aab77bf1ce91b0e60e720eb147c94a02c1f2fd) Tested-by: Baptiste Jonglez [Archer C6 v2: qca9888-ct] --- package/firmware/ath10k-ct-firmware/Makefile | 60 ++-- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/package/firmware/ath10k-ct-firmware/Makefile b/package/firmware/ath10k-ct-firmware/Makefile index 18370b7d85..c298f80186 100644 --- a/package/firmware/ath10k-ct-firmware/Makefile +++ b/package/firmware/ath10k-ct-firmware/Makefile @@ -1,8 +1,8 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-ct-firmware -PKG_VERSION:=2020-04-24 -PKG_RELEASE:=2 +PKG_VERSION:=2020-07-02 +PKG_RELEASE:=1 include $(INCLUDE_DIR)/package.mk @@ -95,14 +95,14 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) HASH:=8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126 endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 +QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019 define Download/ath10k-firmware-qca988x-ct-full-htt $(call Download/ct-firmware-full-htt,QCA988X,) HASH:=a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7 @@ -110,14 +110,14 @@ endef $(eval $(call Download,ath10k-firmware-qca988x-ct-full-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) HASH:=459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 +QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019 define Download/ath10k-firmware-qca9887-ct-full-htt $(call Download/ct-firmware-full-htt,QCA9887,ath10k-9887) HASH:=fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098 @@ -125,90 +125,90 @@ endef $(eval $(call Download,ath10k-firmware-qca9887-ct-full-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42 + HASH:=7dc934f934bc4973c9273a4f22cfead8e26ec6f579647af31b718a860eca0a4b endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 +QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019 define Download/ath10k-firmware-qca99x0-ct-full-htt $(call Download/ct-firmware-full-htt,QCA99X0,ath10k-10-4b) - HASH:=e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc + HASH:=71a27b245a382fe009938d2826d5c97a90dceb10ddf638325268df91837ea302 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-full-htt)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.019 define Download/ath10k-firmware-qca99x0-ct-htt $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) - HASH:=4d4f74afca487d452f244cd48304cf9710d8941eb97a6346a949ed6b6877d657 + HASH:=9ed4fe41e5b0f30172f71ae0fe382dc0aab8aa4f8a898417af4f7ee936575ef6 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) - HASH:=a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1 + HASH:=32d13f432691fe759ded7d027052e925233adb436cd8f729f85ec3d19ccd1dfd endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 +QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019 define Download/ath10k-firmware-qca9984-ct-full-htt $(call Download/ct-firmware-full-htt,QCA9984,ath10k-9984-10-4b) - HASH
[PATCH 19.07 7/8] ath10k-ct-firmware: add htt-mgt variants
From: Álvaro Fernández Rojas For wave-2, there is now a new variant: htt-mgt-community (vs the old full-htt-mgt-community). The non-full one (hence forth 'diet') compiles out a lot of firmware features that ath10k does not use. This saves a lot of resources and lets one configure more stations/vdevs/etc using fwcfg. Signed-off-by: Álvaro Fernández Rojas (cherry picked from commit a882bfce052e78bd344dcbd36efb32acf1340d7a) --- package/firmware/ath10k-ct-firmware/Makefile | 155 ++- 1 file changed, 154 insertions(+), 1 deletion(-) diff --git a/package/firmware/ath10k-ct-firmware/Makefile b/package/firmware/ath10k-ct-firmware/Makefile index 6a35e9c75c..18370b7d85 100644 --- a/package/firmware/ath10k-ct-firmware/Makefile +++ b/package/firmware/ath10k-ct-firmware/Makefile @@ -2,7 +2,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-ct-firmware PKG_VERSION:=2020-04-24 -PKG_RELEASE:=1 +PKG_RELEASE:=2 include $(INCLUDE_DIR)/package.mk @@ -75,6 +75,7 @@ $(eval $(call Download,qca9888-board2)) CT_FIRMWARE_FILE = $(1)-$($(1)_FIRMWARE_FILE_CT) CT_FIRMWARE_FILE_FULL_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_FULL_HTT) +CT_FIRMWARE_FILE_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_HTT) define Download/ct-firmware URL:=https://www.candelatech.com/downloads/$(2) @@ -88,6 +89,12 @@ define Download/ct-firmware-full-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_FULL_HTT) endef +define Download/ct-firmware-htt + URL:=https://www.candelatech.com/downloads/$(2) + FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1)) + URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) +endef + QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) @@ -132,6 +139,13 @@ define Download/ath10k-firmware-qca99x0-ct-full-htt endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-full-htt)) +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018 +define Download/ath10k-firmware-qca99x0-ct-htt + $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) + HASH:=4d4f74afca487d452f244cd48304cf9710d8941eb97a6346a949ed6b6877d657 +endef +$(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) + QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 define Download/ath10k-firmware-qca9984-ct @@ -147,6 +161,13 @@ define Download/ath10k-firmware-qca9984-ct-full-htt endef $(eval $(call Download,ath10k-firmware-qca9984-ct-full-htt)) +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018 +define Download/ath10k-firmware-qca9984-ct-htt + $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b) + HASH:=ee593fb5724d75c372de02ac7894e1630ee9f909fcb2e2bbf17aadef67cb9d43 +endef +$(eval $(call Download,ath10k-firmware-qca9984-ct-htt)) + QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 define Download/ath10k-firmware-qca4019-ct @@ -162,6 +183,13 @@ define Download/ath10k-firmware-qca4019-ct-full-htt endef $(eval $(call Download,ath10k-firmware-qca4019-ct-full-htt)) +QCA4019_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018 +define Download/ath10k-firmware-qca4019-ct-htt + $(call Download/ct-firmware-htt,QCA4019,ath10k-4019-10-4b) + HASH:=51fe06f66365771647d16039cca8b541de3d642c45271977a4cfd433c2c5d45b +endef +$(eval $(call Download,ath10k-firmware-qca4019-ct-htt)) + QCA9888_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 define Download/ath10k-firmware-qca9888-ct @@ -177,6 +205,13 @@ define Download/ath10k-firmware-qca9888-ct-full-htt endef $(eval $(call Download,ath10k-firmware-qca9888-ct-full-htt)) +QCA9888_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018 +define Download/ath10k-firmware-qca9888-ct-htt + $(call Download/ct-firmware-htt,QCA9888,ath10k-9888-10-4b) + HASH:=6c692141155f5bb74c0117553d5d48ff2aaba73bd4d5e90a5044a5e2ec0faab0 +endef +$(eval $(call Download,ath10k-firmware-qca9888-ct-htt)) + define Package/ath10k-ct-firmware-default SECTION:=firmware @@ -232,6 +267,14 @@ $(Package/ath10k-ct-firmware-default) PROVIDES:=ath10k-firmware-qca99x0 DEPENDS:=+!PACKAGE_kmod-ath10k-ct-smallbuffers:kmod-ath10k-ct endef +define Package/ath10k-firmware-qca99x0-ct-htt +$(Package/ath10k-firmware-default) + TITLE:=ath10k CT 10.4 htt-mgt fw for QCA99x0 + SECTION:=firmware + CATEGORY:=Firmware + PROVIDES:=ath10k-firmware-qca99x0 + DEPENDS:=+!PACKAGE_kmod-ath10k-ct-smallbuffers:kmod-ath10k-ct +endef define Package/ath10k-firmware-qca9984-ct $(Package/ath10k-ct-firmware-default) @@ -248,6 +291,14 @@ $(Package/ath10k-ct-firmware-default) PROVIDES:=ath10k-firmware-qca9984 DEPENDS:=+!PACKAGE_kmod-ath10k-ct-smallbuffers:kmod-ath10k-ct endef +define Package/ath10k-firmware-qca9984-ct-htt +$(Package/ath10k-firmware-default) + TITLE:=ath10k CT 10.4 htt-mgt fw for QCA9984 + SECTION:=firmware + CATEGORY:=Firmware + PROVIDES:=ath10k-firmware-qca9984 +
[PATCH 19.07 3/8] ath10k-firmware: update ath10k-ct firmware images
From: Álvaro Fernández Rojas Release notes for 017: Wave-1: * March 19, 2020: Fix problem where power-save was not enabled when going off-channel to scan. The problem was a boolean logic inversion in the chmgr code, a regression I introduced a long time ago. * March 19, 2020: When scanning only on current working channel, do not bother with disable/enable powersave. This should make an on-channel scan less obtrusive than it was previously. * March 23, 2020: Fix channel-mgr use-after-free problem that caused crashes in some cases. The crash was exacerbated by recent power-save changes. * March 23, 2020: Fix station-mode power-save related crash: backported the fix from 10.2 QCA firmware. * March 23, 2020: Attempt to better clean up power-save objects and state, especially in station mode. Release notes for 016: Wave-1 changes, some debugging code for a crash someone reported, plus: * February 28, 2020: Fix custom-tx path when sending in 0x0 for rate-code. Have tries == 0 mean one try but NO-ACK (similar to how wave-2 does it). wave-2: * Fixed some long-ago regressions related to powersave and/or multicast. Maybe fix some additional multicast and/or tx-scheduling bugs. Signed-off-by: Álvaro Fernández Rojas Acked-by: Petr Štetiar (cherry picked from commit 84f4a783c6987fd9d67c089a76e2f90b7491f446) --- package/firmware/ath10k-firmware/Makefile | 48 +++ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index af883e6f03..6eb7cf9a99 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -64,92 +64,92 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.015 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) - HASH:=a3a760d0d72707feffa496b6d2266bd9195f09806553b36420b60c0f12b8b87e + HASH:=2f0bf766e400a4c5726e77b128eb8c141ebaa778526fe2c7c5083f3b17659dbf endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 define Download/ath10k-firmware-qca988x-ct-htt $(call Download/ct-firmware-htt,QCA988X,) - HASH:=3114a54103d2b492fa1ef903769721f59953c829020d62502a1ec411ab4146d5 + HASH:=5e4285d5c6eee159a25ca14c6ce26022c32380bd7bafaedfc0c5de1510119007 endef $(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.015 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) - HASH:=71e8b76dfd7c786d2f57bb7df207dcd13a91d3b492cfbd28916f084d0d1bb5e7 + HASH:=4fa30e0e1972ca3b06225a731df0f93a1b73ac67fea5bf54bb55dea3bbc0da6a endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 define Download/ath10k-firmware-qca9887-ct-htt $(call Download/ct-firmware-htt,QCA9887,ath10k-9887) - HASH:=b085e5d2239727b72bc647a76864431b8ac48438e6a33b1d55edc468f6ff + HASH:=dc681b6b1e45956e7c2e418ab05eee5c943d13e775209196d9bd931ff6493935 endef $(eval $(call Download,ath10k-firmware-qca9887-ct-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=edebe2f6f169cdd05c81a8a78156fb3426a66f415e7946af2ae4b7310fca5fe3 + HASH:=289ea845d4bbae6f36b3af2a13a5eaa07097f52d10f7b7306cfc9e2dd394f889 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 define Download/ath10k-firmware-qca99x0-ct-htt $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) - HASH:=1ef67fb07da9082886e4dd554dfc19256e10b500faf9e4b2a5774d0238130bae + HASH:=adedcd3d379a910bc3a5257d75f8970e11319f4cd9c1b34440d35821602a8b9c endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) -
[PATCH 19.07 6/8] ath10k-ct-firmware: update firmware images
From: Álvaro Fernández Rojas No release notes this time. Signed-off-by: Álvaro Fernández Rojas (cherry picked from commit 06f510df6e2aa0b1e40124bbd758672458d01482) --- package/firmware/ath10k-ct-firmware/Makefile | 52 ++-- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/package/firmware/ath10k-ct-firmware/Makefile b/package/firmware/ath10k-ct-firmware/Makefile index 959bfa975b..6a35e9c75c 100644 --- a/package/firmware/ath10k-ct-firmware/Makefile +++ b/package/firmware/ath10k-ct-firmware/Makefile @@ -1,8 +1,8 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-ct-firmware -PKG_VERSION:=2020-03-25 -PKG_RELEASE:=2 +PKG_VERSION:=2020-04-24 +PKG_RELEASE:=1 include $(INCLUDE_DIR)/package.mk @@ -88,92 +88,92 @@ define Download/ct-firmware-full-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_FULL_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) - HASH:=2f0bf766e400a4c5726e77b128eb8c141ebaa778526fe2c7c5083f3b17659dbf + HASH:=8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126 endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 +QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 define Download/ath10k-firmware-qca988x-ct-full-htt $(call Download/ct-firmware-full-htt,QCA988X,) - HASH:=5e4285d5c6eee159a25ca14c6ce26022c32380bd7bafaedfc0c5de1510119007 + HASH:=a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7 endef $(eval $(call Download,ath10k-firmware-qca988x-ct-full-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.017 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) - HASH:=4fa30e0e1972ca3b06225a731df0f93a1b73ac67fea5bf54bb55dea3bbc0da6a + HASH:=459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 +QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 define Download/ath10k-firmware-qca9887-ct-full-htt $(call Download/ct-firmware-full-htt,QCA9887,ath10k-9887) - HASH:=dc681b6b1e45956e7c2e418ab05eee5c943d13e775209196d9bd931ff6493935 + HASH:=fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098 endef $(eval $(call Download,ath10k-firmware-qca9887-ct-full-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=289ea845d4bbae6f36b3af2a13a5eaa07097f52d10f7b7306cfc9e2dd394f889 + HASH:=cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 +QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 define Download/ath10k-firmware-qca99x0-ct-full-htt $(call Download/ct-firmware-full-htt,QCA99X0,ath10k-10-4b) - HASH:=adedcd3d379a910bc3a5257d75f8970e11319f4cd9c1b34440d35821602a8b9c + HASH:=e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-full-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) - HASH:=8175be5b3946bddc042be018ff7713e67b41b59374ef4cdd183185b59274c91a + HASH:=a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1 endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 +QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 define Download/ath10k-firmware-qca9984-ct-full-htt $(call Download/ct-firmware-full-htt,QCA9984,ath10k-9984-10-4b) - HASH:=eb8b894cfe0d1aaa87f130bb7fd1815ef07b951c14df8a2ceaeb780df8f640e0 + HASH:=96060227e372b3b210badccbe6b0bd75d9a35335a7a0f2966964e9e89f66b00f endef $(eval $(call Download,ath10k-firmware-qca9984-ct-full-htt)) -QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.017 +QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 define Download/ath10k-firmware-qca4019-ct $(call Download/ct-firmware,QCA4019,ath10k-4019-10-4b) -
[PATCH 19.07 2/8] ath10k-firmware: update ath10k-ct firmware
From: Michael Yartys This supports better per-chain noise floor reporting, which in turn allows for better RSSI reporting in the driver. Wave-2 fixes a long-standing rate-ctrl problem when connected to xbox (and probably other devices). Wave-2 has fix for crash likely related to rekeying. Wave-1 has some debugging code added where a user reported a crash. Tested-by: Stefan Lippers-Hollmann [ipq806x+qca9984,ipq4019+qca9986] Signed-off-by: Michael Yartys (cherry picked from commit 18622638831707038556b9b8bd5a0b4d4a53ce53) --- package/firmware/ath10k-firmware/Makefile | 48 +++ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 9f1e7e676b..af883e6f03 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -64,92 +64,92 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.014 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.015 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) - HASH:=19db86003509dedb8ace339c183813ca637d65af24d00666411d1590efe33e13 + HASH:=a3a760d0d72707feffa496b6d2266bd9195f09806553b36420b60c0f12b8b87e endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 define Download/ath10k-firmware-qca988x-ct-htt $(call Download/ct-firmware-htt,QCA988X,) - HASH:=454e67dab545e720369a07be2fee16de008c76db4ab3119e7760bf9f7504c066 + HASH:=3114a54103d2b492fa1ef903769721f59953c829020d62502a1ec411ab4146d5 endef $(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.014 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.015 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) - HASH:=b3c738328427e124701a5735d65cde0f60e4172ae5bc23b00e5b16df7995dbd4 + HASH:=71e8b76dfd7c786d2f57bb7df207dcd13a91d3b492cfbd28916f084d0d1bb5e7 endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 define Download/ath10k-firmware-qca9887-ct-htt $(call Download/ct-firmware-htt,QCA9887,ath10k-9887) - HASH:=4432ccee23133bbaa4a5552e50a1e7e889b257362603e05530e751b67c29b7b5 + HASH:=b085e5d2239727b72bc647a76864431b8ac48438e6a33b1d55edc468f6ff endef $(eval $(call Download,ath10k-firmware-qca9887-ct-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=9a908f743604a468b651a5f73c49e6b0ba11a05c677b9726fbf041b849d88b25 + HASH:=edebe2f6f169cdd05c81a8a78156fb3426a66f415e7946af2ae4b7310fca5fe3 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 define Download/ath10k-firmware-qca99x0-ct-htt $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) - HASH:=800dd0816702aaca75f3eb5436c2ea724a6c24833838cd54399b9286b4d4fbe8 + HASH:=1ef67fb07da9082886e4dd554dfc19256e10b500faf9e4b2a5774d0238130bae endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) - HASH:=a8b12dba478e8c9d4a215f82324382c7554a900e83c31775f8511af84e59fef7 + HASH:=c2f04da3285aad37baef9c37c9905a31927175dd234cd4378fd56c106e5c9379 endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 define Download/ath10k-firmware-qca9984-ct-htt $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b) - HASH:=d185651b5d3d1f0082720bc6c2bbe43b2a00cdb6333403fac9336a720b1d93ae + HASH:=0c9ede1036750d68885e6481fa84f3cb72192b8440b47719344f7327a030f05d endef $(eval $(call Download,ath10k-firmware-qca9984-ct-htt)) -QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 +QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.015 define Download/ath10k-firmware-qca4019-ct $(call Download/ct-firmware,QCA4019,ath10k-4019-10-4b) -
[PATCH 19.07 1/8] ath10k-firmware: update Candela Tech firmware images
From: Stefan Lippers-Hollmann The release notes since last time for wave-1: * No changes to wave-1, but I make a version .014 copy anyway to keep the makefile in sync. The release notes since last time for wave-2: * December 16, 2019: Wave-2 has a fix to make setting txpower work better. Before setting the power was ignored at least some of the time (it also appeared to work mostly, so I guess it was being correctly set in other ways). Signed-off-by: Stefan Lippers-Hollmann (cherry picked from commit 65982642668e859540b21c2bd3bf907493df830a) --- package/firmware/ath10k-firmware/Makefile | 40 +++ 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index b6a7c94e89..9f1e7e676b 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -64,14 +64,14 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.013 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.014 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) HASH:=19db86003509dedb8ace339c183813ca637d65af24d00666411d1590efe33e13 endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.013 +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 define Download/ath10k-firmware-qca988x-ct-htt $(call Download/ct-firmware-htt,QCA988X,) HASH:=454e67dab545e720369a07be2fee16de008c76db4ab3119e7760bf9f7504c066 @@ -79,14 +79,14 @@ endef $(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.013 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.014 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) HASH:=b3c738328427e124701a5735d65cde0f60e4172ae5bc23b00e5b16df7995dbd4 endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.013 +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 define Download/ath10k-firmware-qca9887-ct-htt $(call Download/ct-firmware-htt,QCA9887,ath10k-9887) HASH:=4432ccee23133bbaa4a5552e50a1e7e889b257362603e05530e751b67c29b7b5 @@ -94,62 +94,62 @@ endef $(eval $(call Download,ath10k-firmware-qca9887-ct-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.013 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=6fa74a3fc87cba97dbc4a7213b760f8d997cd9c5f11900d47d387b23764cf20a + HASH:=9a908f743604a468b651a5f73c49e6b0ba11a05c677b9726fbf041b849d88b25 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 define Download/ath10k-firmware-qca99x0-ct-htt $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) - HASH:=68e92820c51270eba4f68b24654c4a9408902b2600762b70204f4cb5419bb714 + HASH:=800dd0816702aaca75f3eb5436c2ea724a6c24833838cd54399b9286b4d4fbe8 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.013 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) - HASH:=08aeb883bd2d9258e8f1907cca8a0d2eda1c559a66e228dadffd6798f6877c7d + HASH:=a8b12dba478e8c9d4a215f82324382c7554a900e83c31775f8511af84e59fef7 endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 define Download/ath10k-firmware-qca9984-ct-htt $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b) - HASH:=38ed59a2b3c66c10926706a21ae2d3aeaf83e589f19345a8f48d6520522e4fde + HASH:=d185651b5d3d1f0082720bc6c2bbe43b2a00cdb6333403fac9336a720b1d93ae endef $(eval $(call Download,ath10k-firmware-qca9984-ct-htt)) -QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.013 +QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.014 define Download/ath10k-firmware-qca4019-ct $(call Download/ct-firmware,QCA4019,ath10k-4019-10-4b) - HASH:=feca75fe89af9a3e998047f85ff3428676f4d574b770d51773bb419d0dd98e5a + HASH:=4c2e48835219f420b18dc58e31d1387dae0da70d8170c3fc5e7bce39c06cf355 endef
Kr00k vulnerabilities / CVE-2019-15126 / CVE-2020-3702
Hi,
Detailed information about the kr00k vulnerabilities is hard to find.
Here is a WIP recap about it and whether/how OpenWrt is vulnerable.
It's missing lots of information, please contribute if you have any.
I will summarize the results in a wiki page afterwards.
Kr00k v1 (CVE-2019-15126)
=
It affects Broadcom / Cypress chips.
https://www.eset.com/int/kr00k/
https://www.welivesecurity.com/2020/02/26/krook-serious-vulnerability-affected-encryption-billion-wifi-devices/
Kr00k v2 (CVE-2020-3702)
It affects Mediatek / Qualcomm chips.
https://www.securityweek.com/qualcomm-mediatek-wi-fi-chips-vulnerable-kr00k-attacks
https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
Other links
===
Repro script: https://github.com/eset/malware-research/tree/master/kr00k
OpenWrt bug report: https://bugs.openwrt.org/index.php?do=details_id=3300
Patch status of mac80211
Three fixes are mentioned here:
https://www.mail-archive.com/ath10k@lists.infradead.org/msg12635.html
The fixes are included in linux v5.6. Two of them were backported in 4.19.X
(a4f68ecf733635 and d34dce8d3dbfa7) and released in 4.19.114.
I didn't find a 4.19 backport for the last one ("mac80211: drop data frames
without key on encrypted links")
Assuming the three fixes are enough:
- OpenWrt master: OK (we are using mac80211 5.8)
- OpenWrt 19.07: OK for 2/3 fixes (19.07.3 uses mac80211 4.19.120)
- OpenWrt 18.06: NOK (mac80211 version is 2017-11-01, I'm not sure where
it comes from but it's definitely 3 years old)
Patch status of ath9k
=
??
Patch status of ath10k
==
??
Patch status for mediatek chips
===
??
Patch status for broadcom chips
===
??
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH opkg 4/5] download: purge cached packages that have incorrect checksum
From: Baptiste Jonglez
Before using a package from the cache, verify its size and checksum
against a package index, and delete the package from the cache if they
don't match. The install process will then proceed to download the
"fixed" package as usual.
This allows to cope with remote packages that are rebuilt while keeping
the same version number as packages in the local cache. With this change,
any outdated package in the local cache will be purged and the new version
will be downloaded instead.
This is mostly useful when running opkg on the host (e.g. in the
imagebuilder). When running on a device, no cache is configured by
default, so this change does nothing in that case.
Fixes: FS#2690
Signed-off-by: Baptiste Jonglez
---
libopkg/opkg_download.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libopkg/opkg_download.c b/libopkg/opkg_download.c
index 175282c..3b79856 100644
--- a/libopkg/opkg_download.c
+++ b/libopkg/opkg_download.c
@@ -263,6 +263,8 @@ int opkg_download_pkg(pkg_t * pkg, const char *dir)
char *stripped_filename;
char *urlencoded_path;
char *filename;
+ char *cache_name;
+ char *cache_location;
if (pkg->src == NULL) {
opkg_msg(ERROR,
@@ -296,6 +298,23 @@ int opkg_download_pkg(pkg_t * pkg, const char *dir)
sprintf_alloc(_filename, "%s/%s", dir, stripped_filename);
pkg_set_string(pkg, PKG_LOCAL_FILENAME, local_filename);
+ /* Invalidate/remove cached package if it has an incorrect checksum. */
+ if (conf->cache) {
+ cache_name = get_cache_filename(local_filename);
+ sprintf_alloc(_location, "%s/%s", conf->cache,
cache_name);
+ free(cache_name);
+ if (file_exists(cache_location)) {
+ err = opkg_verify_integrity(pkg, cache_location);
+ if (err) {
+ opkg_msg(NOTICE,
+"Removing %s from cache because it has
incorrect checksum.\n",
+pkg->name);
+ unlink(cache_location);
+ }
+ }
+ free(cache_location);
+ }
+
err = opkg_download_cache(url, local_filename);
free(url);
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH opkg 0/5] Purge packages from cache when they have incorrect checksum
From: Baptiste Jonglez The motivation of this patch series is to fix FS#2690. Because packages are continuously rebuilt, the ImageBuilder ends up with old packages in its cache, and fails because checksums don't match with the new package index from the download server. The approach to solve this problem is the following. Before using a package from the cache, verify its size and checksum against the package index, and delete the package from the cache if they don't match. The install process will then proceed to download the "fixed" package as usual. The main patch is "download: purge cached packages that have incorrect checksum". The other ones are either cleanup or refactoring to prepare for the main change. Baptiste Jonglez (5): download: remove compatibility with old cache naming scheme libopkg: factor out checksum and size verification download: factor out the logic for building cache filenames download: purge cached packages that have incorrect checksum opkg_verify_integrity: better logging and error conditions libopkg/opkg_download.c | 123 libopkg/opkg_download.h | 1 + libopkg/opkg_install.c | 76 +++-- 3 files changed, 108 insertions(+), 92 deletions(-) -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH opkg 1/5] download: remove compatibility with old cache naming scheme
From: Baptiste Jonglez
A long time ago, the name of cached files was derived from the source URL.
This was changed in 2011 with d46db43e21 ("Don't include the source URI in
the cached filename.")
Some compatibility code was left behind: even today, we are still trying
to read from the old filename. The goal of this compatibility code was to
account for existing caches that still had files with the old naming
scheme.
More than 9 years later, it is safe to remove this compatibility code.
It simplifies the download code and avoids a useless disk access.
Signed-off-by: Baptiste Jonglez
---
libopkg/opkg_download.c | 36 +++-
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/libopkg/opkg_download.c b/libopkg/opkg_download.c
index e970506..97df37f 100644
--- a/libopkg/opkg_download.c
+++ b/libopkg/opkg_download.c
@@ -131,8 +131,7 @@ opkg_download(const char *src, const char *dest_file_name,
static int
opkg_download_cache(const char *src, const char *dest_file_name)
{
- char *cache_name = xstrdup(src);
- char *cache_location, *p;
+ char *cache_name, *cache_location;
int err = 0;
if (!conf->cache || str_starts_with(src, "file:")) {
@@ -146,32 +145,19 @@ opkg_download_cache(const char *src, const char
*dest_file_name)
goto out1;
}
- for (p = cache_name; *p; p++)
- if (*p == '/')
- *p = ','; /* looks nicer than | or # */
-
+ char *filename = strrchr(dest_file_name, '/');
+ if (filename)
+ cache_name = xstrdup(filename + 1); // strip leading '/'
+ else
+ cache_name = xstrdup(dest_file_name);
sprintf_alloc(_location, "%s/%s", conf->cache, cache_name);
if (file_exists(cache_location))
opkg_msg(NOTICE, "Copying %s.\n", cache_location);
else {
- /* cache file with funky name not found, try simple name */
- free(cache_name);
- char *filename = strrchr(dest_file_name, '/');
- if (filename)
- cache_name = xstrdup(filename + 1); // strip
leading '/'
- else
- cache_name = xstrdup(dest_file_name);
- free(cache_location);
- sprintf_alloc(_location, "%s/%s", conf->cache,
- cache_name);
- if (file_exists(cache_location))
- opkg_msg(NOTICE, "Copying %s.\n", cache_location);
- else {
- err = opkg_download(src, cache_location, 0);
- if (err) {
- (void)unlink(cache_location);
- goto out2;
- }
+ err = opkg_download(src, cache_location, 0);
+ if (err) {
+ (void)unlink(cache_location);
+ goto out2;
}
}
@@ -179,8 +165,8 @@ opkg_download_cache(const char *src, const char
*dest_file_name)
out2:
free(cache_location);
-out1:
free(cache_name);
+out1:
return err;
}
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH opkg 5/5] opkg_verify_integrity: better logging and error conditions
From: Baptiste Jonglez
The function now always returns an error if size/checksum don't match: we
let the caller decide what to do with the result.
In addition, most of the logging is also moved to the caller. We just
keep logging for unexpected errors and a bit of debug at loglevel INFO.
Signed-off-by: Baptiste Jonglez
---
libopkg/opkg_download.c | 49 ++---
libopkg/opkg_install.c | 11 -
2 files changed, 26 insertions(+), 34 deletions(-)
diff --git a/libopkg/opkg_download.c b/libopkg/opkg_download.c
index 3b79856..a9ebd58 100644
--- a/libopkg/opkg_download.c
+++ b/libopkg/opkg_download.c
@@ -55,16 +55,11 @@ int opkg_verify_integrity(pkg_t *pkg, const char *filename)
pkg_expected_size = pkg_get_int(pkg, PKG_SIZE);
if (pkg_expected_size > 0 && pkg_stat.st_size != pkg_expected_size) {
- if (!conf->force_checksum) {
- opkg_msg(ERROR,
-"Package size mismatch: %s is %lld bytes,
expecting %lld bytes\n",
-pkg->name, (long long int)pkg_stat.st_size,
pkg_expected_size);
- return -1;
- } else {
- opkg_msg(NOTICE,
-"Ignored %s size mismatch.\n",
-pkg->name);
- }
+ opkg_msg(INFO,
+"Package size mismatch: %s is %lld bytes, expecting
%lld bytes\n",
+pkg->name, (long long int)pkg_stat.st_size,
pkg_expected_size);
+ err = -1;
+ goto out;
}
/* Check for md5 values */
@@ -72,17 +67,11 @@ int opkg_verify_integrity(pkg_t *pkg, const char *filename)
if (pkg_md5) {
file_md5 = file_md5sum_alloc(filename);
if (file_md5 && strcmp(file_md5, pkg_md5)) {
- if (!conf->force_checksum) {
- opkg_msg(ERROR, "Package %s md5sum mismatch. "
-"Either the opkg or the package index
are corrupt. "
-"Try 'opkg update'.\n", pkg->name);
- free(file_md5);
- return -1;
- } else {
- opkg_msg(NOTICE,
-"Ignored %s md5sum mismatch.\n",
-pkg->name);
- }
+ opkg_msg(INFO, "Package %s md5sum mismatch.\n",
+pkg->name);
+ err = -1;
+ free(file_md5);
+ goto out;
}
if (file_md5)
free(file_md5);
@@ -93,23 +82,17 @@ int opkg_verify_integrity(pkg_t *pkg, const char *filename)
if (pkg_sha256) {
file_sha256 = file_sha256sum_alloc(filename);
if (file_sha256 && strcmp(file_sha256, pkg_sha256)) {
- if (!conf->force_checksum) {
- opkg_msg(ERROR,
-"Package %s sha256sum mismatch. "
-"Either the opkg or the package index
are corrupt. "
-"Try 'opkg update'.\n", pkg->name);
- free(file_sha256);
- return -1;
- } else {
- opkg_msg(NOTICE,
-"Ignored %s sha256sum mismatch.\n",
-pkg->name);
- }
+ opkg_msg(INFO, "Package %s sha256sum mismatch.\n",
+pkg->name);
+ err = -1;
+ free(file_sha256);
+ goto out;
}
if (file_sha256)
free(file_sha256);
}
+out:
return err;
}
diff --git a/libopkg/opkg_install.c b/libopkg/opkg_install.c
index e8eccf8..da55b48 100644
--- a/libopkg/opkg_install.c
+++ b/libopkg/opkg_install.c
@@ -1363,9 +1363,18 @@ int opkg_install_pkg(pkg_t * pkg, int from_upgrade)
}
#endif
+ /* Check integrity (size, checksums) */
err = opkg_verify_integrity(pkg, local_filename);
- if (err)
+ if (err && !conf->force_checksum) {
+ opkg_msg(ERROR, "Checksum or size mismatch for package %s. "
+"Either the opkg or the package index are corrupt. "
+"Try 'opkg update'.\n"
[PATCH opkg 3/5] download: factor out the logic for building cache filenames
From: Baptiste Jonglez
If we want to access files in the cache from multiple functions, it is
necessary to have a single source of truth regarding the naming of files
in the cache.
Signed-off-by: Baptiste Jonglez
---
libopkg/opkg_download.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/libopkg/opkg_download.c b/libopkg/opkg_download.c
index f7c2f88..175282c 100644
--- a/libopkg/opkg_download.c
+++ b/libopkg/opkg_download.c
@@ -206,6 +206,17 @@ opkg_download(const char *src, const char *dest_file_name,
return err;
}
+static char* get_cache_filename(const char *dest_file_name)
+{
+ char *cache_name;
+ char *filename = strrchr(dest_file_name, '/');
+ if (filename)
+ cache_name = xstrdup(filename + 1); // strip leading '/'
+ else
+ cache_name = xstrdup(dest_file_name);
+ return cache_name;
+}
+
static int
opkg_download_cache(const char *src, const char *dest_file_name)
{
@@ -223,11 +234,7 @@ opkg_download_cache(const char *src, const char
*dest_file_name)
goto out1;
}
- char *filename = strrchr(dest_file_name, '/');
- if (filename)
- cache_name = xstrdup(filename + 1); // strip leading '/'
- else
- cache_name = xstrdup(dest_file_name);
+ cache_name = get_cache_filename(dest_file_name);
sprintf_alloc(_location, "%s/%s", conf->cache, cache_name);
if (file_exists(cache_location))
opkg_msg(NOTICE, "Copying %s.\n", cache_location);
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
