[OpenWrt-Devel] [PATCH] ath79: add support for OCEDO Ursus
From: Markus Scheck
SOC: Qualcomm Atheros QCA9558
RAM: 128MB
FLASH: 16MB (Macronix MX25L12845EMI-10G)
WLAN1: QCA9558 2.4GHz 802.11bgn 3SS
WLAN2: QCA9880 5GHz 802.11ac 3SS
LED: Power, LAN1, LAN2, 2.4GHz, 5GHz
Serial:Next to SPI Flash,
Pinout is 3V3 - GND - TX - RX (Square Pin is 3V3)
The Serial setting is 115200-8-N-1
INSTALLATION:
1. Serve an OpenWrt ramdisk image named "ursus.bin".
Set your IP-address to 192.168.100.8/24.
2. Connect to the serial. Power up the device and interrupt
the boot process.
3. Set the correct bootcmd with
> setenv bootcmd run bootcmd_1
> saveenv
4. Run
> tftpboot 0x8100 ursus.bin
> bootm 0x8100
5. Wait for OpenWrt to boot up.
6. Transfer OpenWrt sysupdate image and flash via sysupgrade.
Signed-off-by: Markus Scheck
---
.../ath79/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/11-ath10k-caldata | 3 +-
.../linux/ath79/dts/qca9558_ocedo_ursus.dts | 136 ++
target/linux/ath79/image/generic.mk | 9 ++
4 files changed, 149 insertions(+), 2 deletions(-)
create mode 100644 target/linux/ath79/dts/qca9558_ocedo_ursus.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index 62318ee232..69b5c265b4 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -65,7 +65,8 @@ ath79_setup_interfaces()
"0@eth0" "1:lan:1" "3:lan:4" "4:lan:3" "5:lan:2" "2:wan"
;;
devolo,dvl1200e|\
- devolo,dvl1750e)
+ devolo,dvl1750e|\
+ ocedo,ursus)
ucidef_set_interface_lan "eth0 eth1"
;;
dlink,dir-825-b1)
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8651c97099..661008da8f 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -119,7 +119,8 @@ case "$FIRMWARE" in
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac_crc $(mtd_get_mac_text board_data 2176)
;;
- ocedo,koala)
+ ocedo,koala|\
+ ocedo,ursus)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(mtd_get_mac_binary art 12)
;;
diff --git a/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
b/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
new file mode 100644
index 00..5032e09c17
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "qca9557.dtsi"
+
+/ {
+ compatible = "ocedo,ursus", "qca,qca9557";
+ model = "OCEDO Ursus";
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ wifi2 {
+ label = "ursus:green:wlan2";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "phy1tpt";
+ };
+
+ wifi5 {
+ label = "ursus:green:wlan5";
+ gpios = < 15 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "phy0tpt";
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ clocks = <>;
+};
+
+ {
+ status = "okay";
+ num-cs = <1>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2500>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x04>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "u-boot-env";
+ reg = <0x04 0x01>;
+ };
+
+ partition@5 {
+ compatible = "denx,uimage";
+ label = "firmware";
+ reg = <0x05 0x74>;
+ };
+
+ partition@79 {
+ label = "vendor";
+ reg = <0x79 0x74>;
+ read-only;
+ };
+
+ partition@ed {
+ label = "data";
+
Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
On 3/19/19 11:17 AM, Florian Fainelli wrote:
On 3/19/19 11:14 AM, Christian Lamparter wrote:
Cc: Florian. I hope you don't mind.
On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
on an IPQ4019-based device, I can get basic connectivity either manually,
or with a "standard" UCI definition of the "lan" bridge[2].
(I'm aware that this is not "production" code and expect "challenges".)
[...]
This unfortunately results in a kernel panic when trying to add to the
bridge.
Bridge br-lan initially set up with "default" UCI config[2]
Full serial log available[4]
ip link add link wan0 name wan0.100 type vlan id 100
ip link set wan0 up
ip link set wan0.100 up
ip link set wan0.100 master br-lan
(kernel panics)
I've traced this to passing of a null pointer to br_vlan_enabled()
with the diagnostic patch shown in [5]
Yes, this shouldn't crash. I think Florian has already a patch for this
upstream [6].
Right, this specific commit omitted two key details which were that:
- not all drivers support port_vlan_{add,del}
- not all drivers support programming VID 0
This is fixed upstream with d6af21a4fb5fff2f6640feb011902212e658414d
("net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()")
commit 061f6a505ac33659eab007731c0f6374df39ab55
Author: Florian Fainelli
Date: Wed Feb 20 14:35:39 2019 -0800
net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
That should help with the NPEs since it now checks whenever the
bridge_dev is valid or not.
[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
[6]
[OpenWrt-Devel] [PATCH] kernel: Backport ar933x_uart build fix (fixes FS#2152)
Andrey has reported on OpenWrt's bug tracking system[1], that he
currently can't use ar93xx_uart as pure serial UART without console
(CONFIG_SERIAL_8250_CONSOLE and CONFIG_SERIAL_AR933X_CONSOLE undefined),
because compilation ends with following error:
ar933x_uart.c: In function 'ar933x_uart_console_write':
ar933x_uart.c:550:14: error: 'struct uart_port' has no
member named 'sysrq'
1. https://bugs.openwrt.org/index.php?do=details_id=2152
Signed-off-by: Petr Štetiar
---
...3x_uart-Fix-build-failure-with-disabled-c.patch | 99 ++
...3x_uart-Fix-build-failure-with-disabled-c.patch | 99 ++
2 files changed, 198 insertions(+)
create mode 100644
target/linux/generic/backport-4.14/060-v5.1-serial-ar933x_uart-Fix-build-failure-with-disabled-c.patch
create mode 100644
target/linux/generic/backport-4.19/060-v5.1-serial-ar933x_uart-Fix-build-failure-with-disabled-c.patch
diff --git
a/target/linux/generic/backport-4.14/060-v5.1-serial-ar933x_uart-Fix-build-failure-with-disabled-c.patch
b/target/linux/generic/backport-4.14/060-v5.1-serial-ar933x_uart-Fix-build-failure-with-disabled-c.patch
new file mode 100644
index 000..cb65317
--- /dev/null
+++
b/target/linux/generic/backport-4.14/060-v5.1-serial-ar933x_uart-Fix-build-failure-with-disabled-c.patch
@@ -0,0 +1,99 @@
+From 72ff51d8dd262d1fef25baedc2ac35116435be47 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20=C5=A0tetiar?=
+Date: Wed, 6 Mar 2019 17:54:03 +0100
+Subject: [PATCH] serial: ar933x_uart: Fix build failure with disabled console
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Andrey has reported on OpenWrt's bug tracking system[1], that he
+currently can't use ar93xx_uart as pure serial UART without console
+(CONFIG_SERIAL_8250_CONSOLE and CONFIG_SERIAL_AR933X_CONSOLE undefined),
+because compilation ends with following error:
+
+ ar933x_uart.c: In function 'ar933x_uart_console_write':
+ ar933x_uart.c:550:14: error: 'struct uart_port' has no
+ member named 'sysrq'
+
+So this patch moves all the code related to console handling behind
+series of CONFIG_SERIAL_AR933X_CONSOLE ifdefs.
+
+1. https://bugs.openwrt.org/index.php?do=details_id=2152
+
+Cc: Greg Kroah-Hartman
+Cc: Jiri Slaby
+Cc: Andrey Batyiev
+Reported-by: Andrey Batyiev
+Tested-by: Andrey Batyiev
+Signed-off-by: Petr Štetiar
+Signed-off-by: Greg Kroah-Hartman
+---
+ drivers/tty/serial/ar933x_uart.c | 24
+ 1 file changed, 8 insertions(+), 16 deletions(-)
+
+diff --git a/drivers/tty/serial/ar933x_uart.c
b/drivers/tty/serial/ar933x_uart.c
+index db5df3d..3bdd56a 100644
+--- a/drivers/tty/serial/ar933x_uart.c
b/drivers/tty/serial/ar933x_uart.c
+@@ -49,11 +49,6 @@ struct ar933x_uart_port {
+ struct clk *clk;
+ };
+
+-static inline bool ar933x_uart_console_enabled(void)
+-{
+- return IS_ENABLED(CONFIG_SERIAL_AR933X_CONSOLE);
+-}
+-
+ static inline unsigned int ar933x_uart_read(struct ar933x_uart_port *up,
+ int offset)
+ {
+@@ -508,6 +503,7 @@ static int ar933x_uart_verify_port(struct uart_port *port,
+ .verify_port= ar933x_uart_verify_port,
+ };
+
++#ifdef CONFIG_SERIAL_AR933X_CONSOLE
+ static struct ar933x_uart_port *
+ ar933x_console_ports[CONFIG_SERIAL_AR933X_NR_UARTS];
+
+@@ -604,14 +600,7 @@ static int ar933x_uart_console_setup(struct console *co,
char *options)
+ .index = -1,
+ .data = _uart_driver,
+ };
+-
+-static void ar933x_uart_add_console_port(struct ar933x_uart_port *up)
+-{
+- if (!ar933x_uart_console_enabled())
+- return;
+-
+- ar933x_console_ports[up->port.line] = up;
+-}
++#endif /* CONFIG_SERIAL_AR933X_CONSOLE */
+
+ static struct uart_driver ar933x_uart_driver = {
+ .owner = THIS_MODULE,
+@@ -700,7 +689,9 @@ static int ar933x_uart_probe(struct platform_device *pdev)
+ baud = ar933x_uart_get_baud(port->uartclk, 0, AR933X_UART_MAX_STEP);
+ up->max_baud = min_t(unsigned int, baud, AR933X_UART_MAX_BAUD);
+
+- ar933x_uart_add_console_port(up);
++#ifdef CONFIG_SERIAL_AR933X_CONSOLE
++ ar933x_console_ports[up->port.line] = up;
++#endif
+
+ ret = uart_add_one_port(_uart_driver, >port);
+ if (ret)
+@@ -749,8 +740,9 @@ static int __init ar933x_uart_init(void)
+ {
+ int ret;
+
+- if (ar933x_uart_console_enabled())
+- ar933x_uart_driver.cons = _uart_console;
++#ifdef CONFIG_SERIAL_AR933X_CONSOLE
++ ar933x_uart_driver.cons = _uart_console;
++#endif
+
+ ret = uart_register_driver(_uart_driver);
+ if (ret)
+--
+1.9.1
+
diff --git
a/target/linux/generic/backport-4.19/060-v5.1-serial-ar933x_uart-Fix-build-failure-with-disabled-c.patch
b/target/linux/generic/backport-4.19/060-v5.1-serial-ar933x_uart-Fix-build-failure-with-disabled-c.patch
new file mode 100644
index
[OpenWrt-Devel] [PATCH] kernel: brcm47xx: Backport fixes for USB on WNDR3400v2 (fixes FS#2170)
Eric has reported on OpenWrt's bug tracking system[1], that he's not able to use USB devices on his WNDR3400v2 device after the boot, until he turns on GPIO #21 manually through sysfs. 1. https://bugs.openwrt.org/index.php?do=details_id=2170 Signed-off-by: Petr Štetiar --- ...xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch | 39 ++ ...xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch | 39 ++ 2 files changed, 78 insertions(+) create mode 100644 target/linux/brcm47xx/patches-4.14/035-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch create mode 100644 target/linux/brcm47xx/patches-4.19/031-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch diff --git a/target/linux/brcm47xx/patches-4.14/035-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch b/target/linux/brcm47xx/patches-4.14/035-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch new file mode 100644 index 000..6e8ad0f --- /dev/null +++ b/target/linux/brcm47xx/patches-4.14/035-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch @@ -0,0 +1,39 @@ +From cdb8faa00e3fcdd0ad10add743516d616dc7d38e Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Petr=20=C5=A0tetiar?= +Date: Mon, 11 Mar 2019 22:08:22 +0100 +Subject: [PATCH] mips: bcm47xx: Enable USB power on Netgear WNDR3400v2 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Eric has reported on OpenWrt's bug tracking system[1], that he's not +able to use USB devices on his WNDR3400v2 device after the boot, until +he turns on GPIO #21 manually through sysfs. + +1. https://bugs.openwrt.org/index.php?do=details_id=2170 + +Cc: Rafał Miłecki +Cc: Hauke Mehrtens +Reported-by: Eric Bohlman +Tested-by: Eric Bohlman +Signed-off-by: Petr Štetiar +Signed-off-by: Paul Burton +--- + arch/mips/bcm47xx/workarounds.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c +index 46eddbe..0ab95dd 100644 +--- a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c +@@ -24,6 +24,7 @@ void __init bcm47xx_workarounds(void) + case BCM47XX_BOARD_NETGEAR_WNR3500L: + bcm47xx_workarounds_enable_usb_power(12); + break; ++ case BCM47XX_BOARD_NETGEAR_WNDR3400V2: + case BCM47XX_BOARD_NETGEAR_WNDR3400_V3: + bcm47xx_workarounds_enable_usb_power(21); + break; +-- +1.9.1 + diff --git a/target/linux/brcm47xx/patches-4.19/031-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch b/target/linux/brcm47xx/patches-4.19/031-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch new file mode 100644 index 000..6e8ad0f --- /dev/null +++ b/target/linux/brcm47xx/patches-4.19/031-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch @@ -0,0 +1,39 @@ +From cdb8faa00e3fcdd0ad10add743516d616dc7d38e Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Petr=20=C5=A0tetiar?= +Date: Mon, 11 Mar 2019 22:08:22 +0100 +Subject: [PATCH] mips: bcm47xx: Enable USB power on Netgear WNDR3400v2 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Eric has reported on OpenWrt's bug tracking system[1], that he's not +able to use USB devices on his WNDR3400v2 device after the boot, until +he turns on GPIO #21 manually through sysfs. + +1. https://bugs.openwrt.org/index.php?do=details_id=2170 + +Cc: Rafał Miłecki +Cc: Hauke Mehrtens +Reported-by: Eric Bohlman +Tested-by: Eric Bohlman +Signed-off-by: Petr Štetiar +Signed-off-by: Paul Burton +--- + arch/mips/bcm47xx/workarounds.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c +index 46eddbe..0ab95dd 100644 +--- a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c +@@ -24,6 +24,7 @@ void __init bcm47xx_workarounds(void) + case BCM47XX_BOARD_NETGEAR_WNR3500L: + bcm47xx_workarounds_enable_usb_power(12); + break; ++ case BCM47XX_BOARD_NETGEAR_WNDR3400V2: + case BCM47XX_BOARD_NETGEAR_WNDR3400_V3: + bcm47xx_workarounds_enable_usb_power(21); + break; +-- +1.9.1 + -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] iwinfo: Complete device IDs for Ubiquiti airOS XM/XW devices
Hi Mathias, I've put you in the CC as you have commit rights for the iwinfo repository. Regards, Vincent Wiemann (CodeFetch) On 16.03.2019 22:32, Vincent Wiemann wrote: > This commit includes all power offsets and subsystem device IDs > for Ubiquiti XM and XW devices. The device ID is wildcarded. > Consistency has been tested among all Ubiquiti platforms. > These values seem to be PA gains and likely do not include > antenna gains. I expect the antenna gains to be defined in ART- > partitions. > > Signed-off-by: Vincent Wiemann > --- > hardware.txt | 103 > --- > 1 file changed, 98 insertions(+), 5 deletions(-) > > diff --git a/hardware.txt b/hardware.txt > index f36c476..727c607 100644 > --- a/hardware.txt > +++ b/hardware.txt > @@ -17,6 +17,99 @@ > 0x 0x 0x 0xc1055 0 "Ubiquiti" "NanoStation Loco5" > 0x 0x 0x 0xc202 10 0 "Ubiquiti" "Bullet2" > 0x 0x 0x 0xc2055 0 "Ubiquiti" "Bullet5" > +0x168c 0x 0x0777 0xe0026 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe0033 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe0055 0 "Ubiquiti" "NanoStation M5" /* > airOS XM */ > +0x168c 0x 0x0777 0xe0065 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe0096 0 "Ubiquiti" "NanoStation Loco M9" /* > airOS XM */ > +0x168c 0x 0x0777 0xe012 10 0 "Ubiquiti" "NanoStation M2" /* > airOS XM */ > +0x168c 0x 0x0777 0xe0353 0 "Ubiquiti" "NanoStation M3" /* > airOS XM */ > +0x168c 0x 0x0777 0xe0a22 0 "Ubiquiti" "NanoStation Loco M2" /* > airOS XM */ > +0x168c 0x 0x0777 0xe0a51 0 "Ubiquiti" "NanoStation Loco M5" /* > airOS XM */ > +0x168c 0x 0x0777 0xe1026 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1055 0 "Ubiquiti" "Rocket M5" /* airOS XM > */ > +0x168c 0x 0x0777 0xe112 10 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1153 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1a33 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1a55 0 "Ubiquiti" "PowerBridge M5" /* > airOS XM */ > +0x168c 0x 0x0777 0xe1b2 10 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1b33 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1b55 0 "Ubiquiti" "Rocket M5" /* airOS XM > */ > +0x168c 0x 0x0777 0xe1b65 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1b96 0 "Ubiquiti" "Rocket M9" /* airOS XM > */ > +0x168c 0x 0x0777 0xe1c2 10 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1c33 0 "Ubiquiti" "Rocket M3" /* airOS XM > */ > +0x168c 0x 0x0777 0xe1c55 0 "Ubiquiti" "Rocket M5 GPS" /* airOS > XM */ > +0x168c 0x 0x0777 0xe1c55 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1d2 10 0 "Ubiquiti" "Rocket M2 Titanium" /* > airOS XM/XW */ > +0x168c 0x 0x0777 0xe1d33 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1d55 0 "Ubiquiti" "airOS XM/XW" > +0x168c 0x 0x0777 0xe1d96 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1e33 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe1e55 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe202 12 0 "Ubiquiti" "Bullet M2" /* airOS XM > */ > +0x168c 0x 0x0777 0xe2056 0 "Ubiquiti" "Bullet M5" /* airOS XM > */ > +0x168c 0x 0x0777 0xe2121 0 "Ubiquiti" "AirGrid M2" /* airOS XM > */ > +0x168c 0x 0x0777 0xe2151 0 "Ubiquiti" "AirGrid M5" /* airOS XM > */ > +0x168c 0x 0x0777 0xe2322 0 "Ubiquiti" "NanoBridge M2" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2333 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe2351 0 "Ubiquiti" "NanoBridge M5" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2396 0 "Ubiquiti" "NanoBridge M9" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2429 0 "Ubiquiti" "AirGrid M2 HP" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2433 0 "Ubiquiti" "NanoBridge M3" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2456 0 "Ubiquiti" "AirGrid M5 HP" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2529 0 "Ubiquiti" "AirGrid M2 HP" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2556 0 "Ubiquiti" "AirGrid M5 HP" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2a33 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe2a55 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe2b2 10 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe2b51 0 "Ubiquiti" "NanoBridge M5" /* airOS > XM */ > +0x168c 0x 0x0777 0xe2b96 0 "Ubiquiti" "airOS XM" > +0x168c 0x 0x0777 0xe2c2 10 0 "Ubiquiti" "NanoBeam M2 Int" /* > airOS XW */ > +0x168c 0x 0x0777 0xe2c36 0 "Ubiquiti" "Bullet M2 XW" /* airOS > XW */ > +0x168c 0x
Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
Cc: Florian. I hope you don't mind.
On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
> Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
> on an IPQ4019-based device, I can get basic connectivity either manually,
> or with a "standard" UCI definition of the "lan" bridge[2].
>
> (I'm aware that this is not "production" code and expect "challenges".)
>
> However, I'm puzzled as how to manage VLANs and tagging, even using
> `ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).
>
> It appears that the qca8k driver doesn't support `bridge` VLAN-related
> commands. Checking the source doesn't show implementation of the
> `port_vlan_*` functions described in the Linux DSA doc[3].
>
>
> Setting aside my suspicion that a port-based VLAN approach seems
> unlikely to be able to handle trunking of VLANs, I tried adding a
> sub-interface of one of the otherwise unused phy interfaces (renamed
> in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").
At first glance, I think you are running into what's described in section
"Design limitations" of DSA in [3]:"
- inability to configure specific VLAN IDs / trunking VLANs between switches
when using a cascaded setup". (Sadly there isn't a link to a possible
patch or discussion so I don't know the state of it).
However...
> This unfortunately results in a kernel panic when trying to add to the
> bridge.
>
> Bridge br-lan initially set up with "default" UCI config[2]
>
> Full serial log available[4]
>
>ip link add link wan0 name wan0.100 type vlan id 100
>ip link set wan0 up
>ip link set wan0.100 up
>ip link set wan0.100 master br-lan
>(kernel panics)
>
>
> I've traced this to passing of a null pointer to br_vlan_enabled()
> with the diagnostic patch shown in [5]
Yes, this shouldn't crash. I think Florian has already a patch for this
upstream [6].
commit 061f6a505ac33659eab007731c0f6374df39ab55
Author: Florian Fainelli
Date: Wed Feb 20 14:35:39 2019 -0800
net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
That should help with the NPEs since it now checks whenever the
bridge_dev is valid or not.
[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
[6]
Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
On 3/19/19 11:14 AM, Christian Lamparter wrote:
> Cc: Florian. I hope you don't mind.
>
> On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
>> Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
>> on an IPQ4019-based device, I can get basic connectivity either manually,
>> or with a "standard" UCI definition of the "lan" bridge[2].
>>
>> (I'm aware that this is not "production" code and expect "challenges".)
>>
>> However, I'm puzzled as how to manage VLANs and tagging, even using
>> `ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).
>>
>> It appears that the qca8k driver doesn't support `bridge` VLAN-related
>> commands. Checking the source doesn't show implementation of the
>> `port_vlan_*` functions described in the Linux DSA doc[3].
>>
>>
>> Setting aside my suspicion that a port-based VLAN approach seems
>> unlikely to be able to handle trunking of VLANs, I tried adding a
>> sub-interface of one of the otherwise unused phy interfaces (renamed
>> in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").
>
> At first glance, I think you are running into what's described in section
> "Design limitations" of DSA in [3]:"
> - inability to configure specific VLAN IDs / trunking VLANs between switches
> when using a cascaded setup". (Sadly there isn't a link to a possible
> patch or discussion so I don't know the state of it).
>
> However...
>
>> This unfortunately results in a kernel panic when trying to add to the
>> bridge.
>>
>> Bridge br-lan initially set up with "default" UCI config[2]
>>
>> Full serial log available[4]
>>
>>ip link add link wan0 name wan0.100 type vlan id 100
>>ip link set wan0 up
>>ip link set wan0.100 up
>>ip link set wan0.100 master br-lan
>>(kernel panics)
>>
>>
>> I've traced this to passing of a null pointer to br_vlan_enabled()
>> with the diagnostic patch shown in [5]
>
> Yes, this shouldn't crash. I think Florian has already a patch for this
> upstream [6].
Right, this specific commit omitted two key details which were that:
- not all drivers support port_vlan_{add,del}
- not all drivers support programming VID 0
This is fixed upstream with d6af21a4fb5fff2f6640feb011902212e658414d
("net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()")
>
> commit 061f6a505ac33659eab007731c0f6374df39ab55
> Author: Florian Fainelli
> Date: Wed Feb 20 14:35:39 2019 -0800
>
> net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
>
> That should help with the NPEs since it now checks whenever the
> bridge_dev is valid or not.
>
> [3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
> [6]
Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
Hi Jeff, sounds a bit like https://www.spinics.net/lists/netdev/msg552100.html Regards, Vincent Wiemann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
on an IPQ4019-based device, I can get basic connectivity either manually,
or with a "standard" UCI definition of the "lan" bridge[2].
(I'm aware that this is not "production" code and expect "challenges".)
However, I'm puzzled as how to manage VLANs and tagging, even using
`ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).
It appears that the qca8k driver doesn't support `bridge` VLAN-related
commands. Checking the source doesn't show implementation of the
`port_vlan_*` functions described in the Linux DSA doc[3].
Setting aside my suspicion that a port-based VLAN approach seems
unlikely to be able to handle trunking of VLANs, I tried adding a
sub-interface of one of the otherwise unused phy interfaces (renamed
in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").
This unfortunately results in a kernel panic when trying to add to the
bridge.
Bridge br-lan initially set up with "default" UCI config[2]
Full serial log available[4]
ip link add link wan0 name wan0.100 type vlan id 100
ip link set wan0 up
ip link set wan0.100 up
ip link set wan0.100 master br-lan
(kernel panics)
I've traced this to passing of a null pointer to br_vlan_enabled()
with the diagnostic patch shown in [5]
root@OpenWrt:/# ip link add link wan0 name wan0.100 type vlan id 100
root@OpenWrt:/# ip link set wan0 up
[ 104.994191] qca8k c00.switch wan0: configuring for phy/ link mode
[ 104.994465] IPv6: ADDRCONF(NETDEV_UP): wan0: link is not ready
[ 104.07] IPv6: ADDRCONF(NETDEV_UP): wan0.100: link is not ready
root@OpenWrt:/# [ 106.086762] qca8k c00.switch wan0: Link is Up -
1Gbps/Full - flow control off
[ 106.087172] IPv6: ADDRCONF(NETDEV_CHANGE): wan0: link becomes ready
[ 106.095911] IPv6: ADDRCONF(NETDEV_CHANGE): wan0.100: link becomes ready
root@OpenWrt:/# ip link set wan0.100 up
root@OpenWrt:/# ip link set wan0.100 master br-lan
[ 125.304300] br-lan: port 8(wan0.100) entered blocking state
[ 125.304384] br-lan: port 8(wan0.100) entered disabled state
[ 125.309269] device wan0.100 entered promiscuous mode
[ 125.314262] device wan0 entered promiscuous mode
[ 125.320068] VLAN: dsa_port_vlan_add(dsa_port *dp: ecf2e7af)
[ 125.324073] VLAN: net_device->name: wan0
[ 125.329413] VLAN: (port) index: 5, name: wan0, type: 3
[ 125.333529] VLAN: ds->index: 0
[ 125.338499] [ cut here ]
[ 125.341532] WARNING: CPU: 2 PID: 2722 at net/bridge/br_vlan.c:756
br_vlan_enabled+0x28/0x38
[ 125.346320] VLAN: br_vlan_enabled( (null))
Examining earlier in the log, the call to br_vlan_enabled()
is passed a pointer to a valid net_device for other interfaces.
As I've got a running device on the bench with which I can test
things, I'm willing to dig into this further either for diagnostics or
for testing. Please let me know how I can further help.
Jeff
[1]
$ git log -1 --pretty=fuller $(git merge-base HEAD master)
commit b61495409b
Author: Tony Ambardar
AuthorDate: Thu Dec 13 23:49:32 2018 -0800
Commit: Hans Dedecker
CommitDate: Thu Mar 14 22:55:06 2019 +0100
Cherry-picked from staging/chunkeey:
9b3a3a9cdf ipq40xx: include ipq40xx-ized qca8k version
5272a018b9 ipq40xx: fix NPE related to bogus use of fixed phy
e3946c85a6 ipq40xx: extend DT mdio node to be more accessible
273ffef2d8 ipq40xx: add ipqess ethernet driver
9b34795310 ipq40xx: add resets for individual MAC1-5 and PSGMII
f1042e1b15 ipq40xx: decouple mdio-ipq40xx and ar40xx
e34265ecf1 phytool: add phytool utility
[2]
config interface 'lan'
option type 'bridge'
option ifname 'lan1 lan2 lan3 lan4'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
[4] https://gist.github.com/jeffsf/21109ff71a9041ebe4bd452d9cc0ddce
[5]
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -753,6 +753,8 @@ bool br_vlan_enabled(const struct net_de
{
struct net_bridge *br = netdev_priv(dev);
+ WARN(!(dev), "VLAN: br_vlan_enabled(%p)\n", ((void *)dev));
+
return !!br->vlan_enabled;
}
EXPORT_SYMBOL_GPL(br_vlan_enabled);
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,6 +255,11 @@ int dsa_port_vlan_add(struct dsa_port *d
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
+ pr_notice("VLAN: dsa_port_vlan_add(dsa_port *dp: %p)\n", ((void *)dp));
+ pr_notice("VLAN: net_device->name: %s\n", dp->master->name);
+ pr_notice("VLAN: (port) index: %d, name: %s, type: %i\n",
dp->index, dp->name, dp->type);
+ pr_notice("VLAN: ds->index: %d\n", dp->ds->index);
+
if (br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, );
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
[OpenWrt-Devel] [PATCH] ath79: GL.iNet AR300M-nand/nor: correct LAN LED
The port labled as "LAN" is eth1. That's different from the -lite variant, where the only existing port eth0 is used as LAN Signed-off-by: Andreas Ziegler --- target/linux/ath79/base-files/etc/board.d/01_leds | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds b/target/linux/ath79/base-files/etc/board.d/01_leds index 0b0dda3bcf..66247ca55d 100755 --- a/target/linux/ath79/base-files/etc/board.d/01_leds +++ b/target/linux/ath79/base-files/etc/board.d/01_leds @@ -65,7 +65,7 @@ glinet,gl-ar150) ;; glinet,gl-ar300m-nand|\ glinet,gl-ar300m-nor) - ucidef_set_led_netdev "lan" "LAN" "gl-ar300m:green:lan" "eth0" + ucidef_set_led_netdev "lan" "LAN" "gl-ar300m:green:lan" "eth1" ;; glinet,gl-ar300m-lite) ucidef_set_led_netdev "lan" "LAN" "gl-ar300m-lite:green:lan" "eth0" -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: GL.iNet AR300M-nand/nor: correct LAN LED
On Tuesday, March 19, 2019 12:59:16 AM CET Andreas Ziegler wrote: > The port labled as "LAN" is eth1. > That's different from the -lite variant, > where the only existing port eth0 is used as LAN Please resend your patch with a Signed-off-by. > --- > target/linux/ath79/base-files/etc/board.d/01_leds | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds > b/target/linux/ath79/base-files/etc/board.d/01_leds > index 0b0dda3bcf..66247ca55d 100755 > --- a/target/linux/ath79/base-files/etc/board.d/01_leds > +++ b/target/linux/ath79/base-files/etc/board.d/01_leds > @@ -65,7 +65,7 @@ glinet,gl-ar150) > ;; > glinet,gl-ar300m-nand|\ > glinet,gl-ar300m-nor) > - ucidef_set_led_netdev "lan" "LAN" "gl-ar300m:green:lan" "eth0" > + ucidef_set_led_netdev "lan" "LAN" "gl-ar300m:green:lan" "eth1" > ;; > glinet,gl-ar300m-lite) > ucidef_set_led_netdev "lan" "LAN" "gl-ar300m-lite:green:lan" "eth0" > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] wireguard: do not add host-dependencies if fwmark is set
The 'fwmark' option is used to define routing traffic to
wireguard endpoints to go through specific routing tables.
In that case it doesn't make sense to setup routes for
host-dependencies in the 'main' table, so skip setting host
dependencies if 'fwmark' is set.
Signed-off-by: Daniel Golle
---
.../network/services/wireguard/files/wireguard.sh | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/package/network/services/wireguard/files/wireguard.sh
b/package/network/services/wireguard/files/wireguard.sh
index 96fa7215ff..58e47f9450 100644
--- a/package/network/services/wireguard/files/wireguard.sh
+++ b/package/network/services/wireguard/files/wireguard.sh
@@ -176,12 +176,14 @@ proto_wireguard_setup() {
done
# endpoint dependency
- wg show "${config}" endpoints | \
-sed -E 's/\[?([0-9.:a-f]+)\]?:([0-9]+)/\1 \2/' | \
-while IFS=$'\t ' read -r key address port; do
-[ -n "${port}" ] || continue
-proto_add_host_dependency "${config}" "${address}"
- done
+ if [ ! "${fwmark}" ]; then
+wg show "${config}" endpoints | \
+ sed -E 's/\[?([0-9.:a-f]+)\]?:([0-9]+)/\1 \2/' | \
+ while IFS=$'\t ' read -r key address port; do
+ [ -n "${port}" ] || continue
+ proto_add_host_dependency "${config}" "${address}"
+done
+ fi
proto_send_update "${config}"
}
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Broken ipv6 relay
On Tue, Mar 19, 2019 at 1:53 PM Ansuel Smith wrote: > > Can someone take a look at this bug? Real job is keeping me busy; when I have time I will look into this Hans > > ___ > 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] Broken ipv6 relay
Can someone take a look at this bug? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] ath79: add support for COMFAST CF-E313AC
Hi,
I've just added support for the COMFAST CF-E313AC, an outdoor wireless
CPE with two Ethernet ports and a 802.11ac radio (see patch below).
Everything is working fine but I've got two issues for which I'd like to
get some advise:
1) target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
I had to add "rm /lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin", since
the driver tries to board-2.bin (the default calibration data from the
firmware package) first and, when that file is not found, falls back to
board.bin (the calibration data read from the flash).
I haven't seen this on any other device, so I guess there must be a more
elegant way to deal with it. Any idea?
2) target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
The device is equipped with a "w25q128" flash chip (16384 Kbytes) but the
stock firmware image only used half of it (nvram partition finishes at
0x0080, i.e., 8192 Kbytes):
*** stock firmware bootlog ***
[...]
[0.73] 0x-0x0001 : "u-boot"
[0.74] 0x0001-0x0002 : "art"
[0.74] 0x0002-0x001a : "kernel"
[0.75] 0x001a-0x007e : "rootfs"
[0.76] mtd: device 3 (rootfs) set to be root filesystem
[0.76] 1 squashfs-split partitions found on MTD device rootfs
[0.77] 0x006c-0x007e : "rootfs_data"
[0.78] 0x007e-0x007f : "configs"
[0.78] 0x007f-0x0080 : "nvram"
[0.79] 0x0002-0x007e : "firmware"
[...]
Is there a way to use the remaining half of the flash?
Any comments regarding these or other issues will be highly appreciated.
Thanks!
---
.../ath79/base-files/etc/board.d/01_leds | 9 ++
.../etc/hotplug.d/firmware/11-ath10k-caldata | 7 +
.../ath79/dts/qca9531_comfast_cf-e313ac.dts | 143 ++
target/linux/ath79/image/generic.mk | 8 +
4 files changed, 167 insertions(+)
create mode 100644 target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds
b/target/linux/ath79/base-files/etc/board.d/01_leds
index db5a6a4578..50c9ca2a8d 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -47,6 +47,15 @@ comfast,cf-e120a-v3)
ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH"
"$boardname:green:rssimediumhigh" "wlan0" "51" "100"
ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "$boardname:green:rssihigh"
"wlan0" "76" "100"
;;
+comfast,cf-e313ac)
+ ucidef_set_led_netdev "lan" "LAN" "$boardname:green:lan" "eth0"
+ ucidef_set_led_switch "wan" "WAN" "$boardname:green:wan" "switch0"
"0x02"
+ ucidef_set_rssimon "wlan0" "20" "1"
+ ucidef_set_led_rssi "rssilow" "RSSILOW" "$boardname:red:rssilow"
"wlan0" "1" "100"
+ ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMLOW"
"$boardname:red:rssimediumlow" "wlan0" "26" "100"
+ ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH"
"$boardname:green:rssimediumhigh" "wlan0" "51" "100"
+ ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "$boardname:green:rssihigh"
"wlan0" "76" "100"
+ ;;
dlink,dir-859-a1)
ucidef_set_led_switch "internet" "WAN" "$boardname:green:internet"
"switch0" "0x20"
;;
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8651c97099..3096c4e1e8 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -162,6 +162,13 @@ case "$FIRMWARE" in
;;
"ath10k/pre-cal-pci-:00:00.0.bin")
case $board in
+ comfast,cf-e313ac)
+ ath10kcal_extract "art" 20480 12064
+ ath10kcal_patch_mac_crc $(mtd_get_mac_binary art 4098)
+ ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
+ /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
+ rm /lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin
+ ;;
phicomm,k2t)
ath10kcal_extract "art" 20480 12064
ath10kcal_patch_mac_crc $(k2t_get_mac "5g_mac")
diff --git a/target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
b/target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
new file mode 100644
index 00..cf6587b615
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "qca953x.dtsi"
+
+/ {
+ compatible = "comfast,cf-e313ac", "qca,qca9531";
+ model = "COMFAST CF-E313AC";
+
+ aliases {
+ serial0 =
+ led-boot =
+ led-failsafe =
Re: [OpenWrt-Devel] [PATCH] [odhcp6c] ra: clear RA information and request new after link-up event or SIGUSR2
>why is this not the case in your setup ?
Because sometimes odhcp6c miss restart, probably because of Bridge Mode
(it's attached to bridge interface).
Anyway, I use a hotplug script which sends SIGUSR2 signal to odhcp6c on
link-up event.
Of course I could send SIGTERM, but I think it's not the proper way to
solve problem.
I thought that it is an obvious bug because I see a lack of consistency.
Why odhcp6c on SIGUSR2
clear STATE_IA_ and resend DHCPV6_MSG_
and don't do same with RA - clear STATE_RA_ and resend Router Solicitation
message?
Br,
Pavel
On Tue, 19 Mar 2019 at 12:36, Hans Dedecker wrote:
> Hi,
>
> On Mon, Mar 18, 2019 at 8:51 PM Pavel Merzlyakov
> wrote:
> >
> > Hi,
> >
> > >Can you be elaborate more in detail what use case you want to cover
> > >with this patch; in other words what is not working now ?
> > Ok,
> > my setup:
> > Two peer routers A and B which both connected to gateway C.
> > Routers A and B have public IPv6 addresses on WAN interfaces from same
> subnet (because of RA on C) and private IPv6 addresses on LAN interfaces.
> > and issue:
> > If I unplug router B from C and then plug it in LAN port of router A:
> > 1) Router B does not send Router Solicitation message. So router B does
> not have a valid gateway for some time.
> Since we've linksensing support in netifd the wan/wan6 interface
> should be brought down when the cable is unplugged; the wan/wan6
> interface will be brought up again when the cable is plugged in. This
> means odhcp6c will be restarted and will start sending RS; why is this
> not the case in your setup ?
>
> Hans
> > 2) Router B does not delete old IPv6 address on the WAN. After first
> Router Advertisement message router B is capable to send a request via new
> gateway A, but it can't receive responses because of invalid/old source
> address in request.
> >
> >
> > >Why do you want to restart RA if an SIGUSR2 signal is received ?
> > Because I assume that SIGUSR2 signal is equivalent to link-up event
> (see odhcp6c:674 ->
> https://git.openwrt.org/?p=project/odhcp6c.git;a=blob;f=src/odhcp6c.c;h=19a86f2654bf3c59b0f47cf0aedd87235187bf89;hb=d2e247d8d87ecf8c60fcf0acdad05667bd379521#l674
> ).
> > In my case I use hotplug script witch on link-up sends SIGUSR2 signal to
> odhcp6c (it's connected to bridge interface).
> > ra_restart () could be called without condition in beginning of the main
> loop.
> >
> > Br,
> > Pavel
> >
> > On Mon, 18 Mar 2019 at 18:26, Hans Dedecker wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Mar 18, 2019 at 2:43 PM wrote:
> >> >
> >> > From: Pavel Merzlyakov
> >> >
> >> > A subnet may be changed after link-up event
> >> Can you be elaborate more in detail what use case you want to cover
> >> with this patch; in other words what is not working now ?
> >> >
> >> > Signed-off-by: Pavel Merzlyakov
> >> > ---
> >> > src/odhcp6c.c | 3 +++
> >> > src/ra.c | 20 +---
> >> > src/ra.h | 1 +
> >> > 3 files changed, 21 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/src/odhcp6c.c b/src/odhcp6c.c
> >> > index 19a86f2..dd20f39 100644
> >> > --- a/src/odhcp6c.c
> >> > +++ b/src/odhcp6c.c
> >> > @@ -455,6 +455,9 @@ int main(_unused int argc, char* const argv[])
> >> >
> >> > syslog(LOG_NOTICE, "(re)starting transaction on %s",
> ifname);
> >> >
> >> > + if (signal_usr2)
> >> > + ra_restart();
> >> Why do you want to restart RA if an SIGUSR2 signal is received ?
> >>
> >> Hans
> >> > +
> >> > signal_usr1 = signal_usr2 = false;
> >> > int mode = dhcpv6_set_ia_mode(ia_na_mode, ia_pd_mode);
> >> > if (mode != DHCPV6_STATELESS)
> >> > diff --git a/src/ra.c b/src/ra.c
> >> > index 898f449..917df11 100644
> >> > --- a/src/ra.c
> >> > +++ b/src/ra.c
> >> > @@ -55,6 +55,7 @@ static int sock = -1, rtnl = -1;
> >> > static int if_index = 0;
> >> > static char if_name[IF_NAMESIZE] = {0};
> >> > static volatile int rs_attempt = 0;
> >> > +static const int rs_attempt_limit = 4;
> >> > static struct in6_addr lladdr = IN6ADDR_ANY_INIT;
> >> > static unsigned int ra_options = 0;
> >> > static unsigned int ra_holdoff_interval = 0;
> >> > @@ -179,6 +180,20 @@ failure:
> >> > return -1;
> >> > }
> >> >
> >> > +void ra_restart(void)
> >> > +{
> >> > + const int rs_attempt_old = rs_attempt;
> >> > +
> >> > + odhcp6c_clear_state(STATE_RA_PREFIX);
> >> > + odhcp6c_clear_state(STATE_RA_ROUTE);
> >> > + odhcp6c_clear_state(STATE_RA_DNS);
> >> > + odhcp6c_clear_state(STATE_RA_SEARCH);
> >> > +
> >> > + rs_attempt = 0;
> >> > + if (rs_attempt_old == 0 || rs_attempt_old >= rs_attempt_limit)
> >> > + ra_send_rs(SIGALRM);
> >> > +}
> >> > +
> >> > static void ra_send_rs(int signal __attribute__((unused)))
> >> > {
> >> > const struct sockaddr_in6 dest = {AF_INET6, 0, 0,
> ALL_IPV6_ROUTERS, if_index};
> >> > @@ -193,7 +208,7 @@ static void ra_send_rs(int signal
>
Re: [OpenWrt-Devel] Meson/Ninja build system
On 2019-03-18 14:03, Jo-Philipp Wich wrote: > Hi, > >> I think the cmake.mk-link approach would be a good idea and given >> previous discussions the plan is afaik to pull in Ninja first and >> once that's confirmed working via CMake add support for Meson. > > fine with me. > >> Having a look at https://www.python.org/dev/peps/pep-0537/#lifespan >> it seems like a good idea to stick with 3.7? > > No opinion. > >> As for OpenWrt, there are already files with hard dependency of >> python3 dating back to 2015 doing a quick grep of the source tree. >> >> https://github.com/openwrt/openwrt/blob/master/scripts/dl_cleanup.py >> https://github.com/openwrt/openwrt/blob/master/scripts/flashing/eva_ramboot.py > > Both files are supplemental scripts not used as part of the actual build > process. > >> There are also upstream projects like wireless-db that doesn't >> compile/build cleanly with vanilla 2.7 >> https://github.com/openwrt/openwrt/pull/1521 > > On the other end of the spectrum there is SCons (include/scons.mk) which > apparently explicitly does not support Python 3 [1]. > > Having to depend on two Python versions is not ideal. Maybe it is worth > sacrificing scons support for meson, depending on the number of users. It seems that this wiki information is outdated and current versions of SCons support python 3. Let's go with that. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [odhcp6c] ra: clear RA information and request new after link-up event or SIGUSR2
Hi,
On Mon, Mar 18, 2019 at 8:51 PM Pavel Merzlyakov
wrote:
>
> Hi,
>
> >Can you be elaborate more in detail what use case you want to cover
> >with this patch; in other words what is not working now ?
> Ok,
> my setup:
> Two peer routers A and B which both connected to gateway C.
> Routers A and B have public IPv6 addresses on WAN interfaces from same subnet
> (because of RA on C) and private IPv6 addresses on LAN interfaces.
> and issue:
> If I unplug router B from C and then plug it in LAN port of router A:
> 1) Router B does not send Router Solicitation message. So router B does not
> have a valid gateway for some time.
Since we've linksensing support in netifd the wan/wan6 interface
should be brought down when the cable is unplugged; the wan/wan6
interface will be brought up again when the cable is plugged in. This
means odhcp6c will be restarted and will start sending RS; why is this
not the case in your setup ?
Hans
> 2) Router B does not delete old IPv6 address on the WAN. After first Router
> Advertisement message router B is capable to send a request via new gateway
> A, but it can't receive responses because of invalid/old source address in
> request.
>
>
> >Why do you want to restart RA if an SIGUSR2 signal is received ?
> Because I assume that SIGUSR2 signal is equivalent to link-up event (see
> odhcp6c:674 ->
> https://git.openwrt.org/?p=project/odhcp6c.git;a=blob;f=src/odhcp6c.c;h=19a86f2654bf3c59b0f47cf0aedd87235187bf89;hb=d2e247d8d87ecf8c60fcf0acdad05667bd379521#l674).
> In my case I use hotplug script witch on link-up sends SIGUSR2 signal to
> odhcp6c (it's connected to bridge interface).
> ra_restart () could be called without condition in beginning of the main loop.
>
> Br,
> Pavel
>
> On Mon, 18 Mar 2019 at 18:26, Hans Dedecker wrote:
>>
>> Hi,
>>
>> On Mon, Mar 18, 2019 at 2:43 PM wrote:
>> >
>> > From: Pavel Merzlyakov
>> >
>> > A subnet may be changed after link-up event
>> Can you be elaborate more in detail what use case you want to cover
>> with this patch; in other words what is not working now ?
>> >
>> > Signed-off-by: Pavel Merzlyakov
>> > ---
>> > src/odhcp6c.c | 3 +++
>> > src/ra.c | 20 +---
>> > src/ra.h | 1 +
>> > 3 files changed, 21 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/odhcp6c.c b/src/odhcp6c.c
>> > index 19a86f2..dd20f39 100644
>> > --- a/src/odhcp6c.c
>> > +++ b/src/odhcp6c.c
>> > @@ -455,6 +455,9 @@ int main(_unused int argc, char* const argv[])
>> >
>> > syslog(LOG_NOTICE, "(re)starting transaction on %s",
>> > ifname);
>> >
>> > + if (signal_usr2)
>> > + ra_restart();
>> Why do you want to restart RA if an SIGUSR2 signal is received ?
>>
>> Hans
>> > +
>> > signal_usr1 = signal_usr2 = false;
>> > int mode = dhcpv6_set_ia_mode(ia_na_mode, ia_pd_mode);
>> > if (mode != DHCPV6_STATELESS)
>> > diff --git a/src/ra.c b/src/ra.c
>> > index 898f449..917df11 100644
>> > --- a/src/ra.c
>> > +++ b/src/ra.c
>> > @@ -55,6 +55,7 @@ static int sock = -1, rtnl = -1;
>> > static int if_index = 0;
>> > static char if_name[IF_NAMESIZE] = {0};
>> > static volatile int rs_attempt = 0;
>> > +static const int rs_attempt_limit = 4;
>> > static struct in6_addr lladdr = IN6ADDR_ANY_INIT;
>> > static unsigned int ra_options = 0;
>> > static unsigned int ra_holdoff_interval = 0;
>> > @@ -179,6 +180,20 @@ failure:
>> > return -1;
>> > }
>> >
>> > +void ra_restart(void)
>> > +{
>> > + const int rs_attempt_old = rs_attempt;
>> > +
>> > + odhcp6c_clear_state(STATE_RA_PREFIX);
>> > + odhcp6c_clear_state(STATE_RA_ROUTE);
>> > + odhcp6c_clear_state(STATE_RA_DNS);
>> > + odhcp6c_clear_state(STATE_RA_SEARCH);
>> > +
>> > + rs_attempt = 0;
>> > + if (rs_attempt_old == 0 || rs_attempt_old >= rs_attempt_limit)
>> > + ra_send_rs(SIGALRM);
>> > +}
>> > +
>> > static void ra_send_rs(int signal __attribute__((unused)))
>> > {
>> > const struct sockaddr_in6 dest = {AF_INET6, 0, 0,
>> > ALL_IPV6_ROUTERS, if_index};
>> > @@ -193,7 +208,7 @@ static void ra_send_rs(int signal
>> > __attribute__((unused)))
>> > if (sendto(sock, , len, MSG_DONTWAIT, (struct sockaddr*),
>> > sizeof(dest)) < 0)
>> > syslog(LOG_ERR, "Failed to send RS (%s)",
>> > strerror(errno));
>> >
>> > - if (++rs_attempt <= 3)
>> > + if (++rs_attempt < rs_attempt_limit)
>> > alarm(4);
>> > }
>> >
>> > @@ -243,8 +258,7 @@ bool ra_link_up(void)
>> > if (ret) {
>> > syslog(LOG_NOTICE, "carrier => %i event on %s",
>> > (int)!nocarrier, if_name);
>> >
>> > - rs_attempt = 0;
>> > - ra_send_rs(SIGALRM);
>> > + ra_restart();
>> > }
>> >
>> > return ret;
>> > diff --git a/src/ra.h b/src/ra.h
>> > index 9acc8cd..4ec208f 100644
>> > --- a/src/ra.h
>> > +++ b/src/ra.h
>> >
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
Lorenzo, I have tested dynack on a (real distance apart) ~60km link
with some success. This is the code change made:
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -20,8 +20,9 @@
#define COMPUTE_TO (5 * HZ)
#define LATEACK_DELAY (10 * HZ)
-#define LATEACK_TO 256
-#define MAX_DELAY 300
+#define LATEACK_TO 1054
+/* AREDN max distance set to 150km */
+#define MAX_DELAY 1054
#define EWMA_LEVEL 96
#define EWMA_DIV 128
@@ -293,7 +294,8 @@
void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
{
/* ackto = slottime + sifs + air delay */
- u32 ackto = 9 + 16 + 64;
+ /* AREDN starting point is 20km */
+ u32 ackto = 9 + 16 + 171;
struct ath_dynack *da = >dynack;
an->ackto = ackto;
@@ -328,7 +330,8 @@
void ath_dynack_reset(struct ath_hw *ah)
{
/* ackto = slottime + sifs + air delay */
- u32 ackto = 9 + 16 + 64;
+ /* AREDN starting point is 20km */
+ u32 ackto = 9 + 16 + 171;
struct ath_dynack *da = >dynack;
da->lto = jiffies;
Notes:
1) The stations are showing ack_to between 525 up to 575 A. When
static set at 60k distance, the timeout is set to 460 S.
2) significant performance improvement between these settings with
iperf3 and back to back runs with reboot in the middle:
run 1 @ static 60km:
[ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec0 sender
[ 5] 0.00-10.08 sec 7.16 MBytes 5.95 Mbits/sec receiver
run 2 @ static 60km:
[ 5] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec0 sender
[ 5] 0.00-10.04 sec 5.77 MBytes 4.81 Mbits/sec receiver
run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
floats back to ~525 otherwise:
[ 5] 0.00-10.00 sec 20.0 MBytes 16.8 Mbits/sec0 sender
[ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec receiver
[ 5] 0.00-10.00 sec 21.4 MBytes 18.0 Mbits/sec0 sender
[ 5] 0.00-10.04 sec 21.2 MBytes 17.7 Mbits/sec receiver
3) running wpa_supplicant and psk2
4) running ibss on ch 176 with AREDN channels on top of 18.06.2
5) on one reboot, one of the stations stayed down at initial 196, then
bumped up to ~250 range and stayed there, link not functional. Not
sure how to explain this value...
Question, can this condition be true periodically while the link is
live or only at initial 802.11 adhoc link setup?:
if (ieee80211_is_assoc_req(hdr->frame_control) ||
ieee80211_is_assoc_resp(hdr->frame_control) ||
ieee80211_is_auth(hdr->frame_control)) {
6) Auto distance stayed at initial 196 when turning off encryption.
Any ideas of alternative options of packets to key off in late ack
situation? running wpad-mini is ~500k file size and RAM consumer.
It would be beneficial to take wpa_supplicant out of the equation if
at all possible.
Joe
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
