subject:"\[no subject\]"

RE: Subject: [PATCH] x86 64: Add new device Cordoba Edge Platform

2023-10-23 Thread Xiaojun Liu

Thanks for your reminding!  I will update my patch to fix these issues.

-Original Message-
From: Philip Prindeville  
Sent: Monday, October 23, 2023 1:05 PM
To: Xiaojun Liu 
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: Subject: [PATCH] x86 64: Add new device Cordoba Edge Platform

Doesn't this just have ixgbe and igc NIC's?  And the mt7915e of course.

Don't think we need the amd-xgbe, bnx2, e1000e, e1000, r8169, tg3 drivers.

The BIOS we've been using has some odd enumeration of the PCI bus, so you might 
want to include a patch for target/linux/x86/base-files/etc/board.d/02_network

And bind the PCI addresses to the ethernet device names.



> On Oct 18, 2023, at 8:44 PM, Xiaojun Liu  wrote:
> 
> Add new device Cordoba Edge Platform
> Device name: Cordoba Edge Platform
> hardware specifications: CPU - Intel Atom C3000
>  WiFi - mt7915e
> 
> Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il
> ---
> target/linux/x86/image/64.mk | 11 +++
> 1 file changed, 11 insertions(+)
> 
> diff --git a/target/linux/x86/image/64.mk 
> b/target/linux/x86/image/64.mk index 5ec9978b66..04ce0be13a 100644
> --- a/target/linux/x86/image/64.mk
> +++ b/target/linux/x86/image/64.mk
> @@ -8,3 +8,14 @@ define Device/generic
>GRUB2_VARIANT := generic
> endef
> TARGET_DEVICES += generic
> +
> +define Device/cordoba
> +  DEVICE_VENDOR := Cordoba
> +  DEVICE_MODEL := x86/64
> +  DEVICE_PACKAGES += \
> +kmod-amazon-ena kmod-amd-xgbe kmod-bnx2 kmod-e1000e kmod-e1000 \
> +kmod-forcedeth kmod-fs-vfat kmod-igb kmod-igc kmod-ixgbe kmod-r8169 \
> +kmod-tg3 kmod-mt7915-firmware
> +  GRUB2_VARIANT := generic
> +endef
> +TARGET_DEVICES += cordoba
> 
> 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Subject: [PATCH] x86 64: Add new device Cordoba Edge Platform

2023-10-22 Thread Philip Prindeville

Doesn't this just have ixgbe and igc NIC's?  And the mt7915e of course.

Don't think we need the amd-xgbe, bnx2, e1000e, e1000, r8169, tg3 drivers.

The BIOS we've been using has some odd enumeration of the PCI bus, so you might 
want to include a patch for target/linux/x86/base-files/etc/board.d/02_network

And bind the PCI addresses to the ethernet device names.



> On Oct 18, 2023, at 8:44 PM, Xiaojun Liu  wrote:
> 
> Add new device Cordoba Edge Platform
> Device name: Cordoba Edge Platform
> hardware specifications: CPU - Intel Atom C3000
>  WiFi - mt7915e
> 
> Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il
> ---
> target/linux/x86/image/64.mk | 11 +++
> 1 file changed, 11 insertions(+)
> 
> diff --git a/target/linux/x86/image/64.mk b/target/linux/x86/image/64.mk
> index 5ec9978b66..04ce0be13a 100644
> --- a/target/linux/x86/image/64.mk
> +++ b/target/linux/x86/image/64.mk
> @@ -8,3 +8,14 @@ define Device/generic
>GRUB2_VARIANT := generic
> endef
> TARGET_DEVICES += generic
> +
> +define Device/cordoba
> +  DEVICE_VENDOR := Cordoba
> +  DEVICE_MODEL := x86/64
> +  DEVICE_PACKAGES += \
> +kmod-amazon-ena kmod-amd-xgbe kmod-bnx2 kmod-e1000e kmod-e1000 \
> +kmod-forcedeth kmod-fs-vfat kmod-igb kmod-igc kmod-ixgbe kmod-r8169 \
> +kmod-tg3 kmod-mt7915-firmware
> +  GRUB2_VARIANT := generic
> +endef
> +TARGET_DEVICES += cordoba
> 
> 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Subject: [PATCH] x86 64: Add new device Cordoba Edge Platform

2023-10-18 Thread Xiaojun Liu

Add new device Cordoba Edge Platform
Device name: Cordoba Edge Platform
hardware specifications: CPU - Intel Atom C3000
 WiFi - mt7915e

Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il
---
target/linux/x86/image/64.mk | 11 +++
1 file changed, 11 insertions(+)

diff --git a/target/linux/x86/image/64.mk b/target/linux/x86/image/64.mk
index 5ec9978b66..04ce0be13a 100644
--- a/target/linux/x86/image/64.mk
+++ b/target/linux/x86/image/64.mk
@@ -8,3 +8,14 @@ define Device/generic
   GRUB2_VARIANT := generic
endef
TARGET_DEVICES += generic
+
+define Device/cordoba
+  DEVICE_VENDOR := Cordoba
+  DEVICE_MODEL := x86/64
+  DEVICE_PACKAGES += \
+    kmod-amazon-ena kmod-amd-xgbe kmod-bnx2 kmod-e1000e kmod-e1000 \
+    kmod-forcedeth kmod-fs-vfat kmod-igb kmod-igc kmod-ixgbe kmod-r8169 \
+    kmod-tg3 kmod-mt7915-firmware
+  GRUB2_VARIANT := generic
+endef
+TARGET_DEVICES += cordoba




x86 64 Add new device Cordoba Edge Platform.patch
Description: x86 64 Add new device Cordoba Edge Platform.patch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2022-10-20 Thread Christian Marangi

Merged in master with commit 9f27c33e4ede180ee6d0ad359d12f4849bd342f2.

Thanks.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2022-04-03 Thread We have an offer to invest in your country under a joint venture partnership please reply for more details



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2022-03-13 Thread Henrik Ginstmark

Reply-To: 
Subject: 
In-Reply-To: 



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2022-02-25 Thread Eugenio Tampieri via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

I'm new to this list and I hope I'm not doing anything wrong.
I'm a CS student and I've used OpenWrt for years. I'm writing to this mailing 
list because I'd like to contribute to the project by adding support of the 
aformentioned device.
From what I can see, there's already an open PR 
(https://github.com/openwrt/openwrt/pull/3762). I've merged the current master 
into my fork (https://github.com/eutampieri/openwrt) and I've built it. I can 
boot it from ramdisk but as soon as I flash the sysupgrade I get this into the 
serial log:
>Kernel panic - not syncing: No working init found. Try passing init= option to 
>kernel. See Linux Documentation/admin-guide/init.rst for guidance.
As far as I can tell, the init var isn't passed from the bootloader (uboot), 
but how can I fix this? Moreover, other users on the PR haven't reported any 
issue with the setup.

Regards,

Eugenio Tampieri

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-11-28 Thread Henrik Ginstmark

Hi

Is it possible to add dms_get_operating_mode command?
Then it would be possible to verify if the modem is in flight mode or not.


BR
Henrik Ginstmark

---
commands-dms.c

@@ -375,6 +375,38 @@ qmi_set_dms_reset_request(msg);
return QMI_CMD_REQUEST;
}

+static void
+cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
+{
+ struct qmi_dms_get_operating_mode_response res;
+
+ const char *modes[] = {
+ [QMI_DMS_OPERATING_MODE_ONLINE] = "online",
+ [QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
+ [QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
+ [QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
+ [QMI_DMS_OPERATING_MODE_RESET] = "reset",
+ [QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
+ [QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] = "persistent_low_power",
+ [QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
+ };
+ int s = 0;
+
+ qmi_parse_dms_get_operating_mode_response(msg, );
+ if (res.set.mode &&
+res.data.mode < ARRAY_SIZE(modes))
+ s = res.data.mode;
+
+ blobmsg_add_string(, NULL, modes[s]);
+}
+
+static enum qmi_cmd_result
+cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
+{
+ qmi_set_dms_get_operating_mode_request(msg);
+ return QMI_CMD_REQUEST;
+}
+
#define cmd_dms_set_operating_mode_cb no_cb
static enum qmi_cmd_result
cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)


---
commands-dms.h

@@ -37,6 +37,7 @@
__uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
+   __uqmi_command(dms_get_operating_mode,
get-device-operating-mode, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_operating_mode,
set-device-operating-mode, required, QMI_SERVICE_DMS), \
__uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_fcc_authentication, fcc-auth, no,
QMI_SERVICE_DMS) \
@@ -67,6 +58,7 @@
"  --get-imei:   Get International
Mobile Equipment ID\n" \
"  --get-msisdn: Get the MSISDN
(telephone number)\n" \
"  --reset-dms:  Reset the DMS service\n" \
+   "  --get-device-operating-mode   Get the device
operating mode\n" \
"  --set-device-operating-modeSet the device
operating mode\n" \
"(modes: online,
low_power, factory_test, offline\n" \
" reset,
shutting_down, persistent_low_power,\n" \

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-03-21 Thread Gaurav Pathak



I have merged the detection of /pantavisor into the is_container()
function.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-17 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 08.02.21, 10:33, "openwrt-devel on behalf of Rosen Penev" 
 wrote:

> > My patches don't end up in Patchwork for some reason.
> It's because of DMARC. See:
> 
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.

Thanks for the hint about DMARC leading to Patchwork issues.
DMARC is a security standard for accessing email authenticity.

It seems that the OpenWrt mailing list breaks the signature by adding 
the 'openwrt-devel mailing list' footer. For other mailing lists that do 
not modify email subject and body, Patchwork has no problems with DMARC.
Example: 
https://patchwork.ozlabs.org/project/netfilter-devel/patch/a355cb9d-9b07-4d62-a228-a37c2660c...@apple.com/
for mailing list: netfilter-de...@vger.kernel.org 

DMARC settings are beyond my control (and possibly similar for others).

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-16 Thread Sebastian Careba via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Signed-off-by: Sebastian Careba 
---
 .../999-resize mamba kernel.patch | 50 ---
 1 file changed, 50 deletions(-)
 delete mode 100644 target/linux/mvebu/patches-5.10/999-resize mamba 
kernel.patch

diff --git a/target/linux/mvebu/patches-5.10/999-resize mamba kernel.patch 
b/target/linux/mvebu/patches-5.10/999-resize mamba kernel.patch
deleted file mode 100644
index a4230a4104..00
--- a/target/linux/mvebu/patches-5.10/999-resize mamba kernel.patch 
+++ /dev/null
@@ -1,50 +0,0 @@
-diff --git 
a/target/linux/mvebu/patches-5.4/999-DNM-dts-mamba-resize-3MB_to_4MB.patch 
b/target/linux/mvebu/patches-5.4/999-DNM-dts-mamba-resize-3MB_to_4MB.patch
-new file mode 100644
-index 00..2752a92a3f
 /dev/null
-+++ b/target/linux/mvebu/patches-5.4/999-DNM-dts-mamba-resize-3MB_to_4MB.patch
-@@ -0,0 +1,41 @@
-From 258233f00bcd013050efee00c5d9128ef8cd62dd Mon Sep 17 00:00:00 2001
-From: Tad 
-Date: Fri, 5 Feb 2021 22:32:11 -0500
-Subject: [PATCH] DNM: ARM: dts: armada-xp-linksys-mamba: Increase kernel
- partition to 4MB
-

- arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 8 
- 1 file changed, 4 insertions(+), 4 deletions(-)
-
-diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts 
b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
-index d7bc27ae6..20e859021 100644
 a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
-+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
-@@ -456,9 +456,9 @@
-   reg = <0xa0 0x280>;  /* 40MB */
-   };
- 
--  partition@d0 {
-+  partition@e0 {
-   label = "rootfs1";
--  reg = <0xd0 0x250>;  /* 37MB */
-+  reg = <0xe0 0x240>;  /* 36MB */
-   };
- 
-   /* kernel2 overlaps with rootfs2 by design */
-@@ -467,9 +467,9 @@
-   reg = <0x320 0x280>; /* 40MB */
-   };
- 
--  partition@350 {
-+  partition@360 {
-   label = "rootfs2";
--  reg = <0x350 0x250>; /* 37MB */
-+  reg = <0x360 0x240>; /* 36MB */
-   };
- 
-   /*
--- 
-2.29.2
-
--- 
-2.29.2
-
-- 
2.30.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-16 Thread Sebastian Careba via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Signed-off-by: Sebastian Careba 
---
 target/linux/mvebu/Makefile   |   8 +-
 target/linux/mvebu/config-5.10| 436 ++
 .../patches-5.10/002-add_powertables.patch| 770 ++
 .../004-add_sata_disk_activity_trigger.patch  |  39 +
 ...5-linksys_hardcode_nand_ecc_settings.patch |  17 +
 ...Mangle-bootloader-s-kernel-arguments.patch | 189 +
 ...sallow-XDP-program-on-hardware-buffe.patch |  53 ++
 .../030-linkstation-poweroff.patch|  20 +
 .../patches-5.10/100-find_active_root.patch   |  60 ++
 .../patches-5.10/102-revert_i2c_delay.patch   |  15 +
 .../205-armada-385-rd-mtd-partitions.patch|  19 +
 .../206-ARM-mvebu-385-ap-Add-partitions.patch |  35 +
 ...-armada-xp-linksys-mamba-broken-idle.patch |  10 +
 .../231-armada-xp-linksys-mamba-wan.patch |  11 +
 .../patches-5.10/240-linksys-status-led.patch |  50 ++
 .../241-linksys-use-eth0-as-cpu-port.patch|  25 +
 .../250-adjust-compatible-for-linksys.patch   |  68 ++
 .../300-mvneta-tx-queue-workaround.patch  |  26 +
 ...dicate-failure-to-enter-deeper-sleep.patch |  40 +
 ...-pci-mvebu-time-out-reset-on-link-up.patch |  60 ++
 ...5-PCI-aardvark-Improve-link-training.patch | 135 +++
 ...06-PCI-aardvark-Issue-PERST-via-GPIO.patch |  57 ++
 .../407-PCI-aardvark-Add-PHY-support.patch| 116 +++
 ...-t-touch-PCIe-registers-if-no-card-c.patch |  50 ++
 ...-initialization-with-old-Marvell-s-A.patch |  44 +
 ...da388-clearfog-emmc-on-clearfog-base.patch |  87 ++
 ...ts-marvell-armada37xx-Add-eth0-alias.patch |  20 +
 ...witch-PHY-operation-mode-to-2500base.patch |  20 +
 .../560-helios4-dts-status-led-alias.patch|  28 +
 ...-mvebu-armada-38x-enable-libata-leds.patch |  10 +
 .../999-resize mamba kernel.patch |  50 ++
 31 files changed, 2565 insertions(+), 3 deletions(-)
 create mode 100644 target/linux/mvebu/config-5.10
 create mode 100644 target/linux/mvebu/patches-5.10/002-add_powertables.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/004-add_sata_disk_activity_trigger.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/005-linksys_hardcode_nand_ecc_settings.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/022-mvneta-driver-disallow-XDP-program-on-hardware-buffe.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/030-linkstation-poweroff.patch
 create mode 100644 target/linux/mvebu/patches-5.10/100-find_active_root.patch
 create mode 100644 target/linux/mvebu/patches-5.10/102-revert_i2c_delay.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/205-armada-385-rd-mtd-partitions.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/206-ARM-mvebu-385-ap-Add-partitions.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/230-armada-xp-linksys-mamba-broken-idle.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/231-armada-xp-linksys-mamba-wan.patch
 create mode 100644 target/linux/mvebu/patches-5.10/240-linksys-status-led.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/241-linksys-use-eth0-as-cpu-port.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/250-adjust-compatible-for-linksys.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/300-mvneta-tx-queue-workaround.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/400-cpuidle-mvebu-indicate-failure-to-enter-deeper-sleep.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/401-pci-mvebu-time-out-reset-on-link-up.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/405-PCI-aardvark-Improve-link-training.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/406-PCI-aardvark-Issue-PERST-via-GPIO.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/407-PCI-aardvark-Add-PHY-support.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/408-PCI-aardvark-Don-t-touch-PCIe-registers-if-no-card-c.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/410-PCI-aardvark-Fix-initialization-with-old-Marvell-s-A.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/412-ARM-dts-armada388-clearfog-emmc-on-clearfog-base.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/520-arm64-dts-marvell-armada37xx-Add-eth0-alias.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/550-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/560-helios4-dts-status-led-alias.patch
 create mode 100644 
target/linux/mvebu/patches-5.10/561-mvebu-armada-38x-enable-libata-leds.patch
 create mode 100644 target/linux/mvebu/patches-5.10/999-resize mamba 
kernel.patch

diff --git

[no subject]

2021-02-14 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 915336ed34f0a71b09a470f8069be887c85d6a21
  
https://github.com/sdwalker/sdwalker.github.io/commit/915336ed34f0a71b09a470f8069be887c85d6a21
  Author: Stephen Walker 
  Date:   2021-02-14 (Sun, 14 Feb 2021)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-13 Thread Roman Kuzmitskii via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

  it would be nice if we could ‘unbreak' fresh installs for ubiquiti edgerouter 
4 (octeon target) before 21.02 takes off.
  fresh installs are done through usb and (almost) all necessary usb support is 
done through DEVICE_PACKAGES.
  that DEVICE_PACKAGES are currently not included into the initramfs and fresh 
installs are not possible using usb flash drive. 

  https://github.com/openwrt/openwrt/pull/3854 there is a MR that should fix 
the issue for first time installs.
  it should only fix the breakage done by simply enabling support for usb as 
built in instead of having external packages and does not add anything new.

  thank you

> On Feb 12, 2021, at 4:57 AM, Hauke Mehrtens  wrote:
> 
> Hi,
> 
> We just had our developer meeting and want to do branch the next release 
> soon. I just want to coordinate the release planning here, the full meeting 
> notes will be published later.
> 
> We want to merge the mac80211 update to version 5.10 found here:
> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mac80211-5.10
> Felix uses this since some time now and found no problems, I am also not 
> aware of any problems. Kernel 5.10 is an LTS kernel which makes security 
> maintenance easier for us.
> I plan to merge this at the weekend.
> 
> We would also like to get this busybox update in:
> https://patchwork.ozlabs.org/project/openwrt/list/?series=227292
> It also works well and should make it easier to maintain busybox in our 
> stable release.
> I plan to merge this at the weekend.
> 
> It would be nice to get DSA support in LuCI. We have this pull request:
> https://github.com/openwrt/luci/pull/4307
> This still has problems with Wireless bridge-vlan.
> If this is not ready in time for the branching we will backport it later.
> 
> Rafał is asking about the general LuCI status here:
> https://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033715.html
> 
> 
> For more details, we have this release goals page:
> https://openwrt.org/docs/guide-developer/releases/goals/21.02
> 
> lynxis and ynezz will prepare the build bot setup to build snapshots of the 
> 21.02 release branch and the releases (candidates).
> 
> If everything will look good, we will branch 21.02 sometime next week.
> 
> If the update of mac80ß211 or busybox breaks something, we will fix it or 
> revert the update this should not delay the branching.
> 
> I would like to have a 21.02-rc1 in 2 or 3 weeks after the branching, so we 
> get more test coverage.
> 
> Do we still have some important bugs we should really fix in master or 
> anything which could be blocking for the release?
> Any objections to this plan?
> 
> Hauke
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-12 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> We just had our developer meeting and want to do branch the next release 
> soon. I just want to coordinate the release planning here, the full 
> meeting notes will be published later.
> 
> Do we still have some important bugs we should really fix in master or 
> anything which could be blocking for the release?
> Any objections to this plan?

>From my side there are three pending patches to upstream projects.

1. Fix: Correction for IPv6 handling in libnetfilter_queue (packages)
   This is currently pending with Netfilter
   
https://patchwork.ozlabs.org/project/netfilter-devel/patch/a355cb9d-9b07-4d62-a228-a37c2660c...@apple.com/

2. Feature: Adding ICMP support to libnetfilter_queue (packages)
   This is accepted by Netfilter, but has not made it into a release yet
   
https://git.netfilter.org/libnetfilter_queue/commit/?id=662c8f44d53492d2e0ebd430dadef12d580ec330

3. Feature: Extending Dnsmasq with conntrack based DNS query filtering.
   This is currently pending with Dnsmasq, and will also need a minor 
   addition to OpenWrt's dnsmasq.init file.
   http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014661.html

These three patches should eventually get into OpenWrt as well.

For 19.07 it seems that the preferred approach is to only backport 
select patches instead of updating the entire component.
Is it still possible to integrate new libnetfilter_queue / Dnsmasq 
releases into OpenWrt 21.02 once the patches have been accepted,
or do you prefer the patches to be submitted to OpenWrt separately 
before the branch to 21.02?

Etan




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-11 Thread Jonathan Lancett via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 11/02/2021 21:28, Rafał Miłecki wrote:

We're planning a 21.xx release and for a lot of our end users LuCI is
an important part of OpenWrt.

I'd like to ask: what's the current state of LuCI?
One thing that probably requires some extra focus is DSA. Are there
any remaining issues regarding it?

I'd be also nice to get some extra LuCI testing before the release. If
you can, please install & test LuCI on your device & provide a
feedback if something appears broken.



      �

From my POV just this:

https://github.com/openwrt/luci/issues/4801

It's better for screen reader users.


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-09 Thread Paul Oranje via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Op 5 feb. 2021, om 00:59 heeft Paul Spooren  het volgende 
geschreven:
> 
> The script improves readability by using an automatic code formatter.

The decreases of the switch case indentation levels make sense, but IMHO the 
removals of the space between redirection and source (e.g. --- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-08 Thread Etan Kissling (IC) via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
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.

If those are acceptable, be sure to take the latest submission for the patches 
that were submitted multiple times.

Thanks

Etan

> On 5 Feb 2021, at 08:56, Baptiste Jonglez  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
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-02-07 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 0760273d001931c059e857ccf8f2ac359aa30451
  
https://github.com/sdwalker/sdwalker.github.io/commit/0760273d001931c059e857ccf8f2ac359aa30451
  Author: Stephen Walker 
  Date:   2021-02-07 (Sun, 07 Feb 2021)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-31 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 889fef893adbf608e67c2c1c4375efbf2aa7047c
  
https://github.com/sdwalker/sdwalker.github.io/commit/889fef893adbf608e67c2c1c4375efbf2aa7047c
  Author: Stephen Walker 
  Date:   2021-01-31 (Sun, 31 Jan 2021)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-30 Thread Vladimir Zhirov via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

feeds/packages:

Please put in "include/download.mk"
Message about "your can download cached file 
http://https://sources.openwrt.org/.tar.gz;

if SVN fetch problem was appeared.


PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://svn.unix-ag.uni-kl.de/vpnc/trunk/
+PKG_MIRROR_HASH:=659b6451245f17ce0ee3f1a6069b404fdb438d09ca4b9966b512c773e4507eb1
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
 PKG_SOURCE_PROTO:=svn


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-27 Thread Paul Oranje via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


> Op 27 jan. 2021, om 01:12 heeft Philip Prindeville 
>  het volgende geschreven:
> 
> 
> 
>> On Jan 26, 2021, at 2:09 PM, Paul Oranje  wrote:
>> 
>> 
>> 
>>> Op 22 jan. 2021, om 20:03 heeft Daniel Golle  het 
>>> volgende geschreven:
>>> 
>>> Hi Philip,
>>> 
>>> On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote:
 Hi,
 
 Is anyone interested in adding a page to the openwrt.org site about 
 developers willing to do commercial work?
 
 It could be as simple as:
 
 * name
 * email address
 * mobile (if wanted)
 * packages/platforms/architectures you maintain or have competence in
 * whether you're available full-time, part-time, or currently unavailable
 
 Might be useful for matching up devs with work.
>>> 
>>> While I like the idea and would probably benefit from it myself, I'm
>>> a bit sceptical when it comes to making OpenWrt.org an institution
>>> certifying developers. Too much trouble was caused over having
>>> '@openwrt.org' addresses and I doubt we are able to handle the
>>> moderation needs (think: classic fraud, fishing, ...) of such a thing
>>> if it is even a wiki, ie. free to edit for all.
>>> Things like a wiki with only volunteer moderation somehow work because
>>> there is little to no commercial interest in manipulation and it is
>>> usually easy to recognize (ie. classic spam). In the moment that we
>>> change that, we have to be prepared to also face a different quality
>>> of manipulation attempts.
>>> 
>>> Just my 2 cents...
>> Indeed, having a job board would be like opening a can of worms. Don't do it.
>> Paul
> 
> 
> And an open mailing list?
Probably less troublesome, but some moderation will still be needed and with 
that comes the need for a policy etc.
Not against an open ML though.
Bye,
Paul 

> 
> -Philip
> 
> 
>> 
>>> 
 
 Just an idea to help our community prosper.
 
 Thanks,
 
 -Philip
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>> 
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-25 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


On 17.01.21, 19:17, "openwrt-devel on behalf of Daniel Golle" 
 
wrote:

> I think backporting all this is ok, but please add references to the
> corresponding commit in master (or `git cherry-pick -x`, if possible).

Thanks, I resubmitted the patches to include the original commit ID:
- [PATCH 19.07] mbedtls: add config option to compile with hkdf
- [PATCH 19.07] hostapd: add multicast_to_unicast and per_sta_vif
- [PATCH 19.07] hostapd: enable CTRL_IFACE_MIB for hostapd-full
- [PATCH 19.07] nf-conntrack: allow querying conntrack info in nfqueue

For the final one, this was not a backport from master, but instead
an additional patch from upstream.
- [PATCH 19.07] libnetfilter_queue: Fix test for IPv6 header
Because master chose to update the entire library instead of backporting
only individual fixes, and because the updated upstream version consists 
mostly of bug fixes, replaced the patch to backport from master instead:
- [PATCH 19.07] libnetfilter-queue: update to 1.0.5

It seems my patches don't end up in Patchwork (possibly due to DMARC?)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-24 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 8dda2d6947e804a21be65797b4c83b877368acff
  
https://github.com/sdwalker/sdwalker.github.io/commit/8dda2d6947e804a21be65797b4c83b877368acff
  Author: Stephen Walker 
  Date:   2021-01-24 (Sun, 24 Jan 2021)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-19 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Switch to normal tarballs for simplicity.

Removed upstream patch.

Fixed license information.

Signed-off-by: Rosen Penev 
(cherry picked from openwrt/packages
commit b60aa5ffdb258c0c94b375c4e972c587b572b1a7)
Re-added `PKG_FIXUP:=autoreconf` to prevent build error.
Signed-off-by: Etan Kissling 
---
 package/libs/libnetfilter-queue/Makefile  |  17 +--
 .../patches/100-checksum_computation.patch| 113 --
 2 files changed, 9 insertions(+), 121 deletions(-)
 delete mode 100644 
package/libs/libnetfilter-queue/patches/100-checksum_computation.patch

diff --git a/package/libs/libnetfilter-queue/Makefile 
b/package/libs/libnetfilter-queue/Makefile
index 38f148ef07..618cb4e7a3 100644
--- a/package/libs/libnetfilter-queue/Makefile
+++ b/package/libs/libnetfilter-queue/Makefile
@@ -8,18 +8,19 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=libnetfilter_queue
-PKG_RELEASE:=2
+PKG_VERSION:=1.0.5
+PKG_RELEASE:=1
 
-PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL=https://git.netfilter.org/libnetfilter_queue
-PKG_SOURCE_DATE:=2017-06-27
-PKG_SOURCE_VERSION:=601abd1c71ccdf90753cf294c120ad43fb25dc54
-PKG_MIRROR_HASH:=283b99cfe5856dc87fd6bab8f78c0c59b72462d6b4f2b13111f928cf33020eb3
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
+PKG_SOURCE_URL:=https://www.netfilter.org/projects/libnetfilter_queue/files
+PKG_HASH:=f9ff3c11305d6e03d81405957bdc11aea18e0d315c3e3f48da53a24ba251b9f5
 
 PKG_FIXUP:=autoreconf
-PKG_LICENSE:=GPL-2.0+
+PKG_LICENSE:=GPL-2.0-or-later
+PKG_LICENSE_FILES:=COPYING
 
 PKG_INSTALL:=1
+PKG_BUILD_PARALLEL:=1
 
 include $(INCLUDE_DIR)/package.mk
 
@@ -28,7 +29,7 @@ define Package/libnetfilter-queue
   CATEGORY:=Libraries
   DEPENDS:=+libmnl +libnfnetlink
   TITLE:=Userspace API to packets queued by kernel packet filter
-  URL:=http://www.netfilter.org/projects/libnetfilter_queue/
+  URL:=https://www.netfilter.org/projects/libnetfilter_queue/
   ABI_VERSION:=1
 endef
 
diff --git 
a/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch 
b/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch
deleted file mode 100644
index 92e750d510..00
--- a/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch
+++ /dev/null
@@ -1,113 +0,0 @@
 a/src/extra/checksum.c
-+++ b/src/extra/checksum.c
-@@ -11,6 +11,7 @@
- 
- #include 
- #include 
-+#include 
- #include 
- #include 
- #include 
-@@ -26,8 +27,13 @@ uint16_t nfq_checksum(uint32_t sum, uint
-   sum += *buf++;
-   size -= sizeof(uint16_t);
-   }
--  if (size)
--  sum += *(uint8_t *)buf;
-+  if (size) {
-+#if __BYTE_ORDER == __BIG_ENDIAN
-+  sum += (uint16_t)*(uint8_t *)buf << 8;
-+#else
-+  sum += (uint16_t)*(uint8_t *)buf;
-+#endif
-+  }
- 
-   sum = (sum >> 16) + (sum & 0x);
-   sum += (sum >>16);
-@@ -35,7 +41,7 @@ uint16_t nfq_checksum(uint32_t sum, uint
-   return (uint16_t)(~sum);
- }
- 
--uint16_t nfq_checksum_tcpudp_ipv4(struct iphdr *iph)
-+uint16_t nfq_checksum_tcpudp_ipv4(struct iphdr *iph, uint16_t protocol_id)
- {
-   uint32_t sum = 0;
-   uint32_t iph_len = iph->ihl*4;
-@@ -46,13 +52,13 @@ uint16_t nfq_checksum_tcpudp_ipv4(struct
-   sum += (iph->saddr) & 0x;
-   sum += (iph->daddr >> 16) & 0x;
-   sum += (iph->daddr) & 0x;
--  sum += htons(IPPROTO_TCP);
-+  sum += htons(protocol_id);
-   sum += htons(len);
- 
-   return nfq_checksum(sum, (uint16_t *)payload, len);
- }
- 
--uint16_t nfq_checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr)
-+uint16_t nfq_checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr, 
uint16_t protocol_id)
- {
-   uint32_t sum = 0;
-   uint32_t hdr_len = (uint32_t *)transport_hdr - (uint32_t *)ip6h;
-@@ -68,7 +74,7 @@ uint16_t nfq_checksum_tcpudp_ipv6(struct
-   sum += (ip6h->ip6_dst.s6_addr16[i] >> 16) & 0x;
-   sum += (ip6h->ip6_dst.s6_addr16[i]) & 0x;
-   }
--  sum += htons(IPPROTO_TCP);
-+  sum += htons(protocol_id);
-   sum += htons(ip6h->ip6_plen);
- 
-   return nfq_checksum(sum, (uint16_t *)payload, len);
 a/src/extra/tcp.c
-+++ b/src/extra/tcp.c
-@@ -96,7 +96,7 @@ nfq_tcp_compute_checksum_ipv4(struct tcp
- {
-   /* checksum field in header needs to be zero for calculation. */
-   tcph->check = 0;
--  tcph->check = nfq_checksum_tcpudp_ipv4(iph);
-+  tcph->check = nfq_checksum_tcpudp_ipv4(iph, IPPROTO_TCP);
- }
- EXPORT_SYMBOL(nfq_tcp_compute_checksum_ipv4);
- 
-@@ -110,7 +110,7 @@ nfq_tcp_compute_checksum_ipv6(struct tcp
- {
-   /* checksum field in header needs to be zero for calculation. */
-   tcph->check = 0;
--  tcph->check =

[no subject]

2021-01-18 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows libnetfilter_queue to access connection tracking information
by requesting NFQA_CFG_F_CONNTRACK. Connection tracking information is
provided in the NFQA_CT attribute.
CONFIG_NETFILTER_NETLINK_GLUE_CT enables the interaction between
nf_queue and nf_conntrack_netlink. Without this option, trying to access
connection tracking information results in "Operation not supported".

Signed-off-by: Etan Kissling 
(cherry picked from commit 39add246c1e18afc1fe026b5f359a3acf8082279)
Signed-off-by: Etan Kissling 
---
 package/kernel/linux/modules/netfilter.mk | 2 +-
 target/linux/generic/config-4.14  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/netfilter.mk 
b/package/kernel/linux/modules/netfilter.mk
index 53188eab5a..c1db9aa203 100644
--- a/package/kernel/linux/modules/netfilter.mk
+++ b/package/kernel/linux/modules/netfilter.mk
@@ -1013,7 +1013,7 @@ $(eval $(call KernelPackage,nfnetlink-queue))
 define KernelPackage/nf-conntrack-netlink
   TITLE:=Connection tracking netlink interface
   FILES:=$(LINUX_DIR)/net/netfilter/nf_conntrack_netlink.ko
-  KCONFIG:=CONFIG_NF_CT_NETLINK CONFIG_NF_CONNTRACK_EVENTS=y
+  KCONFIG:=CONFIG_NF_CT_NETLINK CONFIG_NF_CONNTRACK_EVENTS=y 
CONFIG_NETFILTER_NETLINK_GLUE_CT=y
   AUTOLOAD:=$(call AutoProbe,nf_conntrack_netlink)
   $(call AddDepends/nfnetlink,+kmod-ipt-conntrack)
 endef
diff --git a/target/linux/generic/config-4.14 b/target/linux/generic/config-4.14
index d54ede9efd..25b3de9f18 100644
--- a/target/linux/generic/config-4.14
+++ b/target/linux/generic/config-4.14
@@ -3252,6 +3252,7 @@ CONFIG_NF_CONNTRACK_PROCFS=y
 # CONFIG_NF_CONNTRACK_ZONES is not set
 # CONFIG_NF_CT_NETLINK is not set
 # CONFIG_NF_CT_NETLINK_TIMEOUT is not set
+# CONFIG_NF_CT_NETLINK_HELPER is not set
 # CONFIG_NF_CT_PROTO_DCCP is not set
 # CONFIG_NF_CT_PROTO_GRE is not set
 # CONFIG_NF_CT_PROTO_SCTP is not set
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-18 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Switch to normal tarballs for simplicity.

Removed upstream patch.

Fixed license information.

Signed-off-by: Rosen Penev 
(cherry picked from packages commit b60aa5ffdb258c0c94b375c4e972c587b572b1a7)
Signed-off-by: Etan Kissling 
---
 package/libs/libnetfilter-queue/Makefile  |  18 +--
 .../patches/100-checksum_computation.patch| 113 --
 2 files changed, 9 insertions(+), 122 deletions(-)
 delete mode 100644 
package/libs/libnetfilter-queue/patches/100-checksum_computation.patch

diff --git a/package/libs/libnetfilter-queue/Makefile 
b/package/libs/libnetfilter-queue/Makefile
index 38f148ef07..01ce1f80d1 100644
--- a/package/libs/libnetfilter-queue/Makefile
+++ b/package/libs/libnetfilter-queue/Makefile
@@ -8,18 +8,18 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=libnetfilter_queue
-PKG_RELEASE:=2
+PKG_VERSION:=1.0.5
+PKG_RELEASE:=1
 
-PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL=https://git.netfilter.org/libnetfilter_queue
-PKG_SOURCE_DATE:=2017-06-27
-PKG_SOURCE_VERSION:=601abd1c71ccdf90753cf294c120ad43fb25dc54
-PKG_MIRROR_HASH:=283b99cfe5856dc87fd6bab8f78c0c59b72462d6b4f2b13111f928cf33020eb3
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
+PKG_SOURCE_URL:=https://www.netfilter.org/projects/libnetfilter_queue/files
+PKG_HASH:=f9ff3c11305d6e03d81405957bdc11aea18e0d315c3e3f48da53a24ba251b9f5
 
-PKG_FIXUP:=autoreconf
-PKG_LICENSE:=GPL-2.0+
+PKG_LICENSE:=GPL-2.0-or-later
+PKG_LICENSE_FILES:=COPYING
 
 PKG_INSTALL:=1
+PKG_BUILD_PARALLEL:=1
 
 include $(INCLUDE_DIR)/package.mk
 
@@ -28,7 +28,7 @@ define Package/libnetfilter-queue
   CATEGORY:=Libraries
   DEPENDS:=+libmnl +libnfnetlink
   TITLE:=Userspace API to packets queued by kernel packet filter
-  URL:=http://www.netfilter.org/projects/libnetfilter_queue/
+  URL:=https://www.netfilter.org/projects/libnetfilter_queue/
   ABI_VERSION:=1
 endef
 
diff --git 
a/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch 
b/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch
deleted file mode 100644
index 92e750d510..00
--- a/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch
+++ /dev/null
@@ -1,113 +0,0 @@
 a/src/extra/checksum.c
-+++ b/src/extra/checksum.c
-@@ -11,6 +11,7 @@
- 
- #include 
- #include 
-+#include 
- #include 
- #include 
- #include 
-@@ -26,8 +27,13 @@ uint16_t nfq_checksum(uint32_t sum, uint
-   sum += *buf++;
-   size -= sizeof(uint16_t);
-   }
--  if (size)
--  sum += *(uint8_t *)buf;
-+  if (size) {
-+#if __BYTE_ORDER == __BIG_ENDIAN
-+  sum += (uint16_t)*(uint8_t *)buf << 8;
-+#else
-+  sum += (uint16_t)*(uint8_t *)buf;
-+#endif
-+  }
- 
-   sum = (sum >> 16) + (sum & 0x);
-   sum += (sum >>16);
-@@ -35,7 +41,7 @@ uint16_t nfq_checksum(uint32_t sum, uint
-   return (uint16_t)(~sum);
- }
- 
--uint16_t nfq_checksum_tcpudp_ipv4(struct iphdr *iph)
-+uint16_t nfq_checksum_tcpudp_ipv4(struct iphdr *iph, uint16_t protocol_id)
- {
-   uint32_t sum = 0;
-   uint32_t iph_len = iph->ihl*4;
-@@ -46,13 +52,13 @@ uint16_t nfq_checksum_tcpudp_ipv4(struct
-   sum += (iph->saddr) & 0x;
-   sum += (iph->daddr >> 16) & 0x;
-   sum += (iph->daddr) & 0x;
--  sum += htons(IPPROTO_TCP);
-+  sum += htons(protocol_id);
-   sum += htons(len);
- 
-   return nfq_checksum(sum, (uint16_t *)payload, len);
- }
- 
--uint16_t nfq_checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr)
-+uint16_t nfq_checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr, 
uint16_t protocol_id)
- {
-   uint32_t sum = 0;
-   uint32_t hdr_len = (uint32_t *)transport_hdr - (uint32_t *)ip6h;
-@@ -68,7 +74,7 @@ uint16_t nfq_checksum_tcpudp_ipv6(struct
-   sum += (ip6h->ip6_dst.s6_addr16[i] >> 16) & 0x;
-   sum += (ip6h->ip6_dst.s6_addr16[i]) & 0x;
-   }
--  sum += htons(IPPROTO_TCP);
-+  sum += htons(protocol_id);
-   sum += htons(ip6h->ip6_plen);
- 
-   return nfq_checksum(sum, (uint16_t *)payload, len);
 a/src/extra/tcp.c
-+++ b/src/extra/tcp.c
-@@ -96,7 +96,7 @@ nfq_tcp_compute_checksum_ipv4(struct tcp
- {
-   /* checksum field in header needs to be zero for calculation. */
-   tcph->check = 0;
--  tcph->check = nfq_checksum_tcpudp_ipv4(iph);
-+  tcph->check = nfq_checksum_tcpudp_ipv4(iph, IPPROTO_TCP);
- }
- EXPORT_SYMBOL(nfq_tcp_compute_checksum_ipv4);
- 
-@@ -110,7 +110,7 @@ nfq_tcp_compute_checksum_ipv6(struct tcp
- {
-   /* checksum field in header needs to be zero for calculation. */
-   tcph->check = 0;
--  tcph->check = nfq_checksum_tcpudp_ipv6(ip6h, tcph);
-+  tcph->check =

[no subject]

2021-01-18 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This adds a config option to allow compiling with HKDF algorithm support
to support applications that require this feature.

Signed-off-by: Etan Kissling 
(cherry picked from commit 02abd99f89d98344d086d95b1ec1dfa9901351aa)
Signed-off-by: Etan Kissling 
---
 package/libs/mbedtls/Makefile | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
index 04033b1e47..ea8df0783c 100644
--- a/package/libs/mbedtls/Makefile
+++ b/package/libs/mbedtls/Makefile
@@ -20,7 +20,9 @@ PKG_BUILD_PARALLEL:=1
 PKG_LICENSE:=GPL-2.0+
 PKG_CPE_ID:=cpe:/a:arm:mbed_tls
 
-PKG_CONFIG_DEPENDS:=CONFIG_LIBMBEDTLS_DEBUG_C
+PKG_CONFIG_DEPENDS := \
+   CONFIG_LIBMBEDTLS_DEBUG_C \
+   CONFIG_LIBMBEDTLS_HKDF_C
 
 include $(INCLUDE_DIR)/package.mk
 include $(INCLUDE_DIR)/cmake.mk
@@ -56,6 +58,14 @@ config LIBMBEDTLS_DEBUG_C
 by around 60 KiB (for an ARMv5 platform).
 
 Usually, you don't need this, so don't select this if you're unsure.
+
+config LIBMBEDTLS_HKDF_C
+   depends on PACKAGE_libmbedtls
+   bool "Enable the HKDF algorithm (RFC 5869)"
+   default n
+   help
+This option adds support for the Hashed Message Authentication Code
+(HMAC)-based key derivation function (HKDF).
 endef
 
 define Package/mbedtls-util
@@ -96,6 +106,13 @@ define Build/Configure
 END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
 >$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
+
+   awk 'BEGIN { rc = 1 } \
+/#define MBEDTLS_HKDF_C/ { 0 = "$(if 
$(CONFIG_LIBMBEDTLS_HKDF_C),,// )#define MBEDTLS_HKDF_C"; rc = 0 } \
+{ print } \
+END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
+>$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
+   mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
 endef
 
 define Build/InstallDev
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-18 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This enables the CTRL_IFACE_MIB symbol for wpad-full and hostapd-full.
If it is not enabled, statistic outputs such as "hostapd_cli all_sta"
are empty.

Signed-off-by: David Bauer 
(cherry picked from commit 1ccf4bb93b0304c3c32a8a31a711a6ab889fd47a)
Signed-off-by: Etan Kissling 
---
 package/network/services/hostapd/files/hostapd-basic.config  | 5 +
 package/network/services/hostapd/files/hostapd-full.config   | 5 +
 package/network/services/hostapd/files/hostapd-mini.config   | 5 +
 .../services/hostapd/files/wpa_supplicant-basic.config   | 5 +
 .../services/hostapd/files/wpa_supplicant-full.config| 5 +
 .../services/hostapd/files/wpa_supplicant-mini.config| 5 +
 .../network/services/hostapd/files/wpa_supplicant-p2p.config | 5 +
 7 files changed, 35 insertions(+)

diff --git a/package/network/services/hostapd/files/hostapd-basic.config 
b/package/network/services/hostapd/files/hostapd-basic.config
index 461b178433..19ea850f6b 100644
--- a/package/network/services/hostapd/files/hostapd-basic.config
+++ b/package/network/services/hostapd/files/hostapd-basic.config
@@ -394,3 +394,8 @@ CONFIG_TLS=internal
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+#CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/hostapd-full.config 
b/package/network/services/hostapd/files/hostapd-full.config
index 5c9fbed2e4..0ecce423e7 100644
--- a/package/network/services/hostapd/files/hostapd-full.config
+++ b/package/network/services/hostapd/files/hostapd-full.config
@@ -394,3 +394,8 @@ CONFIG_TAXONOMY=y
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/hostapd-mini.config 
b/package/network/services/hostapd/files/hostapd-mini.config
index f31e6467b0..d9511441e6 100644
--- a/package/network/services/hostapd/files/hostapd-mini.config
+++ b/package/network/services/hostapd/files/hostapd-mini.config
@@ -394,3 +394,8 @@ CONFIG_TLS=internal
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+#CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/wpa_supplicant-basic.config 
b/package/network/services/hostapd/files/wpa_supplicant-basic.config
index e2bd1866c4..a9da65deed 100644
--- a/package/network/services/hostapd/files/wpa_supplicant-basic.config
+++ b/package/network/services/hostapd/files/wpa_supplicant-basic.config
@@ -618,3 +618,8 @@ CONFIG_GETRANDOM=y
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+#CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/wpa_supplicant-full.config 
b/package/network/services/hostapd/files/wpa_supplicant-full.config
index e5a6752a8e..982f4d5534 100644
--- a/package/network/services/hostapd/files/wpa_supplicant-full.config
+++ b/package/network/services/hostapd/files/wpa_supplicant-full.config
@@ -618,3 +618,8 @@ CONFIG_IBSS_RSN=y
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/wpa_supplicant-mini.config 
b/package/network/services/hostapd/files/wpa_supplicant-mini.config
index 6af4693c53..850d22febc 100644
--- a/package/network/services/hostapd/files/wpa_supplicant-mini.config
+++ b/package/network/services/hostapd/files/wpa_supplicant-mini.config
@@ -618,3 +618,8 @@ CONFIG_GETRANDOM=y
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+#CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/wpa_supplicant-p2p.config

[no subject]

2021-01-18 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows configuration of multicast_to_unicast and per_sta_vif options.
- multicast_to_unicast requests multicast-to-unicast conversion.
- per_sta_vif assigns each station its own AP_VLAN interface.

Signed-off-by: Etan Kissling 
(cherry picked from commit 7babb978ad9d7fc29acb1ff86afb1eb343af303a)
Signed-off-by: Etan Kissling 
---
 package/network/services/hostapd/files/hostapd.sh | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 79e71616dc..603b5a0c80 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -245,6 +245,8 @@ hostapd_common_add_bss_config() {
config_add_boolean sae_require_mfp

config_add_string 'owe_transition_bssid:macaddr' 
'owe_transition_ssid:string'
+
+   config_add_boolean multicast_to_unicast per_sta_vif
 }
 
 hostapd_set_bss_options() {
@@ -267,7 +269,8 @@ hostapd_set_bss_options() {
iapp_interface eapol_version dynamic_vlan ieee80211w nasid \
acct_server acct_secret acct_port acct_interval \
bss_load_update_period chan_util_avg_period sae_require_mfp \
-   multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key
+   multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key \
+   multicast_to_unicast per_sta_vif
 
set_default isolate 0
set_default maxassoc 0
@@ -627,6 +630,16 @@ hostapd_set_bss_options() {
}
}
 
+   set_default multicast_to_unicast 0
+   if [ "$multicast_to_unicast" -gt 0 ]; then
+   append bss_conf "multicast_to_unicast=$multicast_to_unicast" 
"$N"
+   fi
+
+   set_default per_sta_vif 0
+   if [ "$per_sta_vif" -gt 0 ]; then
+   append bss_conf "per_sta_vif=$per_sta_vif" "$N"
+   fi
+
append "$var" "$bss_conf" "$N"
return 0
 }
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-18 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This adds a config option to allow compiling with HKDF algorithm support
to support applications that require this feature.

Signed-off-by: Etan Kissling 
(cherry picked from commit 02abd99f89d98344d086d95b1ec1dfa9901351aa)
---
 package/libs/mbedtls/Makefile | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
index 04033b1e47..ea8df0783c 100644
--- a/package/libs/mbedtls/Makefile
+++ b/package/libs/mbedtls/Makefile
@@ -20,7 +20,9 @@ PKG_BUILD_PARALLEL:=1
 PKG_LICENSE:=GPL-2.0+
 PKG_CPE_ID:=cpe:/a:arm:mbed_tls
 
-PKG_CONFIG_DEPENDS:=CONFIG_LIBMBEDTLS_DEBUG_C
+PKG_CONFIG_DEPENDS := \
+   CONFIG_LIBMBEDTLS_DEBUG_C \
+   CONFIG_LIBMBEDTLS_HKDF_C
 
 include $(INCLUDE_DIR)/package.mk
 include $(INCLUDE_DIR)/cmake.mk
@@ -56,6 +58,14 @@ config LIBMBEDTLS_DEBUG_C
 by around 60 KiB (for an ARMv5 platform).
 
 Usually, you don't need this, so don't select this if you're unsure.
+
+config LIBMBEDTLS_HKDF_C
+   depends on PACKAGE_libmbedtls
+   bool "Enable the HKDF algorithm (RFC 5869)"
+   default n
+   help
+This option adds support for the Hashed Message Authentication Code
+(HMAC)-based key derivation function (HKDF).
 endef
 
 define Package/mbedtls-util
@@ -96,6 +106,13 @@ define Build/Configure
 END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
 >$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
+
+   awk 'BEGIN { rc = 1 } \
+/#define MBEDTLS_HKDF_C/ { 0 = "$(if 
$(CONFIG_LIBMBEDTLS_HKDF_C),,// )#define MBEDTLS_HKDF_C"; rc = 0 } \
+{ print } \
+END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
+>$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
+   mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
 endef
 
 define Build/InstallDev
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-17 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 130e52672ba21677b67b9871576407b25dea1381
  
https://github.com/sdwalker/sdwalker.github.io/commit/130e52672ba21677b67b9871576407b25dea1381
  Author: Stephen Walker 
  Date:   2021-01-17 (Sun, 17 Jan 2021)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-17 Thread Gagan Sidhu via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
hi,

using your dts configurations for the LEDS, just wonderin g how i can make the 
USB LED blink.

they don’t seem to do so with activity.

and also: even with swconfig_LEDS=y and all the stuff in the dts, the ethernet 
led does not turn on as orange by default. it does go green when i get a wan IP.

just wondering how i can have it orange by default

Thanks,
Gagan
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-15 Thread Thomas Reiser via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Discussion is here: 
https://forum.openwrt.org/t/please-consider-ath10k-non-ct-drivers-instead-of-ct

*** I was directed to the mailing list and kindly ask you to have a look, Thank 
you! ***

Hi,

I've now waited a long time to observe why my Archer C7 v2 and v5 units got bad 
performance on 2.4 GHz and sometimes complete crash of the WiFi drivers while 
the LAN interfaces are still working.

It all seems to boil down to OpenWrt's decision to include ath10k-ct drivers 
instead of ath10k (non-ct) drivers since 19.07.x releases.

Since then, many users including me according to the below referenced topics 
have the same issues, e.g.:

2.4 GHz download speed is capped around 10 MBit/sec.
ath10k driver crashes, requiring "rmmod ath10k-pci; sleep 10; insmod 
ath10k-pci;" or "reboot" to make the router work again.
5 GHz max bandwidth is a lot slower than with non-ct drivers, but still okay
the feeling "of less WiFi range", because devices that are further away seem to 
have trouble connecting at 1st try. For me, standing at the exact same 
distance, I've observed my devices connecting fine.
It's a "mysterious" story since then, because I've read a lot of threads here 
(and participated myself), I feel like 80% of the feedback I got for my "ath10 
non-ct builds" was "hey, my WiFi problems with the Archver C7's were solved 
thank you." and the rest like "not sure - or it's the same like with ct 
drivers".

This leads me to kindly ask you to consider including ath10k (non-ct) drivers 
in the next upcoming major OpenWrt releases. It would save me and other people 
the effort to build a new OpenWrt image ourselves whenever a new official 
stable commit is available as release. I'd hope to use the official built 
images again in the future and also advise other people to use them. You are 
really doing great work on OpenWrt!

Thank you.

Kind regards

References:

https://forum.openwrt.org/t/archer-c7-v2-bad-wifi-range-5-ghz-since-19-07-0/
https://forum.openwrt.org/t/archer-c7-v2-massive-problems/
https://forum.openwrt.org/t/tp-link-archer-c7-v2-poor-wifi-performance
https://forum.openwrt.org/t/archer-c7-v5-tx-power-changes-and-candela-tech-drivers
https://forum.openwrt.org/t/ath10k-pci-00-0-swba-overrun-on-vdev-0-skipped-old-beacon
https://forum.openwrt.org/t/state-of-archer-c7-v2-in-mid-2020/
https://forum.openwrt.org/t/archer-c7-2-4-ghz-wireless-dies-in-24-48-hours/

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-14 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This enables the CTRL_IFACE_MIB symbol for wpad-full and hostapd-full.
If it is not enabled, statistic outputs such as "hostapd_cli all_sta"
are empty.

Signed-off-by: David Bauer 
[etan_kissl...@apple.com: Backport from master.]
Signed-off-by: Etan Kissling 
---
 package/network/services/hostapd/files/hostapd-basic.config  | 5 +
 package/network/services/hostapd/files/hostapd-full.config   | 5 +
 package/network/services/hostapd/files/hostapd-mini.config   | 5 +
 .../services/hostapd/files/wpa_supplicant-basic.config   | 5 +
 .../services/hostapd/files/wpa_supplicant-full.config| 5 +
 .../services/hostapd/files/wpa_supplicant-mini.config| 5 +
 .../network/services/hostapd/files/wpa_supplicant-p2p.config | 5 +
 7 files changed, 35 insertions(+)

diff --git a/package/network/services/hostapd/files/hostapd-basic.config 
b/package/network/services/hostapd/files/hostapd-basic.config
index 461b178433..19ea850f6b 100644
--- a/package/network/services/hostapd/files/hostapd-basic.config
+++ b/package/network/services/hostapd/files/hostapd-basic.config
@@ -394,3 +394,8 @@ CONFIG_TLS=internal
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+#CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/hostapd-full.config 
b/package/network/services/hostapd/files/hostapd-full.config
index 5c9fbed2e4..0ecce423e7 100644
--- a/package/network/services/hostapd/files/hostapd-full.config
+++ b/package/network/services/hostapd/files/hostapd-full.config
@@ -394,3 +394,8 @@ CONFIG_TAXONOMY=y
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/hostapd-mini.config 
b/package/network/services/hostapd/files/hostapd-mini.config
index f31e6467b0..d9511441e6 100644
--- a/package/network/services/hostapd/files/hostapd-mini.config
+++ b/package/network/services/hostapd/files/hostapd-mini.config
@@ -394,3 +394,8 @@ CONFIG_TLS=internal
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+#CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/wpa_supplicant-basic.config 
b/package/network/services/hostapd/files/wpa_supplicant-basic.config
index e2bd1866c4..a9da65deed 100644
--- a/package/network/services/hostapd/files/wpa_supplicant-basic.config
+++ b/package/network/services/hostapd/files/wpa_supplicant-basic.config
@@ -618,3 +618,8 @@ CONFIG_GETRANDOM=y
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+#CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/wpa_supplicant-full.config 
b/package/network/services/hostapd/files/wpa_supplicant-full.config
index e5a6752a8e..982f4d5534 100644
--- a/package/network/services/hostapd/files/wpa_supplicant-full.config
+++ b/package/network/services/hostapd/files/wpa_supplicant-full.config
@@ -618,3 +618,8 @@ CONFIG_IBSS_RSN=y
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/wpa_supplicant-mini.config 
b/package/network/services/hostapd/files/wpa_supplicant-mini.config
index 6af4693c53..850d22febc 100644
--- a/package/network/services/hostapd/files/wpa_supplicant-mini.config
+++ b/package/network/services/hostapd/files/wpa_supplicant-mini.config
@@ -618,3 +618,8 @@ CONFIG_GETRANDOM=y
 # Services can connect to the bus and provide methods
 # that can be called by other services or clients.
 CONFIG_UBUS=y
+
+# OpenWrt patch 380-disable-ctrl-iface-mib.patch
+# leads to the MIB only being compiled in if
+# CONFIG_CTRL_IFACE_MIB is enabled.
+#CONFIG_CTRL_IFACE_MIB=y
diff --git a/package/network/services/hostapd/files/wpa_supplicant-p2p.config

[no subject]

2021-01-14 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows configuration of multicast_to_unicast and per_sta_vif options.
- multicast_to_unicast requests multicast-to-unicast conversion.
- per_sta_vif assigns each station its own AP_VLAN interface.

Backport from master.

Signed-off-by: Etan Kissling 
---
 package/network/services/hostapd/files/hostapd.sh | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 79e71616dc..603b5a0c80 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -245,6 +245,8 @@ hostapd_common_add_bss_config() {
config_add_boolean sae_require_mfp

config_add_string 'owe_transition_bssid:macaddr' 
'owe_transition_ssid:string'
+
+   config_add_boolean multicast_to_unicast per_sta_vif
 }
 
 hostapd_set_bss_options() {
@@ -267,7 +269,8 @@ hostapd_set_bss_options() {
iapp_interface eapol_version dynamic_vlan ieee80211w nasid \
acct_server acct_secret acct_port acct_interval \
bss_load_update_period chan_util_avg_period sae_require_mfp \
-   multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key
+   multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key \
+   multicast_to_unicast per_sta_vif
 
set_default isolate 0
set_default maxassoc 0
@@ -627,6 +630,16 @@ hostapd_set_bss_options() {
}
}
 
+   set_default multicast_to_unicast 0
+   if [ "$multicast_to_unicast" -gt 0 ]; then
+   append bss_conf "multicast_to_unicast=$multicast_to_unicast" 
"$N"
+   fi
+
+   set_default per_sta_vif 0
+   if [ "$per_sta_vif" -gt 0 ]; then
+   append bss_conf "per_sta_vif=$per_sta_vif" "$N"
+   fi
+
append "$var" "$bss_conf" "$N"
return 0
 }
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-14 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This adds a config option to allow compiling with HKDF algorithm support
to support applications that require this feature.

Backport from master.

Signed-off-by: Etan Kissling 
---
 package/libs/mbedtls/Makefile | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
index 04033b1e47..ea8df0783c 100644
--- a/package/libs/mbedtls/Makefile
+++ b/package/libs/mbedtls/Makefile
@@ -20,7 +20,9 @@ PKG_BUILD_PARALLEL:=1
 PKG_LICENSE:=GPL-2.0+
 PKG_CPE_ID:=cpe:/a:arm:mbed_tls
 
-PKG_CONFIG_DEPENDS:=CONFIG_LIBMBEDTLS_DEBUG_C
+PKG_CONFIG_DEPENDS := \
+   CONFIG_LIBMBEDTLS_DEBUG_C \
+   CONFIG_LIBMBEDTLS_HKDF_C
 
 include $(INCLUDE_DIR)/package.mk
 include $(INCLUDE_DIR)/cmake.mk
@@ -56,6 +58,14 @@ config LIBMBEDTLS_DEBUG_C
 by around 60 KiB (for an ARMv5 platform).
 
 Usually, you don't need this, so don't select this if you're unsure.
+
+config LIBMBEDTLS_HKDF_C
+   depends on PACKAGE_libmbedtls
+   bool "Enable the HKDF algorithm (RFC 5869)"
+   default n
+   help
+This option adds support for the Hashed Message Authentication Code
+(HMAC)-based key derivation function (HKDF).
 endef
 
 define Package/mbedtls-util
@@ -96,6 +106,13 @@ define Build/Configure
 END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
 >$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
+
+   awk 'BEGIN { rc = 1 } \
+/#define MBEDTLS_HKDF_C/ { 0 = "$(if 
$(CONFIG_LIBMBEDTLS_HKDF_C),,// )#define MBEDTLS_HKDF_C"; rc = 0 } \
+{ print } \
+END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
+>$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
+   mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
 endef
 
 define Build/InstallDev
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-13 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows configuration of multicast_to_unicast and per_sta_vif options.
- multicast_to_unicast requests multicast-to-unicast conversion.
- per_sta_vif assigns each station its own AP_VLAN interface.

Signed-off-by: Etan Kissling 
---
 package/network/services/hostapd/Makefile |  2 +-
 package/network/services/hostapd/files/hostapd.sh | 15 ++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/package/network/services/hostapd/Makefile 
b/package/network/services/hostapd/Makefile
index f57b072974..a6d56d1433 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=hostapd
-PKG_RELEASE:=23
+PKG_RELEASE:=24
 
 PKG_SOURCE_URL:=http://w1.fi/hostap.git
 PKG_SOURCE_PROTO:=git
diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 7d9ee5121e..cee9a8eaa2 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -331,6 +331,8 @@ hostapd_common_add_bss_config() {
config_add_array airtime_sta_weight
config_add_int airtime_bss_weight airtime_bss_limit
 
+   config_add_boolean multicast_to_unicast per_sta_vif
+
config_add_array hostapd_bss_options
 }
 
@@ -480,7 +482,8 @@ hostapd_set_bss_options() {
acct_server acct_secret acct_port acct_interval \
bss_load_update_period chan_util_avg_period sae_require_mfp \
multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key 
skip_inactivity_poll \
-   airtime_bss_weight airtime_bss_limit airtime_sta_weight
+   airtime_bss_weight airtime_bss_limit airtime_sta_weight \
+   multicast_to_unicast per_sta_vif
 
set_default isolate 0
set_default maxassoc 0
@@ -942,6 +945,16 @@ hostapd_set_bss_options() {
json_for_each_item append_operator_icon operator_icon
fi
 
+   set_default multicast_to_unicast 0
+   if [ "$multicast_to_unicast" -gt 0 ]; then
+   append bss_conf "multicast_to_unicast=$multicast_to_unicast" 
"$N"
+   fi
+
+   set_default per_sta_vif 0
+   if [ "$per_sta_vif" -gt 0 ]; then
+   append bss_conf "per_sta_vif=$per_sta_vif" "$N"
+   fi
+
json_get_values opts hostapd_bss_options
for val in $opts; do
append bss_conf "$val" "$N"
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-12 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows configuration of multicast_to_unicast and per_sta_vif options.
- multicast_to_unicast requests multicast-to-unicast conversion.
- per_sta_vif assigns each station its own AP_VLAN interface.

Signed-off-by: Etan Kissling 
---
 package/network/services/hostapd/Makefile   |  2 +-
 .../network/services/hostapd/files/hostapd.sh   | 17 -
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/package/network/services/hostapd/Makefile 
b/package/network/services/hostapd/Makefile
index f57b072974..a6d56d1433 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=hostapd
-PKG_RELEASE:=23
+PKG_RELEASE:=24
 
 PKG_SOURCE_URL:=http://w1.fi/hostap.git
 PKG_SOURCE_PROTO:=git
diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 7d9ee5121e..4184926d19 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -331,6 +331,10 @@ hostapd_common_add_bss_config() {
config_add_array airtime_sta_weight
config_add_int airtime_bss_weight airtime_bss_limit
 
+   config_add_boolean multicast_to_unicast
+
+   config_add_boolean per_sta_vif
+
config_add_array hostapd_bss_options
 }
 
@@ -480,7 +484,8 @@ hostapd_set_bss_options() {
acct_server acct_secret acct_port acct_interval \
bss_load_update_period chan_util_avg_period sae_require_mfp \
multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key 
skip_inactivity_poll \
-   airtime_bss_weight airtime_bss_limit airtime_sta_weight
+   airtime_bss_weight airtime_bss_limit airtime_sta_weight \
+   multicast_to_unicast per_sta_vif
 
set_default isolate 0
set_default maxassoc 0
@@ -942,6 +947,16 @@ hostapd_set_bss_options() {
json_for_each_item append_operator_icon operator_icon
fi
 
+   set_default multicast_to_unicast 0
+   if [ "$multicast_to_unicast" -gt 0 ]; then
+   append bss_conf "multicast_to_unicast=$multicast_to_unicast" 
"$N"
+   fi
+
+   set_default per_sta_vif 0
+   if [ "$per_sta_vif" -gt 0 ]; then
+   append bss_conf "per_sta_vif=$per_sta_vif" "$N"
+   fi
+
json_get_values opts hostapd_bss_options
for val in $opts; do
append bss_conf "$val" "$N"
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-12 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This adds a config option to allow compiling with HKDF algorithm support
to support applications that require this feature.

Signed-off-by: Etan Kissling 
---
 package/libs/mbedtls/Makefile | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
index 27f50f8dde..79650b594a 100644
--- a/package/libs/mbedtls/Makefile
+++ b/package/libs/mbedtls/Makefile
@@ -21,7 +21,9 @@ PKG_LICENSE:=GPL-2.0-or-later
 PKG_LICENSE_FILES:=gpl-2.0.txt
 PKG_CPE_ID:=cpe:/a:arm:mbed_tls
 
-PKG_CONFIG_DEPENDS:=CONFIG_LIBMBEDTLS_DEBUG_C
+PKG_CONFIG_DEPENDS := \
+   CONFIG_LIBMBEDTLS_DEBUG_C \
+   CONFIG_LIBMBEDTLS_HKDF_C
 
 include $(INCLUDE_DIR)/package.mk
 include $(INCLUDE_DIR)/cmake.mk
@@ -57,6 +59,14 @@ config LIBMBEDTLS_DEBUG_C
 by around 60 KiB (for an ARMv5 platform).
 
 Usually, you don't need this, so don't select this if you're unsure.
+
+config LIBMBEDTLS_HKDF_C
+   depends on PACKAGE_libmbedtls
+   bool "Enable the HKDF algorithm (RFC 5869)"
+   default n
+   help
+This option adds support for the Hashed Message Authentication Code
+(HMAC)-based key derivation function (HKDF).
 endef
 
 define Package/mbedtls-util
@@ -97,6 +107,13 @@ define Build/Configure
 END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
 >$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
+
+   awk 'BEGIN { rc = 1 } \
+/#define MBEDTLS_HKDF_C/ { 0 = "$(if 
$(CONFIG_LIBMBEDTLS_HKDF_C),,// )#define MBEDTLS_HKDF_C"; rc = 0 } \
+{ print } \
+END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
+>$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
+   mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
 endef
 
 define Build/InstallDev
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-12 Thread Etan Kissling via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows libnetfilter_queue to access connection tracking information
by requesting NFQA_CFG_F_CONNTRACK. Connection tracking information is
provided in the NFQA_CT attribute.
CONFIG_NETFILTER_NETLINK_GLUE_CT enables the interaction between
nf_queue and nf_conntrack_netlink. Without this option, trying to access
connection tracking information results in "Operation not supported".

Signed-off-by: Etan Kissling 
---
 package/kernel/linux/modules/netfilter.mk | 2 +-
 target/linux/generic/config-5.4   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/netfilter.mk 
b/package/kernel/linux/modules/netfilter.mk
index aacf5948b1..b46fcebc08 100644
--- a/package/kernel/linux/modules/netfilter.mk
+++ b/package/kernel/linux/modules/netfilter.mk
@@ -1002,7 +1002,7 @@ $(eval $(call KernelPackage,nfnetlink-queue))
 define KernelPackage/nf-conntrack-netlink
   TITLE:=Connection tracking netlink interface
   FILES:=$(LINUX_DIR)/net/netfilter/nf_conntrack_netlink.ko
-  KCONFIG:=CONFIG_NF_CT_NETLINK CONFIG_NF_CONNTRACK_EVENTS=y
+  KCONFIG:=CONFIG_NF_CT_NETLINK CONFIG_NF_CONNTRACK_EVENTS=y 
CONFIG_NETFILTER_NETLINK_GLUE_CT=y
   AUTOLOAD:=$(call AutoProbe,nf_conntrack_netlink)
   $(call AddDepends/nfnetlink,+kmod-ipt-conntrack)
 endef
diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index 9006c63ecf..15d235fea5 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -3672,6 +3672,7 @@ CONFIG_NF_CONNTRACK_PROCFS=y
 # CONFIG_NF_CONNTRACK_ZONES is not set
 # CONFIG_NF_CT_NETLINK is not set
 # CONFIG_NF_CT_NETLINK_TIMEOUT is not set
+# CONFIG_NF_CT_NETLINK_HELPER is not set
 # CONFIG_NF_CT_PROTO_DCCP is not set
 # CONFIG_NF_CT_PROTO_GRE is not set
 # CONFIG_NF_CT_PROTO_SCTP is not set
-- 
2.21.1 (Apple Git-122.3)




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-12 Thread Gagan Sidhu via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
hi,

i have spoken with someone who is privy to all things RALINK (see here: 
https://github.com/hanwckf/rt-n56u/issues/562).

i have learned that we need to add wifi hardware NAT to unlock the full 
performance of the driver.

i yearned to use the raeth driver but i could not get it to work on linux 4.x. 
i suspect this is why the mtk_eth_soc driver was created?

anyways: i assume what he is saying is correct? that we need hardware nat for 
wifi in order to get full performance? are there any plans to add this?

to the wizard blogic: isn’t there an easy way for you to work your magic to fix 
the raether driver so i can evaluate the claim?

Thanks,
Gagan



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-12 Thread Etan Kissling (IC) via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows libnetfilter_queue to access connection tracking information
by requesting NFQA_CFG_F_CONNTRACK. Connection tracking information is
provided in the NFQA_CT attribute.
CONFIG_NETFILTER_NETLINK_GLUE_CT enables the interaction between
nf_queue and nf_conntrack_netlink. Without this option, trying to access
connection tracking information results in "Operation not supported".

Signed-off-by: Etan Kissling 
---
 package/kernel/linux/modules/netfilter.mk | 2 +-
 target/linux/generic/config-5.4   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/netfilter.mk 
b/package/kernel/linux/modules/netfilter.mk
index aacf5948b1..b46fcebc08 100644
--- a/package/kernel/linux/modules/netfilter.mk
+++ b/package/kernel/linux/modules/netfilter.mk
@@ -1002,7 +1002,7 @@ $(eval $(call KernelPackage,nfnetlink-queue))
 define KernelPackage/nf-conntrack-netlink
   TITLE:=Connection tracking netlink interface
   FILES:=$(LINUX_DIR)/net/netfilter/nf_conntrack_netlink.ko
-  KCONFIG:=CONFIG_NF_CT_NETLINK CONFIG_NF_CONNTRACK_EVENTS=y
+  KCONFIG:=CONFIG_NF_CT_NETLINK CONFIG_NF_CONNTRACK_EVENTS=y 
CONFIG_NETFILTER_NETLINK_GLUE_CT=y
   AUTOLOAD:=$(call AutoProbe,nf_conntrack_netlink)
   $(call AddDepends/nfnetlink,+kmod-ipt-conntrack)
 endef
diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index 9006c63ecf..15d235fea5 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -3672,6 +3672,7 @@ CONFIG_NF_CONNTRACK_PROCFS=y
 # CONFIG_NF_CONNTRACK_ZONES is not set
 # CONFIG_NF_CT_NETLINK is not set
 # CONFIG_NF_CT_NETLINK_TIMEOUT is not set
+# CONFIG_NF_CT_NETLINK_HELPER is not set
 # CONFIG_NF_CT_PROTO_DCCP is not set
 # CONFIG_NF_CT_PROTO_GRE is not set
 # CONFIG_NF_CT_PROTO_SCTP is not set
-- 
2.21.1 (Apple Git-122.3)



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-12 Thread Etan Kissling (IC) via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows configuration of multicast_to_unicast and per_sta_vif options.
- multicast_to_unicast requests multicast-to-unicast conversion.
- per_sta_vif assigns each station its own AP_VLAN interface.

Signed-off-by: Etan Kissling 
---
 package/network/services/hostapd/Makefile   |  2 +-
 .../network/services/hostapd/files/hostapd.sh   | 17 -
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/package/network/services/hostapd/Makefile 
b/package/network/services/hostapd/Makefile
index f57b072974..a6d56d1433 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=hostapd
-PKG_RELEASE:=23
+PKG_RELEASE:=24
 
 PKG_SOURCE_URL:=http://w1.fi/hostap.git
 PKG_SOURCE_PROTO:=git
diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 7d9ee5121e..4184926d19 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -331,6 +331,10 @@ hostapd_common_add_bss_config() {
config_add_array airtime_sta_weight
config_add_int airtime_bss_weight airtime_bss_limit
 
+   config_add_boolean multicast_to_unicast
+
+   config_add_boolean per_sta_vif
+
config_add_array hostapd_bss_options
 }
 
@@ -480,7 +484,8 @@ hostapd_set_bss_options() {
acct_server acct_secret acct_port acct_interval \
bss_load_update_period chan_util_avg_period sae_require_mfp \
multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key 
skip_inactivity_poll \
-   airtime_bss_weight airtime_bss_limit airtime_sta_weight
+   airtime_bss_weight airtime_bss_limit airtime_sta_weight \
+   multicast_to_unicast per_sta_vif
 
set_default isolate 0
set_default maxassoc 0
@@ -942,6 +947,16 @@ hostapd_set_bss_options() {
json_for_each_item append_operator_icon operator_icon
fi
 
+   set_default multicast_to_unicast 0
+   if [ "$multicast_to_unicast" -gt 0 ]; then
+   append bss_conf "multicast_to_unicast=$multicast_to_unicast" 
"$N"
+   fi
+
+   set_default per_sta_vif 0
+   if [ "$per_sta_vif" -gt 0 ]; then
+   append bss_conf "per_sta_vif=$per_sta_vif" "$N"
+   fi
+
json_get_values opts hostapd_bss_options
for val in $opts; do
append bss_conf "$val" "$N"
-- 
2.21.1 (Apple Git-122.3)



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-12 Thread Etan Kissling (IC) via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This adds a config option to allow compiling with HKDF algorithm support
to support applications that require this feature.

Signed-off-by: Etan Kissling 
---
 package/libs/mbedtls/Makefile | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
index 27f50f8dde..79650b594a 100644
--- a/package/libs/mbedtls/Makefile
+++ b/package/libs/mbedtls/Makefile
@@ -21,7 +21,9 @@ PKG_LICENSE:=GPL-2.0-or-later
 PKG_LICENSE_FILES:=gpl-2.0.txt
 PKG_CPE_ID:=cpe:/a:arm:mbed_tls
 
-PKG_CONFIG_DEPENDS:=CONFIG_LIBMBEDTLS_DEBUG_C
+PKG_CONFIG_DEPENDS := \
+   CONFIG_LIBMBEDTLS_DEBUG_C \
+   CONFIG_LIBMBEDTLS_HKDF_C
 
 include $(INCLUDE_DIR)/package.mk
 include $(INCLUDE_DIR)/cmake.mk
@@ -57,6 +59,14 @@ config LIBMBEDTLS_DEBUG_C
 by around 60 KiB (for an ARMv5 platform).
 
 Usually, you don't need this, so don't select this if you're unsure.
+
+config LIBMBEDTLS_HKDF_C
+   depends on PACKAGE_libmbedtls
+   bool "Enable the HKDF algorithm (RFC 5869)"
+   default n
+   help
+This option adds support for the Hashed Message Authentication Code
+(HMAC)-based key derivation function (HKDF).
 endef
 
 define Package/mbedtls-util
@@ -97,6 +107,13 @@ define Build/Configure
 END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
 >$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
+
+   awk 'BEGIN { rc = 1 } \
+/#define MBEDTLS_HKDF_C/ { 0 = "$(if 
$(CONFIG_LIBMBEDTLS_HKDF_C),,// )#define MBEDTLS_HKDF_C"; rc = 0 } \
+{ print } \
+END { exit(rc) }' $(PKG_BUILD_DIR)/include/mbedtls/config.h \
+>$(PKG_BUILD_DIR)/include/mbedtls/config.h.new && \
+   mv $(PKG_BUILD_DIR)/include/mbedtls/config.h.new 
$(PKG_BUILD_DIR)/include/mbedtls/config.h
 endef
 
 define Build/InstallDev
-- 
2.21.1 (Apple Git-122.3)



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-11 Thread Gagan Sidhu via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
yeah, it will.

i don’t like how many files there are. 

i was looking at the 8xx-x1, 882-a1 and mt7621.dtsi. completely overlooked 
there may have also been an 882-x1.dtsi *eye roll*
-sometimes “factorisation” is a freakin’ nuisance.

this will for sure fix that problem. if only we could attach this to the 
mailing list to show how dumb i am (i have put it as a recipient).

thanks again pal

Thanks,
Gagan

> On Jan 11, 2021, at 4:45 PM, Alberto Bursi  wrote:
> 
> Yeah if you are hacking the dts for your custom build then you can just 
> copy-paste the contents of that file and it should fix the leds
> 
> -Alberto
> 
> On 12/01/21 00:40, Gagan Sidhu wrote:
>> nah this should work, thank you.
>> i am using the DTSes but not in the exact same way.
>> this is partially due to me using kernel 4.x and thus the mt7621.dtsi has 
>> slightly different properties.
>>  - wouldn’t work with 4.x mtk_eth_soc ethernet driver (esp w/  hardware nat 
>> and flow offload, no longer in driver).
>> thank you sir!
>> Thanks,
>> Gagan
>>> On Jan 11, 2021, at 4:38 PM, Alberto Bursi >> > wrote:
>>> 
>>> If you look at the commit that added support for that device:
>>> https://github.com/openwrt/openwrt/commit/28262f815e4d0fe5302babc696ed5ce518b33759
>>> 
>>> 
>>> you see that your device's dts is this file
>>> https://github.com/openwrt/openwrt/tree/master/target/linux/ramips/dts/mt7621_dlink_dir-882-r1.dts
>>> 
>>> and it is calling in two other dts files where most of the contents are.
>>> One is the one you also linked, the other is this
>>> https://github.com/openwrt/openwrt/tree/master/target/linux/ramips/dts/mt7621_dlink_dir-882-x1.dtsi
>>> 
>>> where you actually find that both USB leds are defined and have default 
>>> trigger set to "usbport".
>>> 
>>> 
>>> I don't know why it does not work in your device, maybe there is a typo 
>>> somewhere 
>>> or it is a slightly different hardware revision where the USB leds are on a 
>>> different GPIO line.
>>> 
>>> If it matters to you you can send an email to the guy that added support 
>>> for this device (his email is in the commit above), and ask him.
>>> 
>>> Just waiting works for things that are not developed by OpenWrt (the wifi 
>>> driver comes from Linux, upstream), 
>>> but is not the best way to solve OpenWrt-specific issues like wrong ports 
>>> or leds or whatever.
>>> 
>>> -Alberto
>>> 
>>> 
>>> On 11/01/21 20:17, Gagan Sidhu wrote:
 hi alberto,
 yeah i checked out the latest git and this is the relevant DTS file:
 https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621_dlink_dir-8xx-x1.dtsi
  
 i am assuming it’s not trivial to add the usb trigger and that’s why it is 
 not done.
 it’s not a huge concern at this point anyways.
-it seems the driver still needs a bit more work on the mt7615 chipset.
 -mind you, it’s markedly improved from two years ago, but i’ve had a 
 few-too-many niggles on 5 Ghz (2.4Ghz works well) so i’m sitting pat.
 who knows, maybe it’ll be dealt with in a few months.
 Thanks,
 Gagan
> On Jan 11, 2021, at 12:14 PM, Alberto Bursi  > wrote:
> 
> 
> On 09/01/21 03:54, Gagan Sidhu via openwrt-devel wrote:
>> The sender domain has a DMARC Reject/Quarantine policy which disallows
>> sending mailing list messages using the original "From" header.
>> To mitigate this problem, the original message has been wrapped
>> hi,
> 
>> using the latest stuff from you guys, and i noticed the usb leds aren’t 
>> included in the dts.
>> is there an option i’m missing?
> 
>> currently i have:
>> CONFIG_NEW_LEDS=y
>> CONFIG_LEDS_CLASS=y
>> CONFIG_LEDS_GPIO=y
>> CONFIG_LED_TRIGGER_PHY=y
>> CONFIG_USB_LEDS_TRIGGER_USBPORT=y
>> CONFIG_LEDS_TRIGGER_GPIO=y
> 
>> enabled. what could i be missing?
> 
>> nice to see mt76 caught up to the proprietary driver.
> 
>> Thanks,
>> Gagan
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org 
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> The things you posted are kernel config, if there is no usb led defined 
> in dts file then that led will never work until you add it to the dts.
> 
> What device is this? Did you check the commit of the person that added it 
> to OpenWrt? Maybe they explain why there is no USB led.
> 
> -Alberto



Thanks,
Gagan
--- End Message ---
___
openwrt-devel mailing

[no subject]

2021-01-10 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 30ad7cf7a1e802d2e1f2f27ffd66511ed88e8f3e
  
https://github.com/sdwalker/sdwalker.github.io/commit/30ad7cf7a1e802d2e1f2f27ffd66511ed88e8f3e
  Author: Stephen Walker 
  Date:   2021-01-10 (Sun, 10 Jan 2021)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-08 Thread Gagan Sidhu via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
hi,

using the latest stuff from you guys, and i noticed the usb leds aren’t 
included in the dts.

is there an option i’m missing?

currently i have:
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LED_TRIGGER_PHY=y
CONFIG_USB_LEDS_TRIGGER_USBPORT=y
CONFIG_LEDS_TRIGGER_GPIO=y

enabled. what could i be missing?

nice to see mt76 caught up to the proprietary driver.

Thanks,
Gagan



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2021-01-03 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 6eb5c461a6b1ad2624fb0190178f9eb1e490cad9
  
https://github.com/sdwalker/sdwalker.github.io/commit/6eb5c461a6b1ad2624fb0190178f9eb1e490cad9
  Author: Stephen Walker 
  Date:   2021-01-03 (Sun, 03 Jan 2021)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-12-27 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: f5c2a11c017037f7485363b0f37ff688e4340208
  
https://github.com/sdwalker/sdwalker.github.io/commit/f5c2a11c017037f7485363b0f37ff688e4340208
  Author: Stephen Walker 
  Date:   2020-12-27 (Sun, 27 Dec 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-12-20 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: eb9706cbc06151663c63b851c46b6606da289d22
  
https://github.com/sdwalker/sdwalker.github.io/commit/eb9706cbc06151663c63b851c46b6606da289d22
  Author: Stephen Walker 
  Date:   2020-12-20 (Sun, 20 Dec 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-12-15 Thread Zefir Kurtisi via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
When a FW upgrade is performed without keeping the
current config, the temporary overlay directory is
eventually empty and causes the archive copy to /
to fail. This has no functional impact but adds a
false 'failed to sync jffs2 overlay' to the error
log.

Fix this by explicitly checking for the directory
to exist and being non-empty.

Signed-off-by: Zefir Kurtisi 
---
 libfstools/overlay.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libfstools/overlay.c b/libfstools/overlay.c
index eadafcf..d3987a8 100644
--- a/libfstools/overlay.c
+++ b/libfstools/overlay.c
@@ -315,6 +315,11 @@ jffs2_switch(struct volume *v)
umount2("/tmp/root", MNT_DETACH);
foreachdir("/overlay/", handle_whiteout);
 
+   /* prevent below cp command failing with empty temporary 
overlay */
+   if (system("[ ! -d /tmp/root/upper ] || [ -z \"$(ls -A 
/tmp/root/upper/)\" ]")) {
+   ULOG_INFO("temporary overlay empty\n");
+   break;
+   }
/* try hard to be in sync */
ULOG_INFO("syncronizing overlay\n");
if (system("cp -a /tmp/root/upper/* / 2>/dev/null"))
-- 
2.17.1


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-12-13 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: e2aa12605a57f8b1a7f18fc7a4a1cb9a0aef6728
  
https://github.com/sdwalker/sdwalker.github.io/commit/e2aa12605a57f8b1a7f18fc7a4a1cb9a0aef6728
  Author: Stephen Walker 
  Date:   2020-12-13 (Sun, 13 Dec 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-12-06 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 260b079881c111afa4601cd3ce71017d88691dc1
  
https://github.com/sdwalker/sdwalker.github.io/commit/260b079881c111afa4601cd3ce71017d88691dc1
  Author: Stephen Walker 
  Date:   2020-12-06 (Sun, 06 Dec 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-12-03 Thread Hauke Mehrtens via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This adds the CONFIG_IRQSOFF_TRACER and the CONFIG_PREEMPT_TRACER kernel
configuration option to the OpenWrt menu. This can be used to debug
latencies in the system.
The CONFIG_PREEMPT_TRACER option needs the CONFIG_PREEMPT option which is
supposed to be used for Low-Latency Desktop and not used by many targets
in OpenWrt.

The help text is copied from the Linux kernel Kconfig.

Signed-off-by: Hauke Mehrtens 
---
 config/Config-kernel.in | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/config/Config-kernel.in b/config/Config-kernel.in
index 1cd9da4d12..ba724a2266 100644
--- a/config/Config-kernel.in
+++ b/config/Config-kernel.in
@@ -266,6 +266,40 @@ config KERNEL_FUNCTION_PROFILER
depends on KERNEL_FUNCTION_TRACER
default n
 
+config KERNEL_IRQSOFF_TRACER
+   bool "Interrupts-off Latency Tracer"
+   depends on KERNEL_FTRACE
+   help
+ This option measures the time spent in irqs-off critical
+ sections, with microsecond accuracy.
+
+ The default measurement method is a maximum search, which is
+ disabled by default and can be runtime (re-)started
+ via:
+
+ echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
+
+ (Note that kernel size and overhead increase with this option
+ enabled. This option and the preempt-off timing option can be
+ used together or separately.)
+
+config KERNEL_PREEMPT_TRACER
+   bool "Preemption-off Latency Tracer"
+   depends on KERNEL_FTRACE
+   help
+ This option measures the time spent in preemption-off critical
+ sections, with microsecond accuracy.
+
+ The default measurement method is a maximum search, which is
+ disabled by default and can be runtime (re-)started
+ via:
+
+ echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
+
+ (Note that kernel size and overhead increase with this option
+ enabled. This option and the irqs-off timing option can be
+ used together or separately.)
+
 config KERNEL_DEBUG_KERNEL
bool
default n
-- 
2.17.1


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-30 Thread Raylynn Knight via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
The snapshot builds for Octeon are missing the artifacts for the EdgeRouter and 
EdgeRouter Pro devices (artifacts should be identical).  I couldn’t figure out 
exactly what is wrong with the make file, but if I build locally and select:
 
* Target System (Cavium Networks Octeon)
* Target Profile (Multiple Devices)
* Target Devices
(*) Enable all profiles by default

All of the profiles except the Ubiquiti EdgeRouter profile are selected.  So 
whatever mechanism is used to determine all profiles is missing the Ubiquiti 
EdgeRouter profile.

Hoping someone more familiar with the build system constructs can fix this.

Thank you,
Ray
  
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-29 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: baaad5576ef71849be25f62d313595feaa87a480
  
https://github.com/sdwalker/sdwalker.github.io/commit/baaad5576ef71849be25f62d313595feaa87a480
  Author: Stephen Walker 
  Date:   2020-11-29 (Sun, 29 Nov 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-27 Thread Paul Oranje via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


> Op 20 nov. 2020, om 11:44 heeft Petr Štetiar  het volgende 
> geschreven:
> 
> Paul Spooren  [2020-11-19 13:09:02]:
> 
> Hi,
> 
>> while 20.xx seems close, 
> 
> I don't share your view on this one, 21.xx is close, yes :-) Just being
> realistic here. So I would say, that if this issue should be tackled, there is
> still some time left to do so.
> 
>> I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per
>> default.
> 
> Do we need to make this hard decission? Can't we leave it to the end users?
> We need most of the SSL stuff for other parts, so why not benefit from that in
> other parts?
> 
> For the start, can't we simply introduce some first time welcome page on HTTP,
> explain to the user, that HTTPS is available, the pros and cons of this
> solution and let the user decide?
> 
> In less intrusive way, this welcome page/wizard could be replaced with some
> information box "HTTPS is just a moments away", so the user would need to
> explicitly request that HTTPS feature.
> 
> There might be some better UX approach, but please try hard to move forward,
> not backward :-)

right, so +1

> 
> -- ynezz
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-27 Thread Paul Oranje via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


> Op 20 nov. 2020, om 03:24 heeft ansuels...@gmail.com het volgende geschreven:
> 
>> Given that the first login via LuCI, on a fresh install, is not with a
>> password anyway.  What if setting the initial password sets up
>> letsencrypt also. Then when letsencrypt's first successful cert install,
>> https gets enabled as the default and then requests the user reboot to
>> complete the setup and will force their next session to https.
>> 
>> I agree that https with self-signed certs are not good, especially on a
>> first boot/install device.
>> 
> 
> My 2 cents, I still think that have a properly verified cert is madness.
> I really think that to address this the best way would be to add a big
> And very explicative alert to the first login page.
> The process would be
> 1. First boot --> First login (no password set) Append to the already
> present alert about password-less system, an alert about self signed
> cert and that the browser will tell that the router page will not be secure.
> (again this must be very explicative and easy to understand)
> 2. As soon as the user set a password, the webserver is restarted with
> http disabled/redirected and https now enabled. The user should now
> know that the page is secure and that he can whitelist/allowlist(for the
> inclusive people :D) it.
> 
> This way the user won't be scared of unsecure page and can understand
> why the page is secure. Also if we want to push security to an upper level
> with self signed cert, we can ask the user to insert some data so that the
> self signed cert can be generated based on that and actually validated by
> the user (to prevent any MIT attack)

+1

The only conceivable way to proceed from a first start where security only 
exists in that the first run is in an environment not exposed to the evil world 
towards being exposed and prepared. That without having to rely on previously 
established (secure) DNS combined with DANE (and a webbrowser that does support 
DANE, currently not one mayor does) or a valid certificate which does not fit 
the use-case at hand.

> 
>> Cheers
>>  Derek
>> 
>> On 11/19/20 6:09 PM, Paul Spooren wrote:
>>> Hi,
>>> 
>>> The current list of release goals for 20.xx states[0] that LuCI should
>>> use HTTPS per default. This works by creating on-device a self-signed
>>> certificate. Self-signed certificates result in warnings and may cause
>>> more harm than good, multiple discussion are found in the mail archive.
>>> 
>>> As no clean solution seems in reach while 20.xx seems close, I'd like to
>>> suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default.
>>> 
>>> This isn't a vote but a request for developer/user opinions.
>>> 
>>> Sunshine,
>>> Paul
>>> 
>>> [0]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx
>>> 
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>> 
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-27 Thread Andreas Oberritter via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Nick,

On Fri, 27 Nov 2020 09:43:58 +0100
Nick  wrote:

> The current ipq40xx network stack does no longer work for a few targets:
> - Zyxel
> - Fritz!Box 4040
> - Fritz!Box 7530
> - ZyXEL NBG6617
> - GL-B1300
> - ...
> 
> Can we please finally add my PR? I introduced a kernel flag that is 
> about switching between the different options
> 1. Port Isolation
> 2. Nested VLANs
> ith this I hope to satisfy both sides.
> 
> Here is the PR:
> https://github.com/openwrt/openwrt/pull/3596

if this is a device specific setting, wouldn't it be better to use a DT 
property instead of adding a new compile-time switch?

Best regards,
Andreas

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-27 Thread Matthias May via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On 27/11/2020 19:14, Philip Prindeville wrote:
> Hi,
> 
> I’m working on a PR to add X.509 certificates to Strongswan for 
> authentication and that all seems to be working fine:
> 
> https://urldefense.com/v3/__https://github.com/openwrt/packages/pull/14028__;!!I9LPvj3b!XqJgJCi-P06au0EVChYdDT9yDGqBhoAn-1RAaa7TwM8adhFUNLSF3m_tjUIDs_smTQ$
>  
> 
> 
> But I can’t figure out why my traffic isn’t being passed, even though the 
> tunnel comes up:
> 
> *snipped*

Hi
See 
https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling
Also: 
https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg
xfrm lookup happens after the first round of postrouting NAT, thus you need 
something to accept the frames before they
are NATed.
This should be taken care of by your
config zone
option name vpn
option inputACCEPT
option output   ACCEPT
option forward  ACCEPT
option subnet   '192.168.1.0/24'
option extra_src'-m policy --dir in --pol ipsec --proto esp'
option extra_dest   '-m policy --dir out --pol ipsec --proto esp'
option mtu_fix  1

Can you show the output of
iptable -t nat -nvL

Another thing i could think of, is that your routing table entries are missing.
Usually strongswan would take care to set this up, but if you have
charon.install_routes = no
that would mean you have to manually take care to set the routes up.

What does your
ip rule
and ip route show table 220
show?
Table 220 is the "default" for ipsec, but may be another value depending on 
configuration.

BR
Matthias

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-26 Thread Eneas Ulir de Queiroz via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
 On Thursday, November 26, 2020, 6:29:00 AM GMT-3, Rosen Penev 
 wrote: 

> On Thu, Nov 26, 2020 at 12:26 AM, Petr Štetiar  wrote:

>> Rosen Penev  [2020-11-24 02:04:24]: Hi, 
>>>  It seems the Makefile wrongly picks up dist CC and matches on a clang 
>>>path. Fixes: mips-openwrt-linux-musl-gcc: error: unrecognized command-line 
>>>option '-Qunused-arguments' 
>> then the fix seems wrong. You should make sure, that proper CC is used.
> Yeah. I CC'd cotequeiroz to get his comment on this. No dice so far.

Sorry.  I've been busy lately, but I'll take a look at it over the weekend.  I 
agree with ynezz, we should ensure the right CC is used.

Cheers,

Eneas

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-23 Thread SAn via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Sven, yes this is very useful. I will try to test it this week and report 
back.

Thanks!
SAn

On 11/23/20 1:30 PM, Sven Eckelmann wrote:
> On Monday, 3 August 2020 00:49:40 CET SAn via openwrt-devel wrote:
>> The LibreRouter uses a dual-boot scheme that relies on the bootloader 
>> configuring the kernel cmdline. At ar71xx 18.06 it was possible to select 
>> per device if the cmdline from the bootloader has to be honored (using 
>> patch-cmdline).
>> AFAIK there is no such possibility on ath79.
> 
> There should be the possibility to fix this by dropping the bootargs property 
> from the /chosen/ node. But the MIPS kernel code had a bug which was recently 
> fixed upstream [1]. The fix must still be integrated [2] into OpenWrt.
> 
> The only code necessary in the dts is:
> 
> / {
>   chosen {
>   /delete-property/ bootargs;
>   };
> };
> 
> I hope this helps you.
> 
> Kind regards,
>   Sven
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7784cac697351f0cc0a4bb619594c0c99348c5aa
> [2] (pending because I have to walk to the office to pick up my P300 test 
>  devices)
> 
> https://github.com/ecsv/openwrt/commit/6e4750615dee12c3fd8ce14174fd91fc18fac498
> 

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-22 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: dc5ad50a9581c4e6d7f156e38350d644b88216b7
  
https://github.com/sdwalker/sdwalker.github.io/commit/dc5ad50a9581c4e6d7f156e38350d644b88216b7
  Author: Stephen Walker 
  Date:   2020-11-22 (Sun, 22 Nov 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-22 Thread Paulo Machado via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Remove a syntax error from ImageBuider Makefile

Signed-off-by: Paulo Machado 
---
 target/imagebuilder/files/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/imagebuilder/files/Makefile 
b/target/imagebuilder/files/Makefile
index 65cba92b32..2d1e040286 100644
--- a/target/imagebuilder/files/Makefile
+++ b/target/imagebuilder/files/Makefile
@@ -138,7 +138,7 @@ package_index: FORCE
(cd $(PACKAGE_DIR); $(SCRIPT_DIR)/ipkg-make-index.sh . > Packages && \
gzip -9nc Packages > Packages.gz; \
$(if $(CONFIG_SIGNATURE_CHECK), \
-   $(STAGING_DIR_HOST)/bin/usign -S -m Packages -s 
$(BUILD_KEY)); \
+   $(STAGING_DIR_HOST)/bin/usign -S -m Packages -s 
$(BUILD_KEY)) \
) >/dev/null 2>/dev/null
$(OPKG) update >&2 || true
 
-- 
2.28.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-17 Thread Paul Oranje via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Op 14 nov. 2020, om 12:14 heeft Jo-Philipp Wich  het volgende 
geschreven:
> 
> Hi,
> 
>> Are there any real blockers left?
> 
> LuCI support for bridge-vlan config is unmerged/unpolished yet.
> 
> I'd rather not ship 20.x without functioning switch config support in
> the ui.
Which platforms still have to make the switch to DSA in master ?

> 
> ~ Jo
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-17 Thread Filip Moc via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
There already was an option for autoconfiguring IPv4 from QMI but this
was removed by commit 3b9b963e6e08 ("uqmi: always use DHCP for IPv4").

DHCP does not work on MR400 LTE module (in TL-MR6400 v4) so let's readd
support for IPv4 autoconf from QMI but this time allow to configure this
for IPv4 and IPv6 independently and keep DHCP default on IPv4.

Signed-off-by: Filip Moc 
---
 .../utils/uqmi/files/lib/netifd/proto/qmi.sh  | 49 ++-
 1 file changed, 38 insertions(+), 11 deletions(-)

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 8cbe9e97e7..7870eb7382 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -19,6 +19,7 @@ proto_qmi_init_config() {
proto_config_add_string modes
proto_config_add_string pdptype
proto_config_add_int profile
+   proto_config_add_boolean dhcp
proto_config_add_boolean dhcpv6
proto_config_add_boolean autoconnect
proto_config_add_int plmn
@@ -31,13 +32,13 @@ proto_qmi_setup() {
local interface="$1"
local dataformat connstat
local device apn auth username password pincode delay modes pdptype
-   local profile dhcpv6 autoconnect plmn timeout mtu $PROTO_DEFAULT_OPTIONS
+   local profile dhcp dhcpv6 autoconnect plmn timeout mtu 
$PROTO_DEFAULT_OPTIONS
local ip4table ip6table
local cid_4 pdh_4 cid_6 pdh_6
local ip_6 ip_prefix_length gateway_6 dns1_6 dns2_6
 
json_get_vars device apn auth username password pincode delay modes
-   json_get_vars pdptype profile dhcpv6 autoconnect plmn ip4table
+   json_get_vars pdptype profile dhcp dhcpv6 autoconnect plmn ip4table
json_get_vars ip6table timeout mtu $PROTO_DEFAULT_OPTIONS
 
[ "$timeout" = "" ] && timeout="10"
@@ -353,15 +354,41 @@ proto_qmi_setup() {
}
 
[ -n "$pdh_4" ] && {
-   json_init
-   json_add_string name "${interface}_4"
-   json_add_string ifname "@$interface"
-   json_add_string proto "dhcp"
-   [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
-   proto_add_dynamic_defaults
-   [ -n "$zone" ] && json_add_string zone "$zone"
-   json_close_object
-   ubus call network add_dynamic "$(json_dump)"
+   if [ "$dhcp" = 0 ]; then
+   json_load "$(uqmi -s -d $device --set-client-id 
wds,$cid_4 --get-current-settings)"
+   json_select ipv4
+   json_get_var ip_4 ip
+   json_get_var gateway_4 gateway
+   json_get_var dns1_4 dns1
+   json_get_var dns2_4 dns2
+   json_get_var subnet_4 subnet
+
+   proto_init_update "$ifname" 1
+   proto_set_keep 1
+   proto_add_ipv4_address "$ip_4" "$subnet_4"
+   proto_add_ipv4_route "$gateway_4" "128"
+   [ "$defaultroute" = 0 ] || proto_add_ipv4_route 
"0.0.0.0" 0 "$gateway_4"
+   [ "$peerdns" = 0 ] || {
+   proto_add_dns_server "$dns1_4"
+   proto_add_dns_server "$dns2_4"
+   }
+   [ -n "$zone" ] && {
+   proto_add_data
+   json_add_string zone "$zone"
+   proto_close_data
+   }
+   proto_send_update "$interface"
+   else
+   json_init
+   json_add_string name "${interface}_4"
+   json_add_string ifname "@$interface"
+   json_add_string proto "dhcp"
+   [ -n "$ip4table" ] && json_add_string ip4table 
"$ip4table"
+   proto_add_dynamic_defaults
+   [ -n "$zone" ] && json_add_string zone "$zone"
+   json_close_object
+   ubus call network add_dynamic "$(json_dump)"
+   fi
}
 }
 
-- 
2.28.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-16 Thread Filip Moc via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
There already was an option for autoconfiguring IPv4 from QMI but this
was removed by commit 3b9b963e6e08 ("uqmi: always use DHCP for IPv4").

DHCP does not work on MR400 LTE module (in TL-MR6400 v4) so let's readd
support for IPv4 autoconf from QMI but this time allow to configure this
for IPv4 and IPv6 independently and keep DHCP default on IPv4.

Signed-off-by: Filip Moc 
---
 .../utils/uqmi/files/lib/netifd/proto/qmi.sh  | 49 ++-
 1 file changed, 38 insertions(+), 11 deletions(-)

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 8cbe9e97e7..7870eb7382 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -19,6 +19,7 @@ proto_qmi_init_config() {
proto_config_add_string modes
proto_config_add_string pdptype
proto_config_add_int profile
+   proto_config_add_boolean dhcp
proto_config_add_boolean dhcpv6
proto_config_add_boolean autoconnect
proto_config_add_int plmn
@@ -31,13 +32,13 @@ proto_qmi_setup() {
local interface="$1"
local dataformat connstat
local device apn auth username password pincode delay modes pdptype
-   local profile dhcpv6 autoconnect plmn timeout mtu $PROTO_DEFAULT_OPTIONS
+   local profile dhcp dhcpv6 autoconnect plmn timeout mtu 
$PROTO_DEFAULT_OPTIONS
local ip4table ip6table
local cid_4 pdh_4 cid_6 pdh_6
local ip_6 ip_prefix_length gateway_6 dns1_6 dns2_6
 
json_get_vars device apn auth username password pincode delay modes
-   json_get_vars pdptype profile dhcpv6 autoconnect plmn ip4table
+   json_get_vars pdptype profile dhcp dhcpv6 autoconnect plmn ip4table
json_get_vars ip6table timeout mtu $PROTO_DEFAULT_OPTIONS
 
[ "$timeout" = "" ] && timeout="10"
@@ -353,15 +354,41 @@ proto_qmi_setup() {
}
 
[ -n "$pdh_4" ] && {
-   json_init
-   json_add_string name "${interface}_4"
-   json_add_string ifname "@$interface"
-   json_add_string proto "dhcp"
-   [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
-   proto_add_dynamic_defaults
-   [ -n "$zone" ] && json_add_string zone "$zone"
-   json_close_object
-   ubus call network add_dynamic "$(json_dump)"
+   if [ "$dhcp" = 0 ]; then
+   json_load "$(uqmi -s -d $device --set-client-id 
wds,$cid_4 --get-current-settings)"
+   json_select ipv4
+   json_get_var ip_4 ip
+   json_get_var gateway_4 gateway
+   json_get_var dns1_4 dns1
+   json_get_var dns2_4 dns2
+   json_get_var subnet_4 subnet
+
+   proto_init_update "$ifname" 1
+   proto_set_keep 1
+   proto_add_ipv4_address "$ip_4" "$subnet_4"
+   proto_add_ipv4_route "$gateway_4" "128"
+   [ "$defaultroute" = 0 ] || proto_add_ipv4_route 
"0.0.0.0" 0 "$gateway_4"
+   [ "$peerdns" = 0 ] || {
+   proto_add_dns_server "$dns1_4"
+   proto_add_dns_server "$dns2_4"
+   }
+   [ -n "$zone" ] && {
+   proto_add_data
+   json_add_string zone "$zone"
+   proto_close_data
+   }
+   proto_send_update "$interface"
+   else
+   json_init
+   json_add_string name "${interface}_4"
+   json_add_string ifname "@$interface"
+   json_add_string proto "dhcp"
+   [ -n "$ip4table" ] && json_add_string ip4table 
"$ip4table"
+   proto_add_dynamic_defaults
+   [ -n "$zone" ] && json_add_string zone "$zone"
+   json_close_object
+   ubus call network add_dynamic "$(json_dump)"
+   fi
}
 }
 
-- 
2.28.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-15 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 5dd2ae9224d1e76a442508642d26f1d87eae9ec7
  
https://github.com/sdwalker/sdwalker.github.io/commit/5dd2ae9224d1e76a442508642d26f1d87eae9ec7
  Author: Stephen Walker 
  Date:   2020-11-15 (Sun, 15 Nov 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-15 Thread Filip Moc via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi,

please could anyone give me a hint why did my patches not make it into 
patchwork?

Filip


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-14 Thread Filip Moc via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
You can flash via tftp recovery:
 - serve tftp-recovery image as /tp_recovery.bin on 192.168.0.225/24
 - connect to any ethernet port
 - power on the device while holding the reset button
 - wait at least 8 seconds before releasing reset button

Flashing via OEM web interface does not work.

LTE module does not support DHCP so it must be configured via QMI.

Hardware Specification (v4.0 EU):
 - SoC: MT7628NN
 - Flash: Winbond W25Q64JVS (8MiB)
 - RAM: ESMT M14D5121632A (64MiB)
 - Wireless: SoC platform only (2.4GHz b/g/n, 2x internal antenna)
 - Ethernet: 1NIC (4x100M)
 - WWAN: TP-LINK LTE MODULE (2x external detachable antenna)
 - Power: DC 9V 0.85A

Signed-off-by: Filip Moc 
---

Notes:
Bugs:
  This device is affected by first uqmi command hang.
  This causes qmi proto to hang sometimes when setting up wwan connection 
for
  the first time after boot.
  There is already a patch [1] which aims to fix this.
  So far it can be manually restarted or workarounded by editing qmi.sh [2].

There are also some other issues with LTE module which are addressed by
preceding patches.

[1] 
https://patchwork.ozlabs.org/project/openwrt/patch/20191107115408.13013-1-zefir.kurt...@neratec.com/
[2] https://forum.openwrt.org/t/solved-lte-qmi-troubles/28379

 .../dts/mt7628an_tplink_tl-mr6400-v4.dts  | 97 +++
 target/linux/ramips/image/mt76x8.mk   | 16 +++
 .../mt76x8/base-files/etc/board.d/01_leds |  5 +
 .../mt76x8/base-files/etc/board.d/02_network  |  4 +
 4 files changed, 122 insertions(+)
 create mode 100644 target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts

diff --git a/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts 
b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
new file mode 100644
index 00..9dc71ffd9e
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
@@ -0,0 +1,97 @@
+#include "mt7628an_tplink_8m.dtsi"
+
+/ {
+   compatible = "tplink,tl-mr6400-v4", "mediatek,mt7628an-soc";
+   model = "TP-Link TL-MR6400 v4";
+
+   aliases {
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 38 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   rfkill {
+   label = "rfkill";
+   gpios = < 46 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "white:power";
+   gpios = < 37 GPIO_ACTIVE_LOW>;
+   };
+
+   wan {
+   label = "white:wan";
+   gpios = < 39 GPIO_ACTIVE_LOW>;
+   };
+
+   wlan {
+   label = "white:wlan";
+   gpios = < 40 GPIO_ACTIVE_LOW>;
+   };
+
+   lan {
+   label = "white:lan";
+   gpios = < 41 GPIO_ACTIVE_LOW>;
+   };
+
+   signal1 {
+   label = "white:signal1";
+   gpios = < 42 GPIO_ACTIVE_LOW>;
+   };
+
+   signal2 {
+   label = "white:signal2";
+   gpios = < 43 GPIO_ACTIVE_LOW>;
+   };
+
+   signal3 {
+   label = "white:signal3";
+   gpios = < 44 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_default {
+   gpio {
+   groups = "p0led_an", "p1led_an", "p2led_an", "p3led_an", 
"p4led_an", "refclk", "uart1", "wdt", "wled_an";
+   function = "gpio";
+   };
+};
+
+ {
+   mediatek,portmap = <0x2f>;
+   mediatek,portdisable = <0x21>;
+};
+
+
+ {
+   mtd-mac-address = < 0x1f100>;
+};
+
+ {
+   mtd-mac-address = < 0x1f100>;
+};
diff --git a/target/linux/ramips/image/mt76x8.mk 
b/target/linux/ramips/image/mt76x8.mk
index 6327c95bb0..f3b25bf189 100644
--- a/target/linux/ramips/image/mt76x8.mk
+++ b/target/linux/ramips/image/mt76x8.mk
@@ -473,6 +473,22 @@ define Device/tplink_tl-mr3420-v5
 endef
 TARGET_DEVICES += tplink_tl-mr3420-v5
 
+define Device/tplink_tl-mr6400-v4
+  $(Device/tplink-v2)
+  IMAGE_SIZE := 7808k
+  DEVICE_MODEL := TL-MR6400
+  DEVICE_VARIANT := v4
+  TPLINK_FLASHLAYOUT

[no subject]

2020-11-14 Thread Filip Moc via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This is required for LTE module MR400 in TL-MR6400 v4.

Signed-off-by: Filip Moc 
---

Notes:
Perhaps it would be better to go upstream with this?

 ...usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch | 28 +++
 1 file changed, 28 insertions(+)
 create mode 100644 
target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch

diff --git 
a/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
 
b/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
new file mode 100644
index 00..9c15f01345
--- /dev/null
+++ 
b/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
@@ -0,0 +1,28 @@
+From a661d0b88c6de286f0b861ace670cb31776aadd6 Mon Sep 17 00:00:00 2001
+From: Filip Moc 
+Date: Wed, 11 Nov 2020 20:39:09 +0100
+Subject: [PATCH] net: usb: qmi_wwan: Set DTR quirk for MR400
+
+LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set.
+
+Signed-off-by: Filip Moc 
+---
+ drivers/net/usb/qmi_wwan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
+index 21d905d..da6f10a 100644
+--- a/drivers/net/usb/qmi_wwan.c
 b/drivers/net/usb/qmi_wwan.c
+@@ -1092,7 +1092,7 @@ static const struct usb_device_id products[] = {
+   {QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
+   {QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
+   {QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
+-  {QMI_FIXED_INTF(0x05c6, 0x9025, 4)},/* Alcatel-sbell ASB TL131 TDD 
LTE  (China Mobile) */
++  {QMI_QUIRK_SET_DTR(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB TL131 TDD 
LTE  (China Mobile) */
+   {QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
+   {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
+   {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
+-- 
+2.28.0
+
-- 
2.28.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-14 Thread Filip Moc via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This is required for LTE module MR400 (in TL-MR6400 v4).
Otherwise LTE module won't register to GSM network.

Signed-off-by: Filip Moc 
---
 package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 3 +++
 1 file changed, 3 insertions(+)

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 7870eb7382..dbfcdcb098 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -174,6 +174,9 @@ proto_qmi_setup() {
# Cleanup current state if any
uqmi -s -d "$device" --stop-network 0x --autoconnect > 
/dev/null 2>&1
 
+   # Go online
+   uqmi -s -d "$device" --set-device-operating-mode online > /dev/null 2>&1
+
# Set IP format
uqmi -s -d "$device" --set-data-format 802.3 > /dev/null 2>&1
uqmi -s -d "$device" --wda-set-data-format 802.3 > /dev/null 2>&1
-- 
2.28.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-14 Thread Filip Moc via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
There already was an option for autoconfiguring IPv4 from QMI but this
was removed by commit 3b9b963e6e08 ("uqmi: always use DHCP for IPv4").

DHCP does not work on MR400 LTE module (in TL-MR6400 v4) so let's readd
support for IPv4 autoconf from QMI but this time allow to configure this
for IPv4 and IPv6 independently and keep DHCP default on IPv4.

Signed-off-by: Filip Moc 
---
 .../utils/uqmi/files/lib/netifd/proto/qmi.sh  | 49 ++-
 1 file changed, 38 insertions(+), 11 deletions(-)

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 8cbe9e97e7..7870eb7382 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -19,6 +19,7 @@ proto_qmi_init_config() {
proto_config_add_string modes
proto_config_add_string pdptype
proto_config_add_int profile
+   proto_config_add_boolean dhcp
proto_config_add_boolean dhcpv6
proto_config_add_boolean autoconnect
proto_config_add_int plmn
@@ -31,13 +32,13 @@ proto_qmi_setup() {
local interface="$1"
local dataformat connstat
local device apn auth username password pincode delay modes pdptype
-   local profile dhcpv6 autoconnect plmn timeout mtu $PROTO_DEFAULT_OPTIONS
+   local profile dhcp dhcpv6 autoconnect plmn timeout mtu 
$PROTO_DEFAULT_OPTIONS
local ip4table ip6table
local cid_4 pdh_4 cid_6 pdh_6
local ip_6 ip_prefix_length gateway_6 dns1_6 dns2_6
 
json_get_vars device apn auth username password pincode delay modes
-   json_get_vars pdptype profile dhcpv6 autoconnect plmn ip4table
+   json_get_vars pdptype profile dhcp dhcpv6 autoconnect plmn ip4table
json_get_vars ip6table timeout mtu $PROTO_DEFAULT_OPTIONS
 
[ "$timeout" = "" ] && timeout="10"
@@ -353,15 +354,41 @@ proto_qmi_setup() {
}
 
[ -n "$pdh_4" ] && {
-   json_init
-   json_add_string name "${interface}_4"
-   json_add_string ifname "@$interface"
-   json_add_string proto "dhcp"
-   [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
-   proto_add_dynamic_defaults
-   [ -n "$zone" ] && json_add_string zone "$zone"
-   json_close_object
-   ubus call network add_dynamic "$(json_dump)"
+   if [ "$dhcp" = 0 ]; then
+   json_load "$(uqmi -s -d $device --set-client-id 
wds,$cid_4 --get-current-settings)"
+   json_select ipv4
+   json_get_var ip_4 ip
+   json_get_var gateway_4 gateway
+   json_get_var dns1_4 dns1
+   json_get_var dns2_4 dns2
+   json_get_var subnet_4 subnet
+
+   proto_init_update "$ifname" 1
+   proto_set_keep 1
+   proto_add_ipv4_address "$ip_4" "$subnet_4"
+   proto_add_ipv4_route "$gateway_4" "128"
+   [ "$defaultroute" = 0 ] || proto_add_ipv4_route 
"0.0.0.0" 0 "$gateway_4"
+   [ "$peerdns" = 0 ] || {
+   proto_add_dns_server "$dns1_4"
+   proto_add_dns_server "$dns2_4"
+   }
+   [ -n "$zone" ] && {
+   proto_add_data
+   json_add_string zone "$zone"
+   proto_close_data
+   }
+   proto_send_update "$interface"
+   else
+   json_init
+   json_add_string name "${interface}_4"
+   json_add_string ifname "@$interface"
+   json_add_string proto "dhcp"
+   [ -n "$ip4table" ] && json_add_string ip4table 
"$ip4table"
+   proto_add_dynamic_defaults
+   [ -n "$zone" ] && json_add_string zone "$zone"
+   json_close_object
+   ubus call network add_dynamic "$(json_dump)"
+   fi
}
 }
 
-- 
2.28.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-08 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: c8c39e7c4f9768a7c15d3eaae57bf05451fa8112
  
https://github.com/sdwalker/sdwalker.github.io/commit/c8c39e7c4f9768a7c15d3eaae57bf05451fa8112
  Author: Stephen Walker 
  Date:   2020-11-08 (Sun, 08 Nov 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-06 Thread Johann Neuhauser via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello community,

some time ago i saw the commit "hostapd: add support for wifi-station and 
wifi-vlan sections" [0] on master and I tried to get this up and running.

The goal was to replace my three SSIDs/BSSs, for example Home, Home_Gast and 
Home_IoT, with a single SSID, for example Home.
Every "old" SSID is attached to a own vlan and i want to use this new feature 
to squash them into a single SSID with three different PSKs so that depending 
on the used PSK the client gets attached to one of my three vlans.

The main goal is to save some airtime for the required beacons, but i never got 
this configuration running.

Has anybody played with this feature and can provide a working config as 
example?
Especially /etc/config/{wireless,network}.

I've used the following example configs:

/etc/config/network:
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

config interface 'lan3'
option type 'bridge'
option ifname 'eth3'
option proto 'static'
option ipaddr '192.168.3.1'
option netmask '255.255.255.0'
option ip6assign '60'

/etc/config/wireless:
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/ahb/1810.wmac'
option htmode 'HT20'

config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'psk2+ccmp'
option key 'testtest'

config wifi-vlan 'wifi_vlan100'
option iface 'default_radio0'
option name 'lan'
option vid '100'
option network 'lan3'

config wifi-station 'wifi_station100'
option iface 'default_radio0'
option vid '100'
option key 'testtest100'

With this configs i can connect to "OpenWrt" with PSK "testtest" and 
"testtest100" but for the last one i did not receive a dhcp lease.
With PSK "testest" my device get attached to "lan" and receives a ip from range 
192.168.1.0/24.

How can i assign the "wifi_station" to "lan3" (br-lan3) so that the devices 
gets a ip from range 192.168.3.0/24?

Thanks in advance.

Greets, Johann

[0] 
https://github.com/openwrt/openwrt/commit/5aa2ddd0d6b9759c62bbb7bb11b72a7f4269c16b

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-02 Thread pfzim--- via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
From: "Dmitry V. Zimin" 

This patch add the option --post-type to pass a custom Content-Type

Signed-off-by: Dmitry V. Zimin 
---
 uclient-fetch.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/uclient-fetch.c b/uclient-fetch.c
index 061f0fd..ac257e2 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -44,6 +44,7 @@
 static const char *user_agent = "uclient-fetch";
 static const char *post_data;
 static const char *post_file;
+static const char *post_type;
 static struct ustream_ssl_ctx *ssl_ctx;
 static const struct ustream_ssl_ops *ssl_ops;
 static int quiet = false;
@@ -345,13 +346,13 @@ static int init_request(struct uclient *cl)
check_resume_offset(cl);
 
if (post_data) {
-   uclient_http_set_header(cl, "Content-Type", 
"application/x-www-form-urlencoded");
+   uclient_http_set_header(cl, "Content-Type", post_type ? 
post_type : "application/x-www-form-urlencoded");
uclient_write(cl, post_data, strlen(post_data));
}
else if(post_file)
{
FILE *input_file;
-   uclient_http_set_header(cl, "Content-Type", 
"application/x-www-form-urlencoded");
+   uclient_http_set_header(cl, "Content-Type", post_type ? 
post_type : "application/x-www-form-urlencoded");
 
input_file = fopen(post_file, "r");
if (!input_file)
@@ -480,8 +481,9 @@ static int usage(const char *progname)
"   --user=   HTTP authentication 
username\n"
"   --password=   HTTP authentication 
password\n"
"   --user-agent|-USet 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"
+   "   --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"
+   "   --post-type=STRING  Set custom Content-Type 
for POST method\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"
@@ -539,6 +541,7 @@ enum {
L_USER_AGENT,
L_POST_DATA,
L_POST_FILE,
+   L_POST_TYPE,
L_SPIDER,
L_TIMEOUT,
L_CONTINUE,
@@ -556,6 +559,7 @@ static const struct option longopts[] = {
[L_USER_AGENT] = { "user-agent", required_argument },
[L_POST_DATA] = { "post-data", required_argument },
[L_POST_FILE] = { "post-file", required_argument },
+   [L_POST_TYPE] = { "post-type", required_argument },
[L_SPIDER] = { "spider", no_argument },
[L_TIMEOUT] = { "timeout", required_argument },
[L_CONTINUE] = { "continue", no_argument },
@@ -625,6 +629,9 @@ int main(int argc, char **argv)
case L_POST_FILE:
post_file = optarg;
break;
+   case L_POST_TYPE:
+   post_type = optarg;
+   break;
case L_SPIDER:
no_output = true;
break;
-- 
2.28.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-11-01 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 1e90a6b8ab392256e83309223add6f72c938f99a
  
https://github.com/sdwalker/sdwalker.github.io/commit/1e90a6b8ab392256e83309223add6f72c938f99a
  Author: Stephen Walker 
  Date:   2020-11-01 (Sun, 01 Nov 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html
M uscan/js/sort-18.06.js
M uscan/js/sort-19.07.js

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-30 Thread Raquel Carvalho via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Bom Dia,

A demanda por desinfetantes eficazes que permitam a eliminação de 
microrganismos prejudiciais é continuamente alta em todo o mundo.

Expandir a oferta com uma gama profissional de produtos com atividade viricida 
e bactericida permite aumentar a posição competitiva da empresa e construir 
novas redes de vendas.

Diversificamos a linha de atacadistas e distribuidores com sabonetes, líquidos 
e géis para desinfecção das mãos e outros produtos de limpeza, entre eles: géis 
de banho, shampoos e condicionadores de cabelo, além de detergentes 
concentrados.

Nossos parceiros de negócios estão aumentando sua participação no mercado 
externo devido à crescente satisfação do cliente e oferta diversificada.

O potencial de crescimento de nossas soluções resulta de preços acessíveis, 
alto desempenho e versatilidade para se adaptar a todos os tipos de pele.

A extensão da gama de produtos proposta é um campo interessante para a 
cooperação?


Cumprimentos,
Raquel Carvalho
Conselheiro do Cliente

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-29 Thread Roman Kuzmitskii via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
i can confirm that performance hit with CONFIG_CAVIUM_CN63XXP1 is huge on other 
octeon devices and that option should not be used.

> On Oct 29, 2020, at 4:07 PM, Johannes Kimmel  wrote:
> 
> This patch disables the image for edgerouter devices by default, since
> it isn't able to boot at the moment.
> 
> Currently the edgerouter image won't boot. Current kernels have an
> option CONFIG_CAVIUM_CN63XXP1 that needs to be enabled for this chip.
> 
> If the kernel was compiled without this option, following message is
> displayed and the machine reboots:
> 
> [   36.778028] Kernel panic - not syncing: OCTEON II DCache prefetch 
> workaround not in place (cfac).
> [   36.778028] Please build kernel with proper options 
> (CONFIG_CAVIUM_CN63XXP1).
> [   36.794398] Rebooting in 1 seconds..
> 
> This was last confirmed on 2020-10-29.
> 
> The description of this option states, that enabling it will possibly
> cause performance issues on other chips.
> 
> Signed-off-by: Johannes Kimmel 
> 
> ---
> 
> Full bootlog:
> 
> U-Boot 2012.04.01 (UBNT Build Version: e200_002_80eda) (May 27 2019 - 
> 06:34:56)
> 
> Skipping PCIe port 0 BIST, in EP mode, can't tell if clocked.
> Skipping PCIe port 1 BIST, reset not done. (port not configured)
> BIST check passed.
> UBNT_E200 r1:0, r2:19, serial #: FCECDA05EB31
> MPR 13-00317-19
> Core clock: 1000 MHz, IO clock: 600 MHz, DDR clock: 533 MHz (1066 Mhz DDR)
> Base DRAM address used by u-boot: 0x8f80, size: 0x80
> DRAM: 2 GiB
> Clearing DRAM.. done
> Flash: 8 MiB
> Net:   octeth0, octeth1, octeth2, octeth3, octeth4, octeth5, octeth6, octeth7
> MMC:   Octeon MMC/SD0: 0
> USB:   USB EHCI 1.00
> scanning bus for devices... 2 USB Device(s) found
> Type the command 'usb start' to scan for USB storage devices.
> 
> Hit any key to stop autoboot:  0
> Octeon ubnt_e200# usb start
> (Re)start USB...
> USB:   USB EHCI 1.00
> scanning bus for devices... 2 USB Device(s) found
>   scanning bus for storage devices... 1 Storage Device(s) found
> Octeon ubnt_e200# fatload usb 0 $(loadaddr) 
> openwrt-octeon-ubnt_edgerouter-initramfs-kernel.bin.1 ; bootoctlinux 
> $(loadaddr) numcores=2 endbootargs mem=0
> reading openwrt-octeon-ubnt_edgerouter-initramfs-kernel.bin.1
> 
> 16286136 bytes read
> reading openwrt-octeon-ubnt_edgerouter-initramfs-kernel.bin.1.md5
> 
> ** Unable to read openwrt-octeon-ubnt_edgerouter-initramfs-kernel.bin.1.md5
> argv[2]: numcores=2
> argv[3]: endbootargs
> Allocating memory for ELF segment: addr: 0x8110 (adjusted to: 
> 0x110), size 0x20dcd18
> Bootloader: Done loading app on coremask: 0x3
> Starting cores 0x3
> [0.00] Linux version 5.4.72 (builder@buildhost) (gcc version 8.4.0 
> (OpenWrt GCC 8.4.0 r14793-9f1927173a)) #0 SMP Wed Oct 28 02:25:25 2020
> [0.00] Skipping L2 locking due to reduced L2 cache size
> [0.00] CVMSEG size: 2 cache lines (256 bytes)
> [0.00] printk: bootconsole [early0] enabled
> [0.00] CPU0 revision is: 000d9301 (Cavium Octeon II)
> [0.00] Checking for the multiply/shift bug... no.
> [0.00] Checking for the daddiu bug... no.
> [0.00] Kernel sections are not in the memory maps
> [0.00] Wasting 278528 bytes for tracking 4352 unused pages
> [0.00] Initrd not found or empty - disabling initrd
> [0.00] Using passed Device Tree.
> [0.00] software IO TLB: mapped [mem 0x0320b000-0x0324b000] (0MB)
> [0.00] Primary instruction cache 37kB, virtually tagged, 37 way, 8 
> sets, linesize 128 bytes.
> [0.00] Primary data cache 32kB, 32-way, 8 sets, linesize 128 bytes.
> [0.00] Zone ranges:
> [0.00]   DMA32[mem 0x0110-0xefff]
> [0.00]   Normal   empty
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x0110-0x031dcfff]
> [0.00]   node   0: [mem 0x0320-0x0edf]
> [0.00]   node   0: [mem 0x0f20-0x0fdf]
> [0.00]   node   0: [mem 0x2000-0x8f7f]
> [0.00] Zeroed struct page in unavailable ranges: 7971 pages
> [0.00] Initmem setup node 0 [mem 
> 0x0110-0x8f7f]
> [0.00] percpu: Embedded 18 pages/cpu s35872 r8192 d29664 u73728
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 508249
> [0.00] Kernel command line: 
> mtdparts=phys_mapped_flash:640k(boot0)ro,640k(boot1)ro,64k(eeprom)ro 
> root=/dev/mmcblk0p2 rootfstype=squashfs,ext4 rootwait console=ttyS0,115200
> [0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 
> bytes, linear)

[no subject]

2020-10-25 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 3966875fde9a130d20cb48cbc81f8478404be169
  
https://github.com/sdwalker/sdwalker.github.io/commit/3966875fde9a130d20cb48cbc81f8478404be169
  Author: Stephen Walker 
  Date:   2020-10-25 (Sun, 25 Oct 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html
M uscan/js/sort.js

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-23 Thread Ivan Grynko via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi,
Seen this commit in your branch https://git.openwrt.org/?p=openwrt/staging/
nbd.git;a=commit;h=b18993dcaf5ae57d4569a9606dd707e5380e9382 and have couple of 
questions:
- Will this work on ramips mt7621?
- Could this potentially solve a problem in current master with kernel 5.4 
when flashing openwrt builds randomly soft bricks endgerouterx due to bad 
blocks(not sure but this particular device has 1 bad block in kernel2 and one 
in the ubi partion) ?

I have the same symptoms as described here https://github.com/freifunk-gluon/
gluon/issues/1937 

Part of dmesg
[1.046059] Bad eraseblock 36 at 0x0048
[2.389258] Bad eraseblock 1089 at 0x0882
[3.613784] 6 fixed-partitions partitions found on MTD device mt7621-nand
[3.627314] Creating 6 MTD partitions on "mt7621-nand":
[3.637740] 0x-0x0008 : "u-boot"
[3.648784] 0x0008-0x000e : "u-boot-env"
[3.660548] 0x000e-0x0014 : "factory"
[3.671742] 0x0014-0x0044 : "kernel1"
[3.683089] 0x0044-0x0074 : "kernel2"
[3.694255] 0x0074-0x0ff0 : "ubi"

Regards,
Ivan



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-22 Thread Roman Kuzmitskii via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
yeah, i found that it is broken too.
i tested on few octeon boards and all of them fall in ‘high memory device’ 
category.

reverting commit brings back the working tree back.

i would suggest to revert for now and do better testing next time.

related log after flashing image with that commit:

[   18.661817] procd: Create service ubus
[   18.665645] procd: Start instance ubus::instance1
[   18.670675] procd: Started instance ubus::instance1[614]
[   18.676106] procd: running /etc/init.d/ubus running
[   18.681303] procd: glob failed on /etc/init.d/ubus
[   18.686204] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   18.711471] procd: Connection to ubus failed
[   18.815073] procd: Connection to ubus failed
[   19.018736] procd: Connection to ubus failed
[   19.422610] procd: Connection to ubus failed
[   19.695516] procd: Started instance ubus::instance1[615]
[   19.703165] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   20.226890] procd: Connection to ubus failed
[   20.711994] procd: Started instance ubus::instance1[616]
[   20.719593] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   21.231312] procd: Connection to ubus failed
[   21.728430] procd: Started instance ubus::instance1[617]
[   21.736023] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   22.235724] procd: Connection to ubus failed
[   22.744871] procd: Started instance ubus::instance1[618]
[   22.752489] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   23.240180] procd: Connection to ubus failed
[   23.654955] procd: Ping
[   23.760869] procd: Started instance ubus::instance1[619]
[   23.768453] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   24.245134] procd: Connection to ubus failed
[   24.777303] procd: Started instance ubus::instance1[620]
[   24.784902] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   25.249421] procd: Connection to ubus failed
[   25.794608] procd: Started instance ubus::instance1[621]
[   25.802266] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   26.253912] procd: Connection to ubus failed
[   26.811123] procd: Started instance ubus::instance1[622]
[   26.818762] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   27.258402] procd: Connection to ubus failed
[   27.828596] procd: Started instance ubus::instance1[623]
[   27.836209] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds
[   28.262838] procd: Connection to ubus failed
[   28.658590] procd: Ping
[   28.844571] procd: Started instance ubus::instance1[624]
[   28.852204] procd: Instance ubus::instance1 exit with error code 65280 after 
0 seconds

also when you start a fresh built from initramfs - it boots bot gives lots of 
segfaults:

[   37.210492] do_page_fault(): sending SIGSEGV to ujail for invalid read 
access from 0100f380dc81
[   37.219578] epc = 00ea42dc in ujail[e9e000+11000]
[   37.225349] ra  = 00ea4840 in ujail[e9e000+11000]
[   42.235990] do_page_fault(): sending SIGSEGV to ujail for invalid read 
access from 0100f38a1c81
[   42.245090] epc = 00fd02dc in ujail[fca000+11000]
[   42.250865] ra  = 00fd0840 in ujail[fca000+11000]
[   47.263899] do_page_fault(): sending SIGSEGV to ujail for invalid read 
access from 0100f3736c81
[   47.272998] epc = 00d5c2dc in ujail[d56000+11000]
[   47.278774] ra  = 00d5c840 in ujail[d56000+11000]
[   52.291922] do_page_fault(): sending SIGSEGV to ujail for invalid read 
access from 0100f2f77c81
[   52.301033] epc = 00aaab0682dc in ujail[aaab062000+11000]
[   52.306805] ra  = 00aaab068840 in ujail[aaab062000+11000]
[   54.313652] br-lan: port 1(eth0) entered blocking state
[   54.318946] br-lan: port 1(eth0) entered disabled state
[   54.324469] device eth0 entered promiscuous mode
[   55.346609] eth0: 1000 Mbps Full duplex, port 0, queue 0
[   56.360423] br-lan: port 1(eth0) entered blocking state
[   56.365667] br-lan: port 1(eth0) entered forwarding state
[   56.371366] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[   57.318164] do_page_fault(): sending SIGSEGV to ujail for invalid read 
access from 0100f3708c81
[   57.327255] epc = 00e922dc in ujail[e8c000+11000]
[   57.333021] ra  = 00e92840 in ujail[e8c000+11000]
[   58.865884] do_page_fault(): sending SIGSEGV to ujail for invalid read 
access from 0100f3d9bc81
[   58.874966] epc = 00aaab8432dc in ujail[aaab83d000+11000]
[   58.880736] ra  = 00aaab843840

[no subject]

2020-10-20 Thread Gary Cooper via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
From: Gary Cooper 

1: Daniel: As requested.
2: Robert: Your if/then-logic seems to also do the trick, this patch
simply references the existing logic for 802.11a/ac.

802.11ad support

Signed-off-by: Gary Cooper 
---
 package/base-files/files/sbin/wifi | 1 +
 package/kernel/mac80211/files/lib/wifi/mac80211.sh | 6 ++
 package/network/services/hostapd/files/hostapd.sh  | 8 
 3 files changed, 15 insertions(+)

diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi
index a8b4451c60..75759b94f3 100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -79,6 +79,7 @@ wifi_fixup_hwmode() {
 case "$hwmode" in
 11bg) hwmode=bg;;
 11a) hwmode=a;;
+11ad) hwmode=ad;;
 11b) hwmode=b;;
 11g) hwmode=g;;
 11n*)
diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
index c0fbfbe5a8..3e99f06693 100644
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -88,6 +88,12 @@ detect_mac80211() {
 iw phy "$dev" info | grep -q 'VHT Capabilities'
&& htmode="VHT80"
 }

+iw phy "$dev" info | grep -q '\* 5 MHz \[' && {
+mode_band="ad"
+channel=$(iw phy "$dev" info | grep '\* 5 MHz
\[' | grep
'(disabled)' -v -m 1 | sed 's/[^[]*\[\|\|\].*//g')
+iw phy "$dev" info | grep -q 'Capabilities:' &&
htmode="HT20"
+}
+
 [ -n "$htmode" ] && ht_capab="set
wireless.radio${devidx}.htmode=$htmode"

 path="$(mac80211_phy_to_path "$dev")"
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 3290358ed2..b5563d88a6 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -1163,6 +1163,14 @@ wpa_supplicant_add_network() {
 ;;
 esac

+case "$wpa_cipher" in
+GCMP)
+append network_data "pairwise=GCMP" "$N$T"
+append network_data "group=GCMP" "$N$T"
+;;
+*) ;;
+esac
+
 [ "$mode" = mesh ] || {
 case "$wpa" in
 1)
--


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-20 Thread Gary Cooper via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
From: Gary Cooper 

Device hardware: https://deviwiki.com/wiki/TP-LINK_AD7200_(Talon)

The Talon AD7200 is basically an Archer C2600 with a third PCIe lane and
an 802.11ad radio. It comes in a different housing similar to the
Archers C3200 and C5400.

Specifications
--

  - IPQ8064 dual-core 1400MHz
  - QCA9988 2.4GHz WiFi
  - QCA9888 5GHz WiFi
  - QCA9500 60GHz WiFi
  - 32MB SPI Flash
  - 512MiB RAM
  - 5 GBit Ports (QCA8337)

Installation


Installation is possible from the OEM web interface.
Sysupgrade is possible.
TFTP recovery is possible.
  - Image: AD7200_1.0_tp_recovery.bin

Notes
  - This will (fingers crossed) be the first 802.11ad-device to be
supported by mainline.

Please consider this to be the v2 of this proposal. There seems to
have been some issues with the previous MX-provider, please take note of
the new email-address.

1: The information listed on DeviWiki seems to be erroneous, the Talon
AD7200 does indeed have 32MB of flash, thanks Daniel.

2: I've made a few changes to the patch so as to further alleviate any
concerns with re to maintenance.

3: I've split the patch into device-specific and 802.11ad-specific content.

Signed-off-by: Gary Cooper 
---
 package/firmware/linux-firmware/qca.mk|   8 +
 package/kernel/mac80211/ath.mk|  13 +-
 .../ipq806x/base-files/etc/board.d/01_leds|   9 +
 .../ipq806x/base-files/etc/board.d/02_network |   1 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   2 +
 .../base-files/lib/upgrade/platform.sh|   1 +
 .../arch/arm/boot/dts/qcom-ipq8064-ad7200.dts | 440 ++
 target/linux/ipq806x/image/Makefile   |  15 +
 tools/firmware-utils/src/tplink-safeloader.c  |  44 ++
 9 files changed, 532 insertions(+), 1 deletion(-)
 create mode 100644
target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-ad7200.dts

diff --git a/package/firmware/linux-firmware/qca.mk
b/package/firmware/linux-firmware/qca.mk
index 23fcc0905a..71b484d5c7 100644
--- a/package/firmware/linux-firmware/qca.mk
+++ b/package/firmware/linux-firmware/qca.mk
@@ -37,3 +37,11 @@ define Package/carl9170-firmware/install
 $(INSTALL_DATA) $(PKG_BUILD_DIR)/carl9170-1.fw $(1)/lib/firmware
 endef
 $(eval $(call BuildPackage,carl9170-firmware))
+
+Package/wil6210-firmware = $(call Package/firmware-default,wil6210 firmware)
+define Package/wil6210-firmware/install
+$(INSTALL_DIR) $(1)/lib/firmware
+$(INSTALL_DATA) $(PKG_BUILD_DIR)/wil6210.fw $(1)/lib/firmware
+$(INSTALL_DATA) $(PKG_BUILD_DIR)/wil6210.brd $(1)/lib/firmware
+endef
+$(eval $(call BuildPackage,wil6210-firmware))
diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk
index 5db4be8daa..e563fb71fc 100644
--- a/package/kernel/mac80211/ath.mk
+++ b/package/kernel/mac80211/ath.mk
@@ -1,6 +1,6 @@
 PKG_DRIVERS += \
 ath ath5k ath6kl ath6kl-sdio ath6kl-usb ath9k ath9k-common ath9k-htc
ath10k \
-carl9170 owl-loader ar5523
+carl9170 wil6210 owl-loader ar5523

 PKG_CONFIG_DEPENDS += \
 CONFIG_PACKAGE_ATH_DEBUG \
@@ -20,6 +20,7 @@ ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
 ATH9K_HTC_DEBUGFS \
 ATH10K_DEBUGFS \
 CARL9170_DEBUGFS \
+WIL6210_DEBUGFS \
 ATH5K_DEBUG \
 ATH6KL_DEBUG
 endif
@@ -29,6 +30,7 @@ ifdef CONFIG_PACKAGE_MAC80211_TRACING
 ATH10K_TRACING \
 ATH6KL_TRACING \
 ATH_TRACEPOINTS \
+WIL6210_TRACING
 ATH5K_TRACER
 endif

@@ -66,6 +68,7 @@ config-$(call config_package,ath6kl-sdio) += ATH6KL_SDIO
 config-$(call config_package,ath6kl-usb) += ATH6KL_USB

 config-$(call config_package,carl9170) += CARL9170
+config-$(call config_package,wil6210) += WIL6210
 config-$(call config_package,ar5523) += AR5523

 define KernelPackage/ath/config
@@ -284,6 +287,14 @@ define KernelPackage/carl9170
   AUTOLOAD:=$(call AutoProbe,carl9170)
 endef

+define KernelPackage/wil6210
+  $(call KernelPackage/mac80211/Default)
+  TITLE:=QCA/Wilocity 60g WiFi card wil6210 support
+  DEPENDS+= @PCI_SUPPORT +kmod-mac80211 +wil6210-firmware
+  FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/wil6210/wil6210.ko
+  AUTOLOAD:=$(call AutoProbe,wil6210)
+endef
+
 define KernelPackage/owl-loader
   $(call KernelPackage/mac80211/Default)
   TITLE:=Owl loader for initializing Atheros PCI(e) Wifi chips
diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
b/target/linux/ipq806x/base-files/etc/board.d/01_leds
index c23f25540b..d50fb1d719 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
+++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
@@ -36,6 +36,15 @@ netgear,r7800)
 ucidef_set_led_switch "wan" "WAN" "white:wan" "switch0" "0x20"

[no subject]

2020-10-18 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: a54bbf1af70110872ae210793c2f0aa3c0530205
  
https://github.com/sdwalker/sdwalker.github.io/commit/a54bbf1af70110872ae210793c2f0aa3c0530205
  Author: Stephen Walker 
  Date:   2020-10-18 (Sun, 18 Oct 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-18 Thread Roman Kuzmitskii via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
hello,

  i have edgerouter 4 and there is lots of other devices that would benefit 
from using separate octeon3 target.
  i would like to hear some opinions on what are we  do with it.

  current options are:
- ‘octeon3’ subtarget in ‘octeon’ target
- separate ‘octeon3' target.

  known devices are:
- D-Link DSR-1000AC rev A1 (cn7020)
- Itus Shield (cn7020)
- Riverbed XH2-240 (cn7130)
- Ubiquiti EdgeRouter 4 (cn7130)
- Ubiquiti EdgeRouter 6p (cn7130)
- Ubiquiti EdgeRouter 12 (cn7130)
- Ubiquiti EdgeRouter 12p (cn7130)
- Ubiquiti EdgeRouter 8 Infinity (cn7360)

  benefits of new target are:
- FPU usage so target will be a hardfloat. current octeon target is 
softfloat
- optimizations on compiler side using -march=octeon3 instead of 
-march=octeonplus could bring up to 5% performance boost
- targets do not need hacks like notes strip for old octeon SDK

  all of them would benefit from using a device tree and i already made one for 
cn71xx and cn70xx (essentially less feature rich cn71xx).
  tests was done on edgerouter 4 (me) and edgerouter 12 (lemmi on freenode).

  why am i doing it?
- i have personal interest in contributing to openwrt and can help with 
maintaining new target since there is no owner.
- already own hardware that benefit from new target and already met people 
on freenode that is in the same boat

  thank you

— damex
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-17 Thread Gary Cooper via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
>From de97e34f0a5f0b13e5c80ac43af5c78da52b9572 Mon Sep 17 00:00:00 2001
From: Gary Cooper 
Date: Fri, 15 Oct 2020 12:40:50 +
Subject: ipq806x: add support for TP-Link Talon AD7200

Please consider this to be the v2 of this patch-proposal. There seems to
have been some issues with the previois MX-provider, please take note of
the new email-address.

1: The information listed on DeviWiki seems to be errouneos, the Talon
AD7200 does indeed have 32MB of flash, thanks Daniel.

2: I've made a few changes to the patch so as to further illeviate any
concerns with re to maintenance.

3: I've split the patch into device-specific and 802.11ad-specific content.

Device hardware: https://deviwiki.com/wiki/TP-LINK_AD7200_(Talon)

The Talon AD7200 is basically an Archer C2600 with a third PCIe lane and
an 802.11ad radio. It comes in a different housing reminiscent of the
Archers C3200 and C5400.


Specifications
--

  - IPQ8064 dual-core 1400MHz
  - QCA9988 2.4GHz WiFi
  - QCA9888 5GHz WiFi
  - QCA9500 60GHz WiFi
  - 32MB SPI Flash
  - 512MiB RAM
  - 5 GBit Ports (QCA8337)

Installation


Installation is possible from the OEM web interface.
Sysupgrade is possible.
TFTP recovery is possible.
  - Image: AD7200_1.0_tp_recovery.bin

Notes
  - This will be the first 802.11ad device supported by mainline.

Signed-off-by: Gary Cooper 
---
 package/firmware/linux-firmware/qca.mk|   8 +
 package/kernel/mac80211/ath.mk|  13 +-
 .../ipq806x/base-files/etc/board.d/01_leds|   9 +
 .../ipq806x/base-files/etc/board.d/02_network |   1 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   2 +
 .../base-files/lib/upgrade/platform.sh|   1 +
 .../arch/arm/boot/dts/qcom-ipq8064-ad7200.dts | 440 ++
 target/linux/ipq806x/image/Makefile   |  15 +
 tools/firmware-utils/src/tplink-safeloader.c  |  44 ++
 9 files changed, 532 insertions(+), 1 deletion(-)
 create mode 100644
target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-ad7200.dts

diff --git a/package/firmware/linux-firmware/qca.mk
b/package/firmware/linux-firmware/qca.mk
index 23fcc0905a..71b484d5c7 100644
--- a/package/firmware/linux-firmware/qca.mk
+++ b/package/firmware/linux-firmware/qca.mk
@@ -37,3 +37,11 @@ define Package/carl9170-firmware/install
$(INSTALL_DATA) $(PKG_BUILD_DIR)/carl9170-1.fw $(1)/lib/firmware
 endef
 $(eval $(call BuildPackage,carl9170-firmware))
+
+Package/wil6210-firmware = $(call Package/firmware-default,wil6210 firmware)
+define Package/wil6210-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/wil6210.fw $(1)/lib/firmware
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/wil6210.brd $(1)/lib/firmware
+endef
+$(eval $(call BuildPackage,wil6210-firmware))
diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk
index 5db4be8daa..e563fb71fc 100644
--- a/package/kernel/mac80211/ath.mk
+++ b/package/kernel/mac80211/ath.mk
@@ -1,6 +1,6 @@
 PKG_DRIVERS += \
ath ath5k ath6kl ath6kl-sdio ath6kl-usb ath9k ath9k-common ath9k-htc
ath10k \
-   carl9170 owl-loader ar5523
+   carl9170 wil6210 owl-loader ar5523

 PKG_CONFIG_DEPENDS += \
CONFIG_PACKAGE_ATH_DEBUG \
@@ -20,6 +20,7 @@ ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
ATH9K_HTC_DEBUGFS \
ATH10K_DEBUGFS \
CARL9170_DEBUGFS \
+   WIL6210_DEBUGFS \
ATH5K_DEBUG \
ATH6KL_DEBUG
 endif
@@ -29,6 +30,7 @@ ifdef CONFIG_PACKAGE_MAC80211_TRACING
ATH10K_TRACING \
ATH6KL_TRACING \
ATH_TRACEPOINTS \
+   WIL6210_TRACING
ATH5K_TRACER
 endif

@@ -66,6 +68,7 @@ config-$(call config_package,ath6kl-sdio) += ATH6KL_SDIO
 config-$(call config_package,ath6kl-usb) += ATH6KL_USB

 config-$(call config_package,carl9170) += CARL9170
+config-$(call config_package,wil6210) += WIL6210
 config-$(call config_package,ar5523) += AR5523

 define KernelPackage/ath/config
@@ -284,6 +287,14 @@ define KernelPackage/carl9170
   AUTOLOAD:=$(call AutoProbe,carl9170)
 endef

+define KernelPackage/wil6210
+  $(call KernelPackage/mac80211/Default)
+  TITLE:=QCA/Wilocity 60g WiFi card wil6210 support
+  DEPENDS+= @PCI_SUPPORT +kmod-mac80211 +wil6210-firmware
+  FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/wil6210/wil6210.ko
+  AUTOLOAD:=$(call AutoProbe,wil6210)
+endef
+
 define KernelPackage/owl-loader
   $(call KernelPackage/mac80211/Default)
   TITLE:=Owl loader for initializing Atheros PCI(e) Wifi chips
diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
b/target/linux/ipq806x/base-files/etc/board.d/01_leds
index c23f25540b..d50fb1d719 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
+++ b/target/

[no subject]

2020-10-17 Thread Gary Cooper via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
>From 72829ea7effdf39b9d27dac21dffcf1b6e34a484 Mon Sep 17 00:00:00 2001
From: Gary Cooper 
Date: Fri, 15 Oct 2020 12:40:50 +
Subject: 802.11ad support

1: Daniel: As requested.
2: Robert: Your if/then-logic seems to also do the trick, this patch
achieves the same by referencing the existing logic for 802.11a/ac.

Signed-off-by: Gary Cooper 
---
 package/base-files/files/sbin/wifi | 1 +
 package/kernel/mac80211/files/lib/wifi/mac80211.sh | 6 ++
 package/network/services/hostapd/files/hostapd.sh  | 8 
 3 files changed, 15 insertions(+)

diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi
index a8b4451c60..75759b94f3 100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -79,6 +79,7 @@ wifi_fixup_hwmode() {
case "$hwmode" in
11bg) hwmode=bg;;
11a) hwmode=a;;
+   11ad) hwmode=ad;;
11b) hwmode=b;;
11g) hwmode=g;;
11n*)
diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
index c0fbfbe5a8..3e99f06693 100644
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -88,6 +88,12 @@ detect_mac80211() {
iw phy "$dev" info | grep -q 'VHT Capabilities' && 
htmode="VHT80"
}

+   iw phy "$dev" info | grep -q '\* 5 MHz \[' && {
+   mode_band="ad"
+   channel=$(iw phy "$dev" info | grep '\* 5 MHz \[' | 
grep
'(disabled)' -v -m 1 | sed 's/[^[]*\[\|\|\].*//g')
+   iw phy "$dev" info | grep -q 'Capabilities:' && 
htmode="HT20"
+   }
+
[ -n "$htmode" ] && ht_capab="set 
wireless.radio${devidx}.htmode=$htmode"

path="$(mac80211_phy_to_path "$dev")"
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 3290358ed2..b5563d88a6 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -1163,6 +1163,14 @@ wpa_supplicant_add_network() {
;;
esac

+   case "$wpa_cipher" in
+   GCMP)
+   append network_data "pairwise=GCMP" "$N$T"
+   append network_data "group=GCMP" "$N$T"
+   ;;
+   *) ;;
+   esac
+
[ "$mode" = mesh ] || {
case "$wpa" in
1)
-- 
2.17.1


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-11 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 05f09e51076d0254cd8733d864906156705b922b
  
https://github.com/sdwalker/sdwalker.github.io/commit/05f09e51076d0254cd8733d864906156705b922b
  Author: Stephen Walker 
  Date:   2020-10-11 (Sun, 11 Oct 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-07 Thread Florian Eckert via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> >>>  # For exponential module:
> >>> -#CONFIG_AUTOSCAN_EXPONENTIAL=y
> >>> +CONFIG_AUTOSCAN_EXPONENTIAL=y
> >>>  # For periodic module:
> >>> -#CONFIG_AUTOSCAN_PERIODIC=y

> >>>  # operations for roaming within an ESS (same SSID). See the bgscan 
> >>> parameter in
> >>>  # the wpa_supplicant.conf file for more details.
> >>>  # Periodic background scans based on signal strength
> >>> -#CONFIG_BGSCAN_SIMPLE=y
> >>> +CONFIG_BGSCAN_SIMPLE=y
> >>>  # Learn channels used by the network and try to avoid bgscans on other
> >>>  # channels (experimental)
> >>>  #CONFIG_BGSCAN_LEARN=y

This change enables the config options CONFIG_BGSCAN_* and CONFIG_AUTOSCAN_*
But we only configure CONFIG_BGSCAN_* via hostapd.sh with the uci
option *roam_rssi_threshold* in this change.
But should we not als make CONFIG_AUTOSCAN configurable via hostapd.sh?

#autoscan=:

Kind regards

Florian

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-10-04 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 8dc9322d0bd0138b15cb310cd979f9eaa14d89b2
  
https://github.com/sdwalker/sdwalker.github.io/commit/8dc9322d0bd0138b15cb310cd979f9eaa14d89b2
  Author: Stephen Walker 
  Date:   2020-10-04 (Sun, 04 Oct 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-09-30 Thread Martin Blumenstingl via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Adrian,

On Wed, Sep 30, 2020 at 9:11 PM Adrian Schmutzler
 wrote:
>
> Hi Martin,
>
> > -Original Message-
> > From: Martin Blumenstingl [mailto:martin.blumensti...@googlemail.com]
> > Sent: Mittwoch, 30. September 2020 20:55
> > To: Adrian Schmutzler 
> > Cc: openwrt-devel@lists.openwrt.org
> > Subject: Re: [RFC PATCH] ath79: remove model name from LED labels
> >
> > Hi Adrian,
> >
> > On Sat, Sep 26, 2020 at 6:33 PM Adrian Schmutzler
> >  wrote:
> > [...]
> > > Apart from our needs, upstream has deprecated the label property
> > > entirely and introduced new properties to specify color and function
> > > properties separately. However, the implementation does not appear to
> > > be ready and probably won't become ready and/or match our
> > requirements
> > > in the foreseeable future.
> > I recently did an experiment with the color and function properties and it's
> > working well for me with my F9K1115V2 to make it work I had to come up
> > with a (simple) patch that parses the "color" property: [0]
> >
> > there's no feedback in this mail - my goal is to understand what the 
> > concerns
> > are so I don't "just" start porting some of my boards to the new way that's
> > recommended upstream only to see this patch then being rejected in
> > OpenWrt.
>
> My initial idea was to go the same way; have a look at these two comment 
> where I summarized the response from upstream and why I consider that not 
> helpful:
>
> https://github.com/openwrt/openwrt/pull/3437#issuecomment-696377807
> https://github.com/openwrt/openwrt/pull/3437#issuecomment-699492366
Thanks for the background info!

> Apart from that, I'm aware that we obviously have the option to _partially_ 
> implement the upstream solution, i.e. use the color ids and just put the last 
> part of the former label into function. However, as discussed in the 
> referenced comments, this would essentially be an abuse of "function" as far 
> as upstream sees it: We should create the corresponding LED_FUNCTION entries 
> instead of putting strings into "function" directly, and my proposals for 
> adding some of them were rejected.
> Of course, we could just ignore that, and put into function what we like. 
> That would work perfectly, it's just a little more complicated to implement 
> in user-space as your patch shows. Nevertheless, I just hesitate to implement 
> a system against its intention (color/function) when we have an alternate 
> solution that we can use as intended (label).
I see

> Apart from that, as stated in the referenced comments, your solution will 
> break anyway when kernel starts to use the devicename strings again for 
> internal "devices" like phy0/wlan0/etc. as proposed in the discussion at 
> linux-leds (e.g. wlan0:green:activity instead of green:wlan2g).
it will break again for anything that requires setting the default
trigger from userspace
my hope is that most LEDs will not need userspace handling for their
default behavior anymore, for example all LAN or wifi activity LEDs.
I'm not sure about corner-cases though (for example: 2GHz wifi
specific WPS LED- if that's used anywhere)

> As I said in the PR, unfortunately all of this is essentially very 
> unsatisfying at the moment. So, what I plan to do with the labels is as much 
> improvement as I can get for now.
my personal opinion: I would skip this intermediate step and work with
upstream to implement the LED-triggers where needed. Then backport
these patches and switch to that ABI. Rafał did this with
ledtrig-usbport
that is because I'm not sure how hard the migration for this
intermediate step is. if much effort is required then I'd rather spend
time on something that will be usable in the future rather than
spending time on some temporary solution


Best regards,
Martin

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-09-30 Thread Martin Blumenstingl via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Adrian,

On Sat, Sep 26, 2020 at 6:33 PM Adrian Schmutzler
 wrote:
[...]
> Apart from our needs, upstream has deprecated the label property
> entirely and introduced new properties to specify color and
> function properties separately. However, the implementation does
> not appear to be ready and probably won't become ready and/or
> match our requirements in the foreseeable future.
I recently did an experiment with the color and function properties
and it's working well for me with my F9K1115V2
to make it work I had to come up with a (simple) patch that parses the
"color" property: [0]

there's no feedback in this mail - my goal is to understand what the
concerns are so I don't "just" start porting some of my boards to the
new way that's recommended upstream only to see this patch then being
rejected in OpenWrt.


Thank you!
Martin


[0] 
https://github.com/xdarklight/openwrt/commit/eddaa9004f1897688a15befbd37234f9de1a7ae1.patch

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-09-27 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: aee9e7bea5ea722b638dfce41e9413f5de356ac0
  
https://github.com/sdwalker/sdwalker.github.io/commit/aee9e7bea5ea722b638dfce41e9413f5de356ac0
  Author: Stephen Walker 
  Date:   2020-09-27 (Sun, 27 Sep 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-09-26 Thread Florian Eckert via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> Ok, but having a set of quite some providers doesn't have to be bad
> thing. Was this done to just get the number down or because of space
> savings?

Because of  space saving.

> Because if it's the latter, it doesn't look like it would save that much:
> data.tar.gz, extracted from ddns-scripts_service_2.8.0-24_all.ipk, so
> all 81 providers, is just 4453 bytes. Having all providers on the jffs2
> compressed filesystem probably occupies the similar space?

I have not tried that.
I only saw in my file system that the memory consumption was much
higher due to the change from one file to individual json files.

Regards

Florian

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-09-26 Thread Florian Eckert via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Andre,

thanks for your remarks, but I have to say this is a master branch and
this is *not* a stable branch!
The current implementation is not maintainable so I thought we have to
refactor this package.
If something is changed then something can also be broken.
This is not intended but can happen.

> but the non existing backwards compatibility sucks though. This move
> breaks every installation relying on a provider which now moved to the
> new package.

There will always be new packages and you have to adapt.
The other possibility was to leave the new files in the ddns-scripts package.
This would have increased the size of the package!
Then others would have been upset about the size of the package.
How to do it there is always someone who doesn't like it!

> And the `ddns` command is basically just a stripped down opkg in sh.

Not everyone needs all service providers.
Therefore the possibility to download the providers and not to install
the package.
It is also possible that the service urls change during the life cycle
of the software.
This can be updated by downloading the service files.

> I think this needs to be more user friendly and less setup breaking.

As I said, thanks for the feedback I and Ansual are working on it.

Regards,

Florian

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-09-22 Thread Sami Olmari via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This commit 
https://github.com/openwrt/openwrt/commit/064dc1e81bc85f6ef8becc38854292853a59d2c2
breaks all dnssec, it will never get enabled despite /etc/config/dhcp
enabling it. Reverting this commit made dnssec to work again. So this
needs either reverting, or some more elaborate fix.

Additionally I got this message when troubleshooting this at irc:
"While at it, ask please to fix trust-anchor match too (it's not an
option, the option just contains that word at the end)"

Thank you!

-- 
 Sami Olmari
 Oy Olmari Ab
 Vaasa Hacklab ry

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-09-20 Thread Stephen Walker via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 5286f40f6ba8db650b12e2d8dfa89610a57e6ccd
  
https://github.com/sdwalker/sdwalker.github.io/commit/5286f40f6ba8db650b12e2d8dfa89610a57e6ccd
  Author: Stephen Walker 
  Date:   2020-09-20 (Sun, 20 Sep 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[no subject]

2020-09-15 Thread Daniel Santos via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Jeffery,

Thank you for the wonderful work on maintaining the Go packages!

I got a little irritated at CGo's restriction of arch flags (in the
immutable GOGCCFLAGS variable) and put together a patch set for v19.07
to override them with an environment variable and then (optionally) feed
the machine flags in the Golang build.  In the OpenWRT repo, I did this
by splitting out how DEFAULT_CFLAGS are put together in order to
populate a DEFAULT_MACHINE_FLAGS, but it could probably be done with
just a $(filter -m%,$(DEFAULT_CFLAGS)) instead.

If you or others have any interest in this, I can clean them up for the
master branch.  I'm probably going to submit the Golang patch upstream,
since I don't see any good reason for such a restriction.  I see you've
made a lot of changes on the HEAD.

Daniel
>From f1c770216e4eadaa641fb4f9894576358df5cf74 Mon Sep 17 00:00:00 2001
From: Daniel Santos 
Date: Sun, 13 Sep 2020 20:49:06 -0500
Subject: Goloang: Add customizable ARCH flags via CGO_MACHINE_FLAGS

Adds the option to override Golang's choice of architecture-specific
machine flags with arbitrary values via the environment variable
CGO_MACHINE_FLAGS.  Then we supply those via the MACHINE_FLAGS make
variable fed from CONFIG_MACHINE_FLAGS from .config.

Signed-off-by: Daniel Santos 
---
 lang/golang/golang-package.mk |  1 +
 lang/golang/golang-values.mk  |  2 +-
 ...GS-to-override-hard-coded-arch-flags.patch | 28 +++
 3 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch

diff --git a/lang/golang/golang-package.mk b/lang/golang/golang-package.mk
index 73c6572a9..e3bbab6bc 100644
--- a/lang/golang/golang-package.mk
+++ b/lang/golang/golang-package.mk
@@ -154,6 +154,7 @@ define GoPackage/Environment/Default
 	GOMIPS=$(GO_MIPS) \
 	GOMIPS64=$(GO_MIPS64) \
 	CGO_ENABLED=1 \
+	CGO_MACHINE_FLAGS="$(MACHINE_FLAGS)" \
 	CGO_CFLAGS="$(filter-out $(GO_CFLAGS_TO_REMOVE),$(TARGET_CFLAGS))" \
 	CGO_CPPFLAGS="$(TARGET_CPPFLAGS)" \
 	CGO_CXXFLAGS="$(filter-out $(GO_CFLAGS_TO_REMOVE),$(TARGET_CXXFLAGS))"
diff --git a/lang/golang/golang-values.mk b/lang/golang/golang-values.mk
index 8989a1af4..a5a8c9502 100644
--- a/lang/golang/golang-values.mk
+++ b/lang/golang/golang-values.mk
@@ -16,7 +16,7 @@ unexport \
   GOARCH GOBIN GOCACHE GOFLAGS GOHOSTARCH GOOS GOPATH GORACE GOROOT GOTMPDIR GCCGO \
   GOGC GODEBUG GOMAXPROCS GOTRACEBACK \
   CGO_ENABLED \
-  CGO_CFLAGS CGO_CFLAGS_ALLOW CGO_CFLAGS_DISALLOW \
+  CGO_CFLAGS CGO_CFLAGS_ALLOW CGO_CFLAGS_DISALLOW CGO_MACHINE_FLAGS \
   CGO_CPPFLAGS CGO_CPPFLAGS_ALLOW CGO_CPPFLAGS_DISALLOW \
   CGO_CXXFLAGS CGO_CXXFLAGS_ALLOW CGO_CXXFLAGS_DISALLOW \
   CGO_FFLAGS CGO_FFLAGS_ALLOW CGO_FFLAGS_DISALLOW \
diff --git a/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch b/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch
new file mode 100644
index 0..377c0a447
--- /dev/null
+++ b/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch
@@ -0,0 +1,28 @@
+From 6a5ab9c65b1930377d42b9ffeea93684586685ef Mon Sep 17 00:00:00 2001
+From: Daniel Santos 
+Date: Sun, 13 Sep 2020 20:45:55 -0500
+Subject: Add CGO_MACHINE_FLAGS to override hard-coded flags
+
+Adds CGO_MACHINE_FLAGS to add a mechanism to correct machine flags when
+the hard-coded ones chosen by Google are wrong or sub-optimal.
+---
+ src/cmd/go/internal/work/exec.go | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/cmd/go/internal/work/exec.go b/src/cmd/go/internal/work/exec.go
+index 892e3cb500..6fa050fd38 100644
+--- a/src/cmd/go/internal/work/exec.go
 b/src/cmd/go/internal/work/exec.go
+@@ -2400,6 +2400,9 @@ func (b *Builder) gccSupportsFlag(compiler []string, flag string) bool {
+ 
+ // gccArchArgs returns arguments to pass to gcc based on the architecture.
+ func (b *Builder) gccArchArgs() []string {
++	if af := os.Getenv("CGO_MACHINE_FLAGS"); af != "" {
++	return strings.Fields(af)
++	}
+ 	switch cfg.Goarch {
+ 	case "386":
+ 		return []string{"-m32"}
+-- 
+2.24.1
+
-- 
2.24.1

>From 985f3a6cc0c9fe69e441f17dfb6fcc77fbef68a9 Mon Sep 17 00:00:00 2001
From: Daniel Santos 
Date: Sun, 13 Sep 2020 22:31:14 -0500
Subject: Add MACHINE_FLAGS for use by Golang

This splits up the DEFAULT_CFLAGS --> TARGET_OPTIMIZATIONS flag
generation process, separating out the machine-specific flags.  This is
currently only used in a Golang patch to better control how CGo
generates code.

Signed-off-by: Da

1 2 >

1 - 100 of 199 matches

Mail list logo