Re: [OpenWrt-Devel] [PATCH] odhcpd: add network dependent start trigger
Hi,
On Sun, Feb 24, 2019 at 7:06 AM Eric Luehrsen wrote:
>
> Recent (20190207) changes to odhcpd makee it dependent on OpenWrt
> logical interfaces. Boot time race conditions may make odhcpd binding
Even before the most recent changes odhcpd was dependent on OpenWRT logical
interfaces nothing has changed in that sense
> a challenge. Intermittent or inconsistent problems can occur with DHCP
> requests until odhcpd is restarted. Change start up scripts to use
Can you elaborate a bit more on what issues you're observing and provide odhcpd
tracing (loglevel 7) when you observe issues ?
> procd interface triggers such as dnsmasq and others have already.
This does not really make sense to me as odhcpd is subscribed to ubus
network event
messages triggering config reload logic in case the network state of
an interface changes
Hans
>
> Signed-off-by: Eric Luehrsen
> ---
> .../network/services/odhcpd/files/odhcpd.init | 20 +--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> --- a/package/network/services/odhcpd/files/odhcpd.init
> +++ b/package/network/services/odhcpd/files/odhcpd.init
> @@ -1,10 +1,20 @@
> #!/bin/sh /etc/rc.common
>
> -START=35
> +START=19
> STOP=85
> USE_PROCD=1
>
> +boot() {
> + ODHCPD_BOOT=1
> + start "$@"
> +}
> +
> start_service() {
> + if [ -n "$ODHCPD_BOOT" ] ; then
> + # odhcpd needs to wait for OpenWrt logical interfaces
> + return 0
> + fi
> +
> procd_open_instance
> procd_set_param command /usr/sbin/odhcpd
> procd_set_param respawn
> @@ -17,6 +27,12 @@ reload_service() {
>
> service_triggers()
> {
> - procd_add_reload_trigger "dhcp"
> + if [ -n "$ODHCPD_BOOT" ] ; then
> + # one time trigger at boot to wait for logical interface setup
> + procd_add_raw_trigger "interface.*.up" 3000
> /etc/init.d/odhcpd restart
> + else
> + # reload odhcpd also for network reconfiguration
> + procd_add_reload_trigger "dhcp" "network"
> + fi
> }
>
> --
> 2.20.1
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part
On Monday, 25 February 2019 02:24:56 CET Gui Iribarren wrote: > have you considered, to simplify backwards compatibility, to keep proto > "batadv" as it currently is (hardif) and naming "batadv_mesh" the new proto? It was one of the goals to *not* name the batadv hardif interface proto "batadv". And I wanted to have the batman-adv interface proto named "batadv" because this is the rtnl kind string. So you actually create batman-adv meshifs using: ip link add dev bat0 type batadv But we can call this proto also "batadv_meshif" if there is a strong preference for this name. Kind regards, Sven signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part
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 --- agree on the current mess, and congratulations on working on it :) have you considered, to simplify backwards compatibility, to keep proto "batadv" as it currently is (hardif) and naming "batadv_mesh" the new proto? Am 24. Februar 2019 13:51:13 GMT-03:00 schrieb Sven Eckelmann : >batman-adv allows to configure three different objects: > >* batadv hardif > > - network interface used by batadv meshif to transport the batman-adv >packets > - its master interface is set to the batadv meshif > >* batadv (meshif/softif) > > - virtual interface that emulates a normal 802.3 interface on top > - encapsulates traffic and forwards it via the batadv hardifs > >* batadv vlan > > - potential VLAN ID on top of batadv meshif > - allows filtering of traffic from specific VIDs > >While batadv vlan objects were already represented as an own proto >"batadv_vlan", the batadv meshif could never be fully configured using >/etc/config/network. Instead, parts of its configuration were stored in >/etc/config/batman_adv and some in the interfaces with the "batadv" >proto. > >To increase the confusion, the "batadv" proto wasn't used to define the >batadv meshif but to identify batadv (slave) hardifs. The batman-adv >meshifs were also never created directly but only when a hardif was >configured. The actual modification of the configuration settings was >then >applied using a hotplug script hack. The batadv meshif network >interface >could therefore only be created when an hardif was available and not >manipulated with ifup/ifdown. Also `/etc/init.d/network reload` didn't >modify the batadv meshif interface configuration correctly. > >The "batadv" is now renamed to "batadv_hardif" and a new "batadv" proto >is >used to configure the main (meshif) network interface with all its >configuration. > >A simple network configuration with WiFi & ethernet interfaces and >static >IP on top of bat0 would look like: > > # batadv meshif bat0 > config interface 'bat0' > option proto 'batadv' > option routing_algo 'BATMAN_IV' > option aggregated_ogms 1 > option ap_isolation 0 > option bonding 0 > option fragmentation 1 > #option gw_bandwidth '1/2000' > option gw_mode 'off' > #option gw_sel_class 20 > option log_level 0 > option orig_interval 1000 > option bridge_loop_avoidance 1 > option distributed_arp_table 1 > option multicast_mode 1 > option network_coding 0 > option hop_penalty 30 > option isolation_mark '0x/0x' > ># add *single* wifi-iface with network bat0_hardif_wlan as hardif to >bat0 > config interface 'bat0_hardif_wlan' > option mtu '1536' > option proto 'batadv_hardif' > option master 'bat0' > # option ifname is filled out by the wifi-iface > > # add eth0 as hardif to bat0 > config interface 'bat0_hardif_eth0' > option proto 'batadv_hardif' > option master 'bat0' > option ifname 'eth0' > option mtu '1536' > > # configure IP on bat0 > config interface 'bat0_lan' > option ifname 'bat0' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' > >Signed-off-by: Sven Eckelmann >--- >Cc: Matthias Schiffer >Cc: openwrt-devel@lists.openwrt.org >Cc: Gui Iribarren >Cc: Moritz Warning > >Changes depend on https://github.com/openwrt-routing/packages/pull/451 >--- > batman-adv/Makefile | 2 +- > batman-adv/files/etc/config/batman-adv| 20 > .../files/etc/hotplug.d/net/99-batman-adv | 12 -- > .../etc/uci-defaults/99-migrate-batadv_hardif | 97 +++ > batman-adv/files/lib/batman-adv/config.sh | 69 --- > batman-adv/files/lib/netifd/proto/batadv.sh | 112 +++--- > .../files/lib/netifd/proto/batadv_hardif.sh | 40 +++ > 7 files changed, 235 insertions(+), 117 deletions(-) > delete mode 100644 batman-adv/files/etc/config/batman-adv > delete mode 100644 batman-adv/files/etc/hotplug.d/net/99-batman-adv >create mode 100755 >batman-adv/files/etc/uci-defaults/99-migrate-batadv_hardif > delete mode 100644 batman-adv/files/lib/batman-adv/config.sh > create mode 100755 batman-adv/files/lib/netifd/proto/batadv_hardif.sh > >diff --git a/batman-adv/Makefile b/batman-adv/Makefile >index 82af6c7..b250888 100644 >--- a/batman-adv/Makefile >+++ b/batman-adv/Makefile >@@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk > PKG_NAME:=batman-adv > > PKG_VERSION:=2019.0 >-PKG_RELEASE:=2 >+PKG_RELEASE:=3 >PKG_HASH:=3e97d8a771cdbd7b2df42c52b88e071eaa58b5d28eb4e17a4b13b6698debbdc0 > > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz >diff --git
Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions
On 2/24/19 4:21 PM, Andreas Ziegler wrote:
Hi Jeff,
thanks for your suggested change!
Although i agree with your change regarding USB GPIO, i don't with the
other part.
Using stock/vendor firmware, GPIO 12 is a green system/status LED and
GPIO 14 is a red wifi LED.
I just sent a patch to the list which fixes this in ar71xx target, maybe
you can update your patch for ath79, too.
see "[PATCH] ar71xx: GL.iNet AR300M family: correct LED definitions"
Regards
Andreas
Thank you for taking care of the ar71xx target.
I agree that the device has a red LED and have confirmed
with the manufacturer on this. Alas, I'm behind in
updating the patch.
Jeff
Jeff Kletsky schrieb am 28.01.19 um 03:54:
Resend as per M. Kreskin
From f485678e7f37b3f2995fefc1e7c41794091bd73e Mon Sep 17 00:00:00 2001
From: Jeff Kletsky
Date: Sun, 20 Jan 2019 14:48:09 -0800
Subject: [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED
definitions
Change the "status" LED to proper GPIO 12 and "red" naming.
Remove GPIO 2 from definition as a USB LED.
GPIO 2 is used to control power to the USB socket, not an LED.
As such, PWM on the line or typical LED triggers are inappropriate.
Users who wish to control the USB power for custom applications
can manipulate the GPIO through code, or for example, export it
through /sys/class/gpio/export.
Runtime-tested: GL.iNet AR300M-Lite
Signed-off-by: Jeff Kletsky
---
target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
index 2a0c4385cd..9baa6235b2 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
@@ -41,13 +41,6 @@
leds {
compatible = "gpio-leds";
- usb {
- label = "gl-ar300m:green:usb";
- gpios = < 2 GPIO_ACTIVE_LOW>;
- trigger-sources = <_port>;
- linux,default-trigger = "usbport";
- };
-
wlan {
label = "gl-ar300m:green:wlan";
gpios = < 14 GPIO_ACTIVE_LOW>;
@@ -60,8 +53,8 @@
};
led_status: status {
- label = "gl-ar300m:green:status";
- gpios = < 3 GPIO_ACTIVE_LOW>;
+ label = "gl-ar300m:red:status";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
};
};
};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions
Hi Jeff,
thanks for your suggested change!
Although i agree with your change regarding USB GPIO, i don't with the
other part.
Using stock/vendor firmware, GPIO 12 is a green system/status LED and
GPIO 14 is a red wifi LED.
I just sent a patch to the list which fixes this in ar71xx target, maybe
you can update your patch for ath79, too.
see "[PATCH] ar71xx: GL.iNet AR300M family: correct LED definitions"
Regards
Andreas
Jeff Kletsky schrieb am 28.01.19 um 03:54:
> Resend as per M. Kreskin
>
>
> From f485678e7f37b3f2995fefc1e7c41794091bd73e Mon Sep 17 00:00:00 2001
> From: Jeff Kletsky
> Date: Sun, 20 Jan 2019 14:48:09 -0800
> Subject: [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED
> definitions
>
> Change the "status" LED to proper GPIO 12 and "red" naming.
>
> Remove GPIO 2 from definition as a USB LED.
>
> GPIO 2 is used to control power to the USB socket, not an LED.
> As such, PWM on the line or typical LED triggers are inappropriate.
> Users who wish to control the USB power for custom applications
> can manipulate the GPIO through code, or for example, export it
> through /sys/class/gpio/export.
>
> Runtime-tested: GL.iNet AR300M-Lite
>
> Signed-off-by: Jeff Kletsky
> ---
> target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
> b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
> index 2a0c4385cd..9baa6235b2 100644
> --- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
> +++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
> @@ -41,13 +41,6 @@
> leds {
> compatible = "gpio-leds";
>
> - usb {
> - label = "gl-ar300m:green:usb";
> - gpios = < 2 GPIO_ACTIVE_LOW>;
> - trigger-sources = <_port>;
> - linux,default-trigger = "usbport";
> - };
> -
> wlan {
> label = "gl-ar300m:green:wlan";
> gpios = < 14 GPIO_ACTIVE_LOW>;
> @@ -60,8 +53,8 @@
> };
>
> led_status: status {
> - label = "gl-ar300m:green:status";
> - gpios = < 3 GPIO_ACTIVE_LOW>;
> + label = "gl-ar300m:red:status";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> };
> };
> };
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: GL.iNet AR300M family: correct LED definitions
remove USB as this is no LED but power control
rename WiFi LED with correct color red (like in stock firmware)
set middle LED to be used for LAN link/activity
Signed-off-by: Andreas Ziegler
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 1 +
.../linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c | 9 +
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 170adaa7a2..183495e57f 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -412,6 +412,7 @@ fritz450e)
;;
gl-ar300m)
ucidef_set_led_wlan "wlan" "WLAN" "$board:red:wlan" "phy0tpt"
+ ucidef_set_led_netdev "lan" "LAN" "$board:green:lan" "eth1"
;;
gl-ar750)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:white:wlan2g" "phy1tpt"
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c
index 2a2d2702bc..d10a910129 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c
@@ -29,7 +29,6 @@
#include "machtypes.h"
#include "pci.h"
-#define GL_AR300M_GPIO_LED_USB 2
#define GL_AR300M_GPIO_LED_WLAN14
#define GL_AR300M_GPIO_LED_LAN 13
#define GL_AR300M_GPIO_LED_SYSTEM 12
@@ -47,13 +46,7 @@
static struct gpio_led gl_ar300m_leds_gpio[] __initdata = {
{
- .name = "gl-ar300m:green:usb",
- .gpio = GL_AR300M_GPIO_LED_USB,
- .active_low = 0,
- .default_state = 1,
- },
- {
- .name = "gl-ar300m:green:wlan",
+ .name = "gl-ar300m:red:wlan",
.gpio = GL_AR300M_GPIO_LED_WLAN,
.active_low = 1,
},
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: make TP-Link revision naming consistent
This commit makes the TP-Link hardware-revision naming consistent to
match the one used by the vendor. TP-Link refers to the different
revisions as "vX" not "Version X".
Signed-off-by: David Bauer
---
target/linux/ath79/dts/ar9132_tplink_tl-wr1043nd-v1.dts | 2 +-
target/linux/ath79/dts/qca9533_tplink_tl-wr841-v11.dts | 2 +-
target/linux/ath79/dts/qca9533_tplink_tl-wr841-v9.dts| 2 +-
target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts | 2 +-
target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts | 2 +-
target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v2.dts | 2 +-
target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v3.dts | 2 +-
target/linux/ath79/dts/qca9563_tplink_archer-c2-v3.dts | 2 +-
target/linux/ath79/dts/qca9563_tplink_tl-wr1043nd-v4.dts | 2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/target/linux/ath79/dts/ar9132_tplink_tl-wr1043nd-v1.dts
b/target/linux/ath79/dts/ar9132_tplink_tl-wr1043nd-v1.dts
index 23eba5bb30..f617d89c5b 100644
--- a/target/linux/ath79/dts/ar9132_tplink_tl-wr1043nd-v1.dts
+++ b/target/linux/ath79/dts/ar9132_tplink_tl-wr1043nd-v1.dts
@@ -8,7 +8,7 @@
/ {
compatible = "tplink,tl-wr1043nd-v1", "qca,ar9132";
- model = "TP-Link TL-WR1043ND Version 1";
+ model = "TP-Link TL-WR1043ND v1";
aliases {
led-boot =
diff --git a/target/linux/ath79/dts/qca9533_tplink_tl-wr841-v11.dts
b/target/linux/ath79/dts/qca9533_tplink_tl-wr841-v11.dts
index e451b7d67d..29fca8b3a9 100644
--- a/target/linux/ath79/dts/qca9533_tplink_tl-wr841-v11.dts
+++ b/target/linux/ath79/dts/qca9533_tplink_tl-wr841-v11.dts
@@ -8,7 +8,7 @@
/ {
compatible = "tplink,tl-wr841-v11", "qca,qca9533";
- model = "TP-Link TL-WR841N/ND Version 11";
+ model = "TP-Link TL-WR841N/ND v11";
aliases {
led-boot = _led;
diff --git a/target/linux/ath79/dts/qca9533_tplink_tl-wr841-v9.dts
b/target/linux/ath79/dts/qca9533_tplink_tl-wr841-v9.dts
index ac069eed27..a3284226a0 100644
--- a/target/linux/ath79/dts/qca9533_tplink_tl-wr841-v9.dts
+++ b/target/linux/ath79/dts/qca9533_tplink_tl-wr841-v9.dts
@@ -8,7 +8,7 @@
/ {
compatible = "tplink,tl-wr841-v9", "qca,qca9533";
- model = "TP-Link TL-WR841N/ND Version 9";
+ model = "TP-Link TL-WR841N/ND v9";
aliases {
led-boot = _led;
diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts
b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts
index 7334a6e7ee..c26695d248 100644
--- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts
@@ -8,7 +8,7 @@
/ {
compatible = "tplink,archer-c7-v1", "qca,qca9558";
- model = "TP-Link Archer C7 Version 1";
+ model = "TP-Link Archer C7 v1";
};
_keys {
diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
index f168a17796..afc1b14b8a 100644
--- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
@@ -8,7 +8,7 @@
/ {
compatible = "tplink,archer-c7-v2", "qca,qca9558";
- model = "TP-Link Archer C7 Version 2";
+ model = "TP-Link Archer C7 v2";
};
_keys {
diff --git a/target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v2.dts
b/target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v2.dts
index a2992c10fe..f49f143d14 100644
--- a/target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v2.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v2.dts
@@ -8,5 +8,5 @@
/ {
compatible = "tplink,tl-wr1043nd-v2", "qca,qca9557";
- model = "TP-Link TL-WR1043ND Version 2";
+ model = "TP-Link TL-WR1043ND v2";
};
diff --git a/target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v3.dts
b/target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v3.dts
index a473cf42ea..5efa417216 100644
--- a/target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v3.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_tl-wr1043nd-v3.dts
@@ -8,5 +8,5 @@
/ {
compatible = "tplink,tl-wr1043nd-v3", "qca,qca9557";
- model = "TP-Link TL-WR1043ND Version 3";
+ model = "TP-Link TL-WR1043ND v3";
};
diff --git a/target/linux/ath79/dts/qca9563_tplink_archer-c2-v3.dts
b/target/linux/ath79/dts/qca9563_tplink_archer-c2-v3.dts
index 9686290e73..c106a63eb8 100644
--- a/target/linux/ath79/dts/qca9563_tplink_archer-c2-v3.dts
+++ b/target/linux/ath79/dts/qca9563_tplink_archer-c2-v3.dts
@@ -8,7 +8,7 @@
/ {
compatible = "tplink,archer-c2-v3", "qca,qca9563";
- model = "TP-Link Archer C2 Version 3";
+ model = "TP-Link Archer C2 v3";
chosen {
bootargs = "console=ttyS0,115200n8";
diff --git a/target/linux/ath79/dts/qca9563_tplink_tl-wr1043nd-v4.dts
b/target/linux/ath79/dts/qca9563_tplink_tl-wr1043nd-v4.dts
index 5a4c4e588e..e51bb7f834 100644
---
[OpenWrt-Devel] ath9k: fix dynack in IBSS mode
First of all, thanks for contributing this fix. I've incorporated into the http://www.arednmesh.org project, just getting into our nightly builds now. A comment and a couple questions... The MAX_DELAY was way too short for our community, had to increase that significantly. We commonly have long distance links over 50km. One of our common scenarios is a P2MP -- tower or cell site with multiple clients. We're using adhoc mode with OLSR. I see the ack_to calculation is based on the furthest station. What happens when the furthest station is quiet for long periods of time, nothing but beacons and olsr 'broadcast' traffic. In this case, there wouldn't be any acks received back? Would it drop out of the ack_to calculation, until user data is active? Thus, distance would tune to a shorter distance for another STA with user data being transferred? What is the behavior in this scenario? I made a small change so that '0' in /etc/config/wireless distance setting ended up being auto for ath9k. Did I miss an upstream patch to incorporate? Regards, Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [sdwalker/sdwalker.github.io] cdf1fd: This week's update
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: cdf1fd80183e56db9d5ccabdaa35f9aa449846a6 https://github.com/sdwalker/sdwalker.github.io/commit/cdf1fd80183e56db9d5ccabdaa35f9aa449846a6 Author: Stephen Walker Date: 2019-02-24 (Sun, 24 Feb 2019) Changed paths: M uscan/index-18.06.html M uscan/index.html Log Message: --- This week's update ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part
batman-adv allows to configure three different objects: * batadv hardif - network interface used by batadv meshif to transport the batman-adv packets - its master interface is set to the batadv meshif * batadv (meshif/softif) - virtual interface that emulates a normal 802.3 interface on top - encapsulates traffic and forwards it via the batadv hardifs * batadv vlan - potential VLAN ID on top of batadv meshif - allows filtering of traffic from specific VIDs While batadv vlan objects were already represented as an own proto "batadv_vlan", the batadv meshif could never be fully configured using /etc/config/network. Instead, parts of its configuration were stored in /etc/config/batman_adv and some in the interfaces with the "batadv" proto. To increase the confusion, the "batadv" proto wasn't used to define the batadv meshif but to identify batadv (slave) hardifs. The batman-adv meshifs were also never created directly but only when a hardif was configured. The actual modification of the configuration settings was then applied using a hotplug script hack. The batadv meshif network interface could therefore only be created when an hardif was available and not manipulated with ifup/ifdown. Also `/etc/init.d/network reload` didn't modify the batadv meshif interface configuration correctly. The "batadv" is now renamed to "batadv_hardif" and a new "batadv" proto is used to configure the main (meshif) network interface with all its configuration. A simple network configuration with WiFi & ethernet interfaces and static IP on top of bat0 would look like: # batadv meshif bat0 config interface 'bat0' option proto 'batadv' option routing_algo 'BATMAN_IV' option aggregated_ogms 1 option ap_isolation 0 option bonding 0 option fragmentation 1 #option gw_bandwidth '1/2000' option gw_mode 'off' #option gw_sel_class 20 option log_level 0 option orig_interval 1000 option bridge_loop_avoidance 1 option distributed_arp_table 1 option multicast_mode 1 option network_coding 0 option hop_penalty 30 option isolation_mark '0x/0x' # add *single* wifi-iface with network bat0_hardif_wlan as hardif to bat0 config interface 'bat0_hardif_wlan' option mtu '1536' option proto 'batadv_hardif' option master 'bat0' # option ifname is filled out by the wifi-iface # add eth0 as hardif to bat0 config interface 'bat0_hardif_eth0' option proto 'batadv_hardif' option master 'bat0' option ifname 'eth0' option mtu '1536' # configure IP on bat0 config interface 'bat0_lan' option ifname 'bat0' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' Signed-off-by: Sven Eckelmann --- Cc: Matthias Schiffer Cc: openwrt-devel@lists.openwrt.org Cc: Gui Iribarren Cc: Moritz Warning Changes depend on https://github.com/openwrt-routing/packages/pull/451 --- batman-adv/Makefile | 2 +- batman-adv/files/etc/config/batman-adv| 20 .../files/etc/hotplug.d/net/99-batman-adv | 12 -- .../etc/uci-defaults/99-migrate-batadv_hardif | 97 +++ batman-adv/files/lib/batman-adv/config.sh | 69 --- batman-adv/files/lib/netifd/proto/batadv.sh | 112 +++--- .../files/lib/netifd/proto/batadv_hardif.sh | 40 +++ 7 files changed, 235 insertions(+), 117 deletions(-) delete mode 100644 batman-adv/files/etc/config/batman-adv delete mode 100644 batman-adv/files/etc/hotplug.d/net/99-batman-adv create mode 100755 batman-adv/files/etc/uci-defaults/99-migrate-batadv_hardif delete mode 100644 batman-adv/files/lib/batman-adv/config.sh create mode 100755 batman-adv/files/lib/netifd/proto/batadv_hardif.sh diff --git a/batman-adv/Makefile b/batman-adv/Makefile index 82af6c7..b250888 100644 --- a/batman-adv/Makefile +++ b/batman-adv/Makefile @@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=batman-adv PKG_VERSION:=2019.0 -PKG_RELEASE:=2 +PKG_RELEASE:=3 PKG_HASH:=3e97d8a771cdbd7b2df42c52b88e071eaa58b5d28eb4e17a4b13b6698debbdc0 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz diff --git a/batman-adv/files/etc/config/batman-adv b/batman-adv/files/etc/config/batman-adv deleted file mode 100644 index 21138cb..000 --- a/batman-adv/files/etc/config/batman-adv +++ /dev/null @@ -1,20 +0,0 @@ - -config 'mesh' 'bat0' - #option 'aggregated_ogms' 1 - #option 'ap_isolation' 0 - #option 'bonding' 0 - #option 'fragmentation' 1 - #option 'gw_bandwidth' '1/2000' - #option 'gw_mode' 'off' - #option 'gw_sel_class' 20 - #option 'log_level' 0 - #option 'orig_interval' 1000 - #option 'bridge_loop_avoidance' 1 - #option 'distributed_arp_table' 1 - #option 'multicast_mode' 1 -
[OpenWrt-Devel] [PATCH] mac80211: rt2x00: fix crash on release_firmware
Fix crash due to passing invalid r2x00dev->eeprom_file pointer to
release_firmware(). Since we copy eeprom data with EEPROM_SIZE
in rt2800_read_eeprom() we can use eeprom_file->size as marker
if the file was crated by request_firmware().
Cc: Felix Fietkau ,
Cc: Daniel Golle
Signed-off-by: Stanislaw Gruszka
---
.../mac80211/patches/rt2x00/602-rt2x00-introduce-rt2x00eeprom.patch | 5 +++--
.../604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch | 5 ++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git
a/package/kernel/mac80211/patches/rt2x00/602-rt2x00-introduce-rt2x00eeprom.patch
b/package/kernel/mac80211/patches/rt2x00/602-rt2x00-introduce-rt2x00eeprom.patch
index ab31d8485d7d..c6d4862e41ec 100644
---
a/package/kernel/mac80211/patches/rt2x00/602-rt2x00-introduce-rt2x00eeprom.patch
+++
b/package/kernel/mac80211/patches/rt2x00/602-rt2x00-introduce-rt2x00eeprom.patch
@@ -152,7 +152,7 @@
--- /dev/null
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00eeprom.c
-@@ -0,0 +1,105 @@
+@@ -0,0 +1,106 @@
+/*
+ Copyright (C) 2004 - 2009 Ivo van Doorn
+ Copyright (C) 2004 - 2009 Gertjan van Wingerde
@@ -255,7 +255,8 @@
+
+void rt2x00lib_free_eeprom_file(struct rt2x00_dev *rt2x00dev)
+{
-+ release_firmware(rt2x00dev->eeprom_file);
++ if (rt2x00dev->eeprom_file && rt2x00dev->eeprom_file->size)
++ release_firmware(rt2x00dev->eeprom_file);
+ rt2x00dev->eeprom_file = NULL;
+}
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00lib.h
diff --git
a/package/kernel/mac80211/patches/rt2x00/604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
b/package/kernel/mac80211/patches/rt2x00/604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
index a98b49c541f5..b3e1220b601a 100644
---
a/package/kernel/mac80211/patches/rt2x00/604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
+++
b/package/kernel/mac80211/patches/rt2x00/604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
@@ -22,7 +22,7 @@ Signed-off-by: John Crispin
Supported chips: RT2880, RT3050, RT3052, RT3350, RT3352.
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00eeprom.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00eeprom.c
-@@ -26,11 +26,73 @@
+@@ -26,11 +26,72 @@
#include
#include
@@ -84,7 +84,6 @@ Signed-off-by: John Crispin
+ rt2x00dev->eeprom[i] = swab16(rt2x00dev->eeprom[i]);
+
+ rt2x00dev->eeprom_file = _fw;
-+ mtd_fw.size = len;
+ mtd_fw.data = (const u8 *) rt2x00dev->eeprom;
+
+ dev_info(rt2x00dev->dev, "loaded eeprom from mtd device \"%s\"\n",
part);
@@ -96,7 +95,7 @@ Signed-off-by: John Crispin
static const char *
rt2x00lib_get_eeprom_file_name(struct rt2x00_dev *rt2x00dev)
{
-@@ -58,6 +120,9 @@ static int rt2x00lib_request_eeprom_file
+@@ -58,6 +119,9 @@ static int rt2x00lib_request_eeprom_file
const char *ee_name;
int retval;
--
2.7.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
