Re: [PATCH iwinfo] lib: report byte counters as 64 bit values
+Cc a few devs that have worked on iwinfo recently.
Hi,
could somebody take a look my patches [0] to fix an overflow of
per-association packet counters after two GiB [1]?
Thanks,
Thomas
[0] https://lists.openwrt.org/pipermail/openwrt-devel/2023-May/041056.html
https://lists.openwrt.org/pipermail/openwrt-devel/2023-May/041096.html
https://lists.openwrt.org/pipermail/openwrt-devel/2023-May/041055.html
[1] https://github.com/openwrt/luci/issues/6210
On 2023-05-15 16:54:27+0200, Thomas Weißschuh wrote:
> The 32bit counter can only count to 4GiB before wrapping.
> Switching to the 64bit variant avoids this issue.
>
> In practice some users are interpreting the counter values as signed
> integer bringing down the usable range for 32bit values down to only
> 2GiB.
>
> Signed-off-by: Thomas Weißschuh
> ---
> include/iwinfo.h | 4 ++--
> iwinfo_nl80211.c | 12 ++--
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index eae99302704a..b50de69f49ca 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -240,8 +240,8 @@ struct iwinfo_assoclist_entry {
> uint64_t rx_drop_misc;
> struct iwinfo_rate_entry rx_rate;
> struct iwinfo_rate_entry tx_rate;
> - uint32_t rx_bytes;
> - uint32_t tx_bytes;
> + uint64_t rx_bytes;
> + uint64_t tx_bytes;
> uint32_t tx_retries;
> uint32_t tx_failed;
> uint64_t t_offset;
> diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> index 50bb8f03c2fd..1e0a0c77dc39 100644
> --- a/iwinfo_nl80211.c
> +++ b/iwinfo_nl80211.c
> @@ -1554,6 +1554,8 @@ static int nl80211_fill_signal_cb(struct nl_msg *msg,
> void *arg)
> [NL80211_STA_INFO_INACTIVE_TIME] = { .type = NLA_U32},
> [NL80211_STA_INFO_RX_BYTES] = { .type = NLA_U32},
> [NL80211_STA_INFO_TX_BYTES] = { .type = NLA_U32},
> + [NL80211_STA_INFO_RX_BYTES64]= { .type = NLA_U64},
> + [NL80211_STA_INFO_TX_BYTES64]= { .type = NLA_U64},
> [NL80211_STA_INFO_RX_PACKETS]= { .type = NLA_U32},
> [NL80211_STA_INFO_TX_PACKETS]= { .type = NLA_U32},
> [NL80211_STA_INFO_SIGNAL]= { .type = NLA_U8 },
> @@ -2214,6 +2216,8 @@ static int nl80211_get_assoclist_cb(struct nl_msg *msg,
> void *arg)
> [NL80211_STA_INFO_SIGNAL_AVG]= { .type = NLA_U8 },
> [NL80211_STA_INFO_RX_BYTES] = { .type = NLA_U32},
> [NL80211_STA_INFO_TX_BYTES] = { .type = NLA_U32},
> + [NL80211_STA_INFO_RX_BYTES64]= { .type = NLA_U64},
> + [NL80211_STA_INFO_TX_BYTES64]= { .type = NLA_U64},
> [NL80211_STA_INFO_TX_RETRIES]= { .type = NLA_U32},
> [NL80211_STA_INFO_TX_FAILED] = { .type = NLA_U32},
> [NL80211_STA_INFO_CONNECTED_TIME]= { .type = NLA_U32},
> @@ -2277,10 +2281,14 @@ static int nl80211_get_assoclist_cb(struct nl_msg
> *msg, void *arg)
> sinfo[NL80211_STA_INFO_TX_BITRATE],
> rate_policy))
> nl80211_parse_rateinfo(rinfo, >tx_rate);
>
> - if (sinfo[NL80211_STA_INFO_RX_BYTES])
> + if (sinfo[NL80211_STA_INFO_RX_BYTES64])
> + e->rx_bytes =
> nla_get_u64(sinfo[NL80211_STA_INFO_RX_BYTES64]);
> + else if (sinfo[NL80211_STA_INFO_RX_BYTES])
> e->rx_bytes =
> nla_get_u32(sinfo[NL80211_STA_INFO_RX_BYTES]);
>
> - if (sinfo[NL80211_STA_INFO_TX_BYTES])
> + if (sinfo[NL80211_STA_INFO_TX_BYTES64])
> + e->tx_bytes =
> nla_get_u64(sinfo[NL80211_STA_INFO_TX_BYTES64]);
> + else if (sinfo[NL80211_STA_INFO_TX_BYTES])
> e->tx_bytes =
> nla_get_u32(sinfo[NL80211_STA_INFO_TX_BYTES]);
>
> if (sinfo[NL80211_STA_INFO_TX_RETRIES])
>
> base-commit: b3888b29535a92584524e14aadf25fcb85e7fed2
> --
> 2.40.1
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: typo in module config
Il giorno ven 23 giu 2023 alle ore 15:58 Koen Vandeputte ha scritto: > > Hi Yousong, > > By reading some mk files I noticed your commit: > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4f443c885dede3331b969e6265a41a0ff1e3059a > > within netfilter.mk: > > +define KernelPackage/nf-socket > .. > + KCONFIG:= $(KCOFNIG_NF_SOCKET) > > +define KernelPackage/nf-tproxy > .. > + KCONFIG:= $(KCOFNIG_NF_TPROXY) > > > Looks like it contains 2 typos? :) --> KCOFNIG > I can quickly fix them... Do you know by chance if also 23.05 is also affected? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
typo in module config
Hi Yousong, By reading some mk files I noticed your commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4f443c885dede3331b969e6265a41a0ff1e3059a within netfilter.mk: +define KernelPackage/nf-socket .. + KCONFIG:= $(KCOFNIG_NF_SOCKET) +define KernelPackage/nf-tproxy .. + KCONFIG:= $(KCOFNIG_NF_TPROXY) Looks like it contains 2 typos? :) --> KCOFNIG Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH firmware-utils] add dlink-sge-image for D-Link devices by SGE
This tool will encrypt/decrypt factory images requiring the "SHRS" header
e.g. COVR-C1200, COVR-P2500, COVR-X1860, DIR-878, DIR-882, ...
Encryption is loosely based on a series of blogposts by ricksanchez [1]
and the provided code [2], as well as patches to qca-uboot found in the
GPL tarball released for D-Link COVR-P2500 Rev. A1 [3].
Further scripts (e.g. /lib/upgrade/) and keys were found in the GPL tarball
and/or rootfs of COVR-C1200 (the devices are based on OpenWrt Chaos Calmer
and failsafe can be entered by pressing 'f' on the serial console during
boot, allowing to access the file system of the running device).
For newer devices like COVR-X1860 and DIR-X3260, an updated method of
vendor key derivation is implemented based on enk.txt from the GPL release.
[1]
https://0x00sec.org/t/breaking-the-d-link-dir3060-firmware-encryption-recon-part-1/21943
[2] https://github.com/0xricksanchez/dlink-decrypt
[3] https://tsd.dlink.com.tw/GPL.asp
Signed-off-by: Sebastian Schaper
Tested-By: Alan Luck
---
This patch is based on previous work on PR #4174, migrated to OpenSSL EVP API
and extended to include support for newer devices like COVR-X1860.
The intermediate development stages are tracked at
https://github.com/s-2/firmware-utils/commits/dlink-sge-image
and the forum thread
https://forum.openwrt.org/t/add-support-for-d-link-covr-x1860/161862
CMakeLists.txt| 1 +
src/dlink-sge-image.c | 510 ++
src/dlink-sge-image.h | 349 +
3 files changed, 860 insertions(+)
create mode 100644 src/dlink-sge-image.c
create mode 100644 src/dlink-sge-image.h
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c1750d478c..d7d4ed2a7b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -40,6 +40,7 @@ FW_UTIL(buffalo-tftp src/buffalo-lib.c "" "")
FW_UTIL(cros-vbutil "" "" "${OPENSSL_CRYPTO_LIBRARIES}")
FW_UTIL(dgfirmware "" "" "")
FW_UTIL(dgn3500sum "" "" "")
+FW_UTIL(dlink-sge-image "" "" "${OPENSSL_CRYPTO_LIBRARIES}")
FW_UTIL(dns313-header "" "" "")
FW_UTIL(edimax_fw_header "" "" "")
FW_UTIL(encode_crc "" "" "")
diff --git a/src/dlink-sge-image.c b/src/dlink-sge-image.c
new file mode 100644
index 00..9b567f43ff
--- /dev/null
+++ b/src/dlink-sge-image.c
@@ -0,0 +1,510 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (C) 2023 Sebastian Schaper
+ *
+ * This tool encrypts factory images for certain D-Link Devices
+ * manufactured by SGE / T, e.g. COVR-C1200, COVR-P2500, DIR-882, ...
+ *
+ * Usage:
+ * ./dlink-sge-image DEVICE_MODEL infile outfile [-d: decrypt]
+ *
+ */
+
+#include "dlink-sge-image.h"
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define BUFSIZE4096
+
+#define HEAD_MAGIC "SHRS"
+#define HEAD_MAGIC_LEN 4
+#define SHA512_DIGEST_LENGTH 64
+#define RSA_KEY_LENGTH_BYTES 512
+#define AES_BLOCK_SIZE 16
+#define HEADER_LEN 1756
+
+unsigned char aes_iv[AES_BLOCK_SIZE];
+
+unsigned char readbuf[BUFSIZE];
+unsigned char encbuf[BUFSIZE];
+
+unsigned int read_bytes;
+unsigned long read_total;
+unsigned int i;
+
+unsigned char vendor_key[AES_BLOCK_SIZE];
+BIO *rsa_private_bio;
+const EVP_CIPHER *aes128;
+EVP_CIPHER_CTX *aes_ctx;
+
+FILE *input_file;
+FILE *output_file;
+
+int pass_cb(char *buf, int size, int rwflag, void *u)
+{
+char *tmp = "12345678";
+size_t len = strlen(tmp);
+
+if (len > size)
+len = size;
+memcpy(buf, tmp, len);
+return len;
+}
+
+void image_encrypt(void)
+{
+ char buf[HEADER_LEN];
+ const EVP_MD *sha512;
+ EVP_MD_CTX *digest_before;
+ EVP_MD_CTX *digest_post;
+ EVP_MD_CTX *digest_vendor;
+ EVP_PKEY *signing_key;
+ EVP_PKEY_CTX *rsa_ctx;
+ uint32_t payload_length_before, pad_len, sizebuf;
+ unsigned char md_before[SHA512_DIGEST_LENGTH];
+ unsigned char md_post[SHA512_DIGEST_LENGTH];
+ unsigned char md_vendor[SHA512_DIGEST_LENGTH];
+ unsigned char sigret[RSA_KEY_LENGTH_BYTES];
+ size_t siglen;
+ char footer[] = {0x00, 0x00, 0x00, 0x00, 0x30};
+
+ // seek to position 1756 (begin of AES-encrypted data),
+ // write image headers later
+ memset(buf, 0, HEADER_LEN);
+ fwrite(, 1, HEADER_LEN, output_file);
+ digest_before = EVP_MD_CTX_new();
+ digest_post = EVP_MD_CTX_new();
+ digest_vendor = EVP_MD_CTX_new();
+ sha512 = EVP_sha512();
+ EVP_DigestInit_ex(digest_before, sha512, NULL);
+ EVP_DigestInit_ex(digest_post, sha512, NULL);
+ EVP_DigestInit_ex(digest_vendor, sha512, NULL);
+
+ signing_key = PEM_read_bio_PrivateKey(rsa_private_bio, NULL, pass_cb,
NULL);
+ rsa_ctx = EVP_PKEY_CTX_new(signing_key, NULL);
+
+ EVP_PKEY_sign_init(rsa_ctx);
+ EVP_PKEY_CTX_set_signature_md(rsa_ctx, sha512);
+
+ memcpy(_iv, , AES_BLOCK_SIZE);
+ aes_ctx = EVP_CIPHER_CTX_new();
+ EVP_EncryptInit_ex(aes_ctx, aes128, NULL,
Re: [PATCH] mac80211: always use mac80211 loss detection
Hi Felix, On 6/23/23 12:47, Felix Fietkau wrote: On 23.06.23 12:29, David Bauer wrote: Hi Felix, On 6/23/23 08:55, Felix Fietkau wrote: On 18.05.23 11:19, David Bauer wrote: ath10k does not report excessive loss in case of broken block-ack sessions. The loss is communicated to the host-os, but ath10k does not trigger a low-ack events by itself. The mac80211 framework for loss detection however detects this circumstance well in case of ath10k. So use it regardless of ath10k's own loss detection mechanism. Signed-off-by: David Bauer Please make a patch for ath10k instead of turning the flag into a no-op in mac80211. The rationale for removal was in fact to avoid patching ath1xk separately, given these are the only drivers using this flag. I'm aware this is not the nicest approach, do you have any insight if there's a downside to always keeping mac80211 loss detection active? I however still respect the preferation of keeping this limited to specific drivers, I'm just interested if there's a deeper rationale / problem i did not spot :) Just to outline the issue this is trying to avoid - Intel clients started dropping their BA sessions sometimes in late 2020 without notifying the AP. The ath10k firmware keeps retransmitting exclusive to the device at the lowest rate while not indicating a low-ack situation to the host-os, avoiding station kickout. This results in very low throughput for all connected stations (aql enabled) up to DoS of the AP (aql disabled). My rationale is this: changes to the driver dropping that flag can be upstreamed, because your description implies that it fixes a real bug. A mac80211 patch turning the flag into an no-op will be rejected, since it doesn't make any sense to keep the flag around. Thanks, I haven't looked at it this way. I will update the patch to account for this. If it turns out that all ath drivers can't use this flag because of the issue you're describing, we can remove it upstream from mac80211 entirely instead of turning it into a dummy no-op. I was not at the point of upstreaming, as from reading the code the root-cause is within the firmware not reporting low-ack situation. So this requires to be evaluated with all existing platform-firmware in mind. As a sidenote - the issue I'm describing also exists with QCAs own driver, however the ramifications there greatly differ from vendor to vendor. Best David - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: always use mac80211 loss detection
On 23.06.23 12:29, David Bauer wrote: Hi Felix, On 6/23/23 08:55, Felix Fietkau wrote: On 18.05.23 11:19, David Bauer wrote: ath10k does not report excessive loss in case of broken block-ack sessions. The loss is communicated to the host-os, but ath10k does not trigger a low-ack events by itself. The mac80211 framework for loss detection however detects this circumstance well in case of ath10k. So use it regardless of ath10k's own loss detection mechanism. Signed-off-by: David Bauer Please make a patch for ath10k instead of turning the flag into a no-op in mac80211. The rationale for removal was in fact to avoid patching ath1xk separately, given these are the only drivers using this flag. I'm aware this is not the nicest approach, do you have any insight if there's a downside to always keeping mac80211 loss detection active? I however still respect the preferation of keeping this limited to specific drivers, I'm just interested if there's a deeper rationale / problem i did not spot :) Just to outline the issue this is trying to avoid - Intel clients started dropping their BA sessions sometimes in late 2020 without notifying the AP. The ath10k firmware keeps retransmitting exclusive to the device at the lowest rate while not indicating a low-ack situation to the host-os, avoiding station kickout. This results in very low throughput for all connected stations (aql enabled) up to DoS of the AP (aql disabled). My rationale is this: changes to the driver dropping that flag can be upstreamed, because your description implies that it fixes a real bug. A mac80211 patch turning the flag into an no-op will be rejected, since it doesn't make any sense to keep the flag around. If it turns out that all ath drivers can't use this flag because of the issue you're describing, we can remove it upstream from mac80211 entirely instead of turning it into a dummy no-op. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: always use mac80211 loss detection
Hi Felix, On 6/23/23 08:55, Felix Fietkau wrote: On 18.05.23 11:19, David Bauer wrote: ath10k does not report excessive loss in case of broken block-ack sessions. The loss is communicated to the host-os, but ath10k does not trigger a low-ack events by itself. The mac80211 framework for loss detection however detects this circumstance well in case of ath10k. So use it regardless of ath10k's own loss detection mechanism. Signed-off-by: David Bauer Please make a patch for ath10k instead of turning the flag into a no-op in mac80211. The rationale for removal was in fact to avoid patching ath1xk separately, given these are the only drivers using this flag. I'm aware this is not the nicest approach, do you have any insight if there's a downside to always keeping mac80211 loss detection active? I however still respect the preferation of keeping this limited to specific drivers, I'm just interested if there's a deeper rationale / problem i did not spot :) Just to outline the issue this is trying to avoid - Intel clients started dropping their BA sessions sometimes in late 2020 without notifying the AP. The ath10k firmware keeps retransmitting exclusive to the device at the lowest rate while not indicating a low-ack situation to the host-os, avoiding station kickout. This results in very low throughput for all connected stations (aql enabled) up to DoS of the AP (aql disabled). Best David - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: always use mac80211 loss detection
On 18.05.23 11:19, David Bauer wrote: ath10k does not report excessive loss in case of broken block-ack sessions. The loss is communicated to the host-os, but ath10k does not trigger a low-ack events by itself. The mac80211 framework for loss detection however detects this circumstance well in case of ath10k. So use it regardless of ath10k's own loss detection mechanism. Signed-off-by: David Bauer Please make a patch for ath10k instead of turning the flag into a no-op in mac80211. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
