date:20150527

[OpenWrt-Devel] [PATCHv2] ralink: add support for mt7621 switch counters

2015-05-27 Thread Cristian Morales Vega

Signed-off-by: Cristian Morales Vega 
---
 .../files/drivers/net/ethernet/ralink/mt7530.c | 194 -
 1 file changed, 191 insertions(+), 3 deletions(-)

diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c 
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
index 1352b25..b4b74d4 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
@@ -63,6 +63,107 @@ enum {
 
 #define REG_HWTRAP 0x7804
 
+#define MIB_DESC(_s , _o, _n)   \
+   {   \
+   .size = (_s),   \
+   .offset = (_o), \
+   .name = (_n),   \
+   }
+
+struct mt7xxx_mib_desc {
+   unsigned int size;
+   unsigned int offset;
+   const char *name;
+};
+
+#define MT7621_MIB_COUNTER_BASE0x4000
+#define MT7621_MIB_COUNTER_PORT_OFFSET 0x100
+#define MT7621_STATS_TDPC  0x00
+#define MT7621_STATS_TCRC  0x04
+#define MT7621_STATS_TUPC  0x08
+#define MT7621_STATS_TMPC  0x0C
+#define MT7621_STATS_TBPC  0x10
+#define MT7621_STATS_TCEC  0x14
+#define MT7621_STATS_TSCEC 0x18
+#define MT7621_STATS_TMCEC 0x1C
+#define MT7621_STATS_TDEC  0x20
+#define MT7621_STATS_TLCEC 0x24
+#define MT7621_STATS_TXCEC 0x28
+#define MT7621_STATS_TPPC  0x2C
+#define MT7621_STATS_TL64PC0x30
+#define MT7621_STATS_TL65PC0x34
+#define MT7621_STATS_TL128PC   0x38
+#define MT7621_STATS_TL256PC   0x3C
+#define MT7621_STATS_TL512PC   0x40
+#define MT7621_STATS_TL1024PC  0x44
+#define MT7621_STATS_TOC   0x48
+#define MT7621_STATS_RDPC  0x60
+#define MT7621_STATS_RFPC  0x64
+#define MT7621_STATS_RUPC  0x68
+#define MT7621_STATS_RMPC  0x6C
+#define MT7621_STATS_RBPC  0x70
+#define MT7621_STATS_RAEPC 0x74
+#define MT7621_STATS_RCEPC 0x78
+#define MT7621_STATS_RUSPC 0x7C
+#define MT7621_STATS_RFEPC 0x80
+#define MT7621_STATS_ROSPC 0x84
+#define MT7621_STATS_RJEPC 0x88
+#define MT7621_STATS_RPPC  0x8C
+#define MT7621_STATS_RL64PC0x90
+#define MT7621_STATS_RL65PC0x94
+#define MT7621_STATS_RL128PC   0x98
+#define MT7621_STATS_RL256PC   0x9C
+#define MT7621_STATS_RL512PC   0xA0
+#define MT7621_STATS_RL1024PC  0xA4
+#define MT7621_STATS_ROC   0xA8
+#define MT7621_STATS_RDPC_CTRL 0xB0
+#define MT7621_STATS_RDPC_ING  0xB4
+#define MT7621_STATS_RDPC_ARL  0xB8
+
+static const struct mt7xxx_mib_desc mt7621_mibs[] = {
+   MIB_DESC(1, MT7621_STATS_TDPC, "TxDrop"),
+   MIB_DESC(1, MT7621_STATS_TCRC, "TxCRC"),
+   MIB_DESC(1, MT7621_STATS_TUPC, "TxUni"),
+   MIB_DESC(1, MT7621_STATS_TMPC, "TxMulti"),
+   MIB_DESC(1, MT7621_STATS_TBPC, "TxBroad"),
+   MIB_DESC(1, MT7621_STATS_TCEC, "TxCollision"),
+   MIB_DESC(1, MT7621_STATS_TSCEC, "TxSingleCol"),
+   MIB_DESC(1, MT7621_STATS_TMCEC, "TxMultiCol"),
+   MIB_DESC(1, MT7621_STATS_TDEC, "TxDefer"),
+   MIB_DESC(1, MT7621_STATS_TLCEC, "TxLateCol"),
+   MIB_DESC(1, MT7621_STATS_TXCEC, "TxExcCol"),
+   MIB_DESC(1, MT7621_STATS_TPPC, "TxPause"),
+   MIB_DESC(1, MT7621_STATS_TL64PC, "Tx64Byte"),
+   MIB_DESC(1, MT7621_STATS_TL65PC, "Tx65Byte"),
+   MIB_DESC(1, MT7621_STATS_TL128PC, "Tx128Byte"),
+   MIB_DESC(1, MT7621_STATS_TL256PC, "Tx256Byte"),
+   MIB_DESC(1, MT7621_STATS_TL512PC, "Tx512Byte"),
+   MIB_DESC(1, MT7621_STATS_TL1024PC, "Tx1024Byte"),
+   MIB_DESC(2, MT7621_STATS_TOC, "TxByte"),
+   MIB_DESC(1, MT7621_STATS_RDPC, "RxDrop"),
+   MIB_DESC(1, MT7621_STATS_RFPC, "RxFiltered"),
+   MIB_DESC(1, MT7621_STATS_RUPC, "RxUni"),
+   MIB_DESC(1, MT7621_STATS_RMPC, "RxMulti"),
+   MIB_DESC(1, MT7621_STATS_RBPC, "RxBroad"),
+   MIB_DESC(1, MT7621_STATS_RAEPC, "RxAlignErr"),
+   MIB_DESC(1, MT7621_STATS_RCEPC, "RxCRC"),
+   MIB_DESC(1, MT7621_STATS_RUSPC, "RxUnderSize"),
+   MIB_DESC(1, MT7621_STATS_RFEPC, "RxFragment"),
+   MIB_DESC(1, MT7621_STATS_ROSPC, "RxOverSize"),
+   MIB_DESC(1, MT7621_STATS_RJEPC, "RxJabber"),
+   MIB_DESC(1, MT7621_STATS_RPPC, "RxPause"),
+   MIB_DESC(1, MT7621_STATS_RL64PC, "Rx64Byte"),
+   MIB_DESC(1, MT7621_STATS_RL65PC, "Rx65Byte"),
+   MIB_DESC(1, MT7621_STATS_RL128PC, "Rx128Byte"),
+   MIB_DESC(1, MT7621_STATS_RL256PC, "Rx256Byte"),
+   MIB_DESC(1, MT7621_STATS_RL512PC, "Rx512Byte"),
+   MIB_DESC(1, MT7621_STATS_RL1024PC, "Rx1024Byte"),
+   MIB_DESC(2, MT7621_STATS_ROC, "RxByte"),
+   MIB_DESC(1, MT7621_STATS_RDPC_CTRL, "RxCtrlDrop"),
+   MIB_DESC(1, MT7621_STATS_RDPC_ING, "RxIngDrop"),
+   MIB_DESC(1, MT7621_STATS_RDPC_ARL, "RxARLDrop")
+};
+
 enum {
/* Global attributes. */
MT7530_ATTR_ENABLE_VLAN,
@@ -500,6 +601,63 @@ static const struct switch_attr mt7530_global[] = {
},
 };
 
+static u64 get_mib_counter(struct mt7530_priv *priv, int i, int port)
+{
+   unsigned int port_base;
+   u64

[OpenWrt-Devel] [PATCH] sysctl: read settings from /etc/sysctl.d/*.conf

2015-05-27 Thread Stefan Tomanek

This changes makes it possible to store custom settings
in individual files inside the directory /etc/sysctl.d/,
which take precedence over /etc/sysctl.conf.

Signed-off-by: Stefan Tomanek 
---
 package/base-files/files/etc/init.d/sysctl |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/package/base-files/files/etc/init.d/sysctl 
b/package/base-files/files/etc/init.d/sysctl
index 36e29ea..2dfbaf7 100755
--- a/package/base-files/files/etc/init.d/sysctl
+++ b/package/base-files/files/etc/init.d/sysctl
@@ -3,5 +3,7 @@
 
 START=11
 start() {
-   [ -f /etc/sysctl.conf ] && sysctl -p -e >&-
+   for CONF in /etc/sysctl.conf /etc/sysctl.d/*.conf; do
+   [ -f "$CONF" ] && sysctl -p "$CONF" -e >&-
+   done
 }
-- 
1.7.2.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] scripts/feeds: print the source of packages installed

2015-05-27 Thread Karl Palsson

From: Karl Palsson 

Can be helpful in diagnosing unexpected package overlaps between
feeds/core.

Signed-off-by: Karl Palsson 
---

Changes since v1: Include feed source for override case as well, as suggested
by Mathieu Olivari

 scripts/feeds | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/feeds b/scripts/feeds
index a6be9cc..4f3f812 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -497,8 +497,8 @@ sub install_package {
$installed{$src} = 1;
 
defined($override) and $override == 1
-   and warn "Overriding package '$src'\n"
-   or warn "Installing package '$src'\n";
+   and warn "Overriding core package '$src' with version from 
$feed->[1]\n"
+   or warn "Installing package '$src' from $feed->[1]\n";
 
do_install_package($feed, $pkg) == 0 or do {
warn "failed.\n";
-- 
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus

2015-05-27 Thread Kirill Berezin


Hi,

Well, this was my bad )) I accidentally chose cpu's gpio and realised 
that this is a mistake yesterday night.


So I made a patch for atheros driver and it works. A signal level on 
different frequencies is more or less equal and seems adequate (about 
-30 dbm if a client within a meter from ap).


The patch for bb 14.07 is in the attachment. It should be placed in 
package/kernel/mac80211/patches . The code generates a lot of messages, 
so it'll be easy to track what happens.



Kirill

On 05/26/2015 11:25 PM, Stefan Rompf wrote:


Until I found that I was accessing GPIO lines of the CPU (cat
/sys/devices/virtual/gpio/gpiochip0/label => ath79), not of the 928x wifi
chip. It seems that ath9k does not even export its pins to the GPIO subsystem.

Stefan



diff -urN old/drivers/net/wireless/ath/ath9k/hsr.c new/drivers/net/wireless/ath/ath9k/hsr.c
--- old/drivers/net/wireless/ath/ath9k/hsr.c	1970-01-01 03:00:00.0 +0300
+++ new/drivers/net/wireless/ath/ath9k/hsr.c	2015-05-27 12:47:43.0 +0300
@@ -0,0 +1,236 @@
+/*
+ *
+ * The MIT License (MIT)
+ *
+ * Copyright (c) 2015 Kirill Berezin
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in all
+ * copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hw.h"
+#include "hw-ops.h"
+#include "ar9003_mac.h"
+#include "ar9003_mci.h"
+#include "ar9003_phy.h"
+#include "ath9k.h"
+
+#include "hsr.h"
+
+void hsr_init(struct ath_hw* ah) {
+
+	if ( NULL == ah) {
+		return;
+	}
+
+	ath9k_hw_cfg_gpio_input(ah, HSR_GPIO_DIN);
+	ath9k_hw_cfg_output(ah, HSR_GPIO_CSN, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
+	ath9k_hw_cfg_output(ah, HSR_GPIO_CLK, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
+	ath9k_hw_cfg_output(ah, HSR_GPIO_DOUT, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
+
+	ath9k_hw_set_gpio(ah, HSR_GPIO_CSN, 1);
+	ath9k_hw_set_gpio(ah, HSR_GPIO_CLK, 0);
+	ath9k_hw_set_gpio(ah, HSR_GPIO_DOUT, 0);
+
+	udelay(HSR_DELAY_TRAILING);
+
+	printk(KERN_NOTICE "hsr_init: done");
+
+}
+EXPORT_SYMBOL(hsr_init);
+
+static u32 hsr_write_byte(struct ath_hw* ah, int delay, u32 value){
+	int i;
+	u32 rval = 0;
+
+	udelay(delay);
+
+	ath9k_hw_set_gpio(ah, HSR_GPIO_CLK, 0);
+	udelay(HSR_DELAY_HALF_TICK);
+
+	ath9k_hw_set_gpio(ah, HSR_GPIO_CSN, 0);
+	udelay(HSR_DELAY_HALF_TICK);
+
+	for( i = 0; i < 8; ++i) {
+		rval = rval << 1;
+
+		// pattern is left to right, that is 7-th bit runs first
+		ath9k_hw_set_gpio(ah, HSR_GPIO_DOUT, (value >> (7 - i)) & 0x1);
+		udelay(HSR_DELAY_HALF_TICK);
+
+		ath9k_hw_set_gpio(ah, HSR_GPIO_CLK, 1);
+		udelay(HSR_DELAY_HALF_TICK);
+
+		rval |= ath9k_hw_gpio_get(ah, HSR_GPIO_DIN);
+
+		ath9k_hw_set_gpio(ah, HSR_GPIO_CLK, 0);
+		udelay(HSR_DELAY_HALF_TICK);
+	}
+
+	ath9k_hw_set_gpio(ah, HSR_GPIO_CSN, 1);
+	udelay(HSR_DELAY_HALF_TICK);
+
+printk(KERN_NOTICE "hsr_write_byte: write byte %d return value is %x %d %c \n", value, rval, rval, rval > 32 ? rval : '-');
+   
+	return rval & 0xff;
+}
+
+static int hsr_write_a_chain(struct ath_hw* ah, char* chain, int items) {
+	int i = 0, j;
+	int status = 0;
+	int loops = 0;
+	// a preabmle
+	hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, 0);
+
+	status = hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, 0);
+
+	if ( status) {
+		int loop = 2;
+		++ loops;
+		if ( loops > 42) {
+printk(KERN_NOTICE "hsr_write_a_chain: too many loops in preamble. giving up.\n");
+			return 0;
+		}
+		do {
+			status = hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, 0);
+			loop = (loop + 1) & 0x;
+			if ( loop < 2) {
+continue;
+			} 
+		} while(status);
+	}
+
+for ( i =0; (i < items) && ( 0 != chain[i]); ++i) {
+		hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, (u32)chain[i]);
+	}
+	hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, 0);  
+	udelay(HSR_DELAY_FINAL);
+
+	memset(chain, 0, items);
+
+	for ( j = 0, i = 0; (i < 7) && (j < (items - 1)) ; ++i) { 
+		u32 ret;
+		if ( 31 < (ret = hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, 0))) {
+			chain[j] = (char)ret;
+			++ j;
+		}
+

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Christian Mehlis


Am 26.05.2015 um 22:48 schrieb Richard Clark:

https://dev.openwrt.org/ticket/17674 (set to closed / duplicate) but no
reference

Any thoughts, suggestions, or can someone give me some pointers on where
I can be digging in the openwrt kernel code for where that Ethernet
driver 'link status' get filled in ?

ps.. This all works on a different Atheros generic device (GL-Inet), so
it is TP-Link specific.


Hi Richard,

I had this problem a moth ago with this board:
http://wiki.openwrt.org/toh/compex/wpj344

Ref:
https://lists.openwrt.org/pipermail/openwrt-devel/2015-April/032786.html

I found no solution so far...

Best
Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Karl Palsson


Christian Mehlis  wrote:
> Am 26.05.2015 um 22:48 schrieb Richard Clark:
> > https://dev.openwrt.org/ticket/17674 (set to closed / duplicate) but no
> > reference
> >
> > Any thoughts, suggestions, or can someone give me some pointers on where
> > I can be digging in the openwrt kernel code for where that Ethernet
> > driver 'link status' get filled in ?
> >
> > ps.. This all works on a different Atheros generic device (GL-Inet), so
> > it is TP-Link specific.

You don't happen to have force_link set on the interface in question in
your UCI config do you?

Cheers,
Karl Palsson___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Jo-Philipp Wich

Hi Richard,

the link status is not propagated to the netdev because there's an
external switch chip between the CPU and the RJ45 plug on the outside.

There currently is no mechanism to propagate switch port states to Linux
netdev link states as such an mechanism has various implications.

For example: consider a switch port group containing five ports, 4
external RJ45 ports and one internal connected to the SoC - when would
you consider that interface down? When no port except the CPU one has a
link? Whenever a cable is plugged into one of the four ports?

Strictly speaking the missing link detection on wan is not a bug but by
design because the link between the CPU and the switch is always
established, it never goes down - its just a trace on the PCB.

Currently the WAN port link state detection only works on boards that
have a dedicated phy for their WAN and no intermediate programmable switch.

If you would want to work on that you'd need to propagate the swconfig
link state information to the connected netdev, but that already is a
problem since there is no programmatic way to relate a given netdev to a
switch device (e.g. is it eth0 or eth1 connected to switch0?).

Such information needs to be hardcoded per model, maybe encoded in the
board config code.

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] sysctl: read settings from /etc/sysctl.d/*.conf

2015-05-27 Thread Jonathan Thibault

You might want to adjust the hotplug script too.

On 27/05/15 05:23 AM, Stefan Tomanek wrote:
> This changes makes it possible to store custom settings
> in individual files inside the directory /etc/sysctl.d/,
> which take precedence over /etc/sysctl.conf.
>
> Signed-off-by: Stefan Tomanek 
> ---
>  package/base-files/files/etc/init.d/sysctl |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/package/base-files/files/etc/init.d/sysctl 
> b/package/base-files/files/etc/init.d/sysctl
> index 36e29ea..2dfbaf7 100755
> --- a/package/base-files/files/etc/init.d/sysctl
> +++ b/package/base-files/files/etc/init.d/sysctl
> @@ -3,5 +3,7 @@
>  
>  START=11
>  start() {
> - [ -f /etc/sysctl.conf ] && sysctl -p -e >&-
> + for CONF in /etc/sysctl.conf /etc/sysctl.d/*.conf; do
> + [ -f "$CONF" ] && sysctl -p "$CONF" -e >&-
> + done
>  }
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] zram-swap: set a high priority for the swap

2015-05-27 Thread Bastian Bittorf

* Juan Orti Alcaine  [26.05.2015 07:59]:
> - swapon "$zram_dev"
> + swapon -p 100 "$zram_dev"

please use at least:

swapon -p X $dev || swapon $dev

so it can work even without '-p' option,
which is optional in busybox.

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created

2015-05-27 Thread Bastian Bittorf

This is the case e.g. if JFFS2 partition is full.

see: https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00246.html
runtime tested on ar71xx with kernel 3.18.14 and r45772 (rebased)
this paritially fixes #19564

Signed-off-by: Bastian Bittorf 
---
 ...-overlayfs-fallback-to-readonly-when-full.patch |  109 
 1 file changed, 109 insertions(+)
 create mode 100644 
target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch

diff --git 
a/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
 
b/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
new file mode 100644
index 000..21f11fd
--- /dev/null
+++ 
b/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
@@ -0,0 +1,109 @@
+[linux-unionfs added to Cc]
+
+On Tue, May 19, 2015 at 09:51:20AM +0200, Bastian Bittorf wrote:
+> Hi Miklos,
+>
+> sorry for writing directly to you, feel free to forward
+> this to the appropriate mailinglist.
+>
+> we have a problem with mainline overlay filesystem on kernel 3.18:
+> https://dev.openwrt.org/ticket/19564
+>
+> 2 things are odd:
+> when the working filesystem is full, overlays fails with:
+>
+> overlayfs: failed to create directory /overlay/work/work
+>
+> what is strange, that we call it with:
+>
+> mount(overlay, "/mnt", "overlay", MS_NOATIME, lowerdir)
+>
+> see here:
+> 
http://nbd.name/gitweb.cgi?p=fstools.git;a=blob;f=libfstools/mount.c;h=81176ce399b4cd8e2d347c0008c13dec92407f55;hb=e6004000ff15d7bd32cf5663e8690fc94d7ec747#l125
+>
+> do you have an idea whats wrong?
+> 1) is it really needed, that we need space for creating dir "/overlay/work"?
+> 2) why does overlay need "/overlay/work/work"?
+
+The work directory is needed for atomic copy-up and similar.  It is not 
actually
+necessary to mount a read-only overlay.  Post 4.0 it is possible to mount the
+overlay without workdir (but even then it won't happen automatically in case 
the
+upper fs is full, so this should be fixed in the latest kernel too).
+
+Could you please try the following patch?  If the workdir can't be created it
+will fall back to mounting the overlay read-only.
+
+Thanks,
+Miklos
+
+---
+ fs/overlayfs/copy_up.c |3 +++
+ fs/overlayfs/dir.c |9 +
+ fs/overlayfs/super.c   |   12 +---
+ 3 files changed, 21 insertions(+), 3 deletions(-)
+
+--- a/fs/overlayfs/copy_up.c
 b/fs/overlayfs/copy_up.c
+@@ -300,6 +300,9 @@ int ovl_copy_up_one(struct dentry *paren
+   struct cred *override_cred;
+   char *link = NULL;
+
++  if (WARN_ON(!workdir))
++  return -EROFS;
++
+   ovl_path_upper(parent, &parentpath);
+   upperdir = parentpath.dentry;
+
+--- a/fs/overlayfs/dir.c
 b/fs/overlayfs/dir.c
+@@ -222,6 +222,9 @@ static struct dentry *ovl_clear_empty(st
+   struct kstat stat;
+   int err;
+
++  if (WARN_ON(!workdir))
++  return ERR_PTR(-EROFS);
++
+   err = ovl_lock_rename_workdir(workdir, upperdir);
+   if (err)
+   goto out;
+@@ -322,6 +325,9 @@ static int ovl_create_over_whiteout(stru
+   struct dentry *newdentry;
+   int err;
+
++  if (WARN_ON(!workdir))
++  return -EROFS;
++
+   err = ovl_lock_rename_workdir(workdir, upperdir);
+   if (err)
+   goto out;
+@@ -506,6 +512,9 @@ static int ovl_remove_and_whiteout(struc
+   struct dentry *opaquedir = NULL;
+   int err;
+
++  if (WARN_ON(!workdir))
++  return -EROFS;
++
+   if (is_dir) {
+   opaquedir = ovl_check_empty_and_clear(dentry);
+   err = PTR_ERR(opaquedir);
+--- a/fs/overlayfs/super.c
 b/fs/overlayfs/super.c
+@@ -740,9 +740,15 @@ static int ovl_fill_super(struct super_b
+   ufs->workdir = ovl_workdir_create(ufs->upper_mnt, workpath.dentry);
+   err = PTR_ERR(ufs->workdir);
+   if (IS_ERR(ufs->workdir)) {
+-  pr_err("overlayfs: failed to create directory %s/%s\n",
+- ufs->config.workdir, OVL_WORKDIR_NAME);
+-  goto out_put_lower_mnt;
++  if (err == -ENOSPC || err == -EROFS) {
++  pr_warning("overlayfs: failed to work directory (%s), 
mounting read-only\n", err == ENOSPC ? "ENOSPC" : "EROFS");
++  sb->s_flags |= MS_RDONLY;
++  ufs->workdir = NULL;
++  } else {
++  pr_err("overlayfs: failed to create directory %s/%s\n",
++ ufs->config.workdir, OVL_WORKDIR_NAME);
++  goto out_put_lower_mnt;
++  }
+   }
+
+   /*
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] [PATCH] build: honor command line CONFIG_ variables on kernel_*config targets

2015-05-27 Thread Felix Fietkau

Please don't send HTML mails to the list, further comment below.

On 2015-05-13 15:11, Emmanuel Deloget wrote:
> The CONFIG_* variables are correctly handled when building nearly all
> targets (at least packages and full build) yet they are not honored on 
> kernel_menuconfig and similar targets.
> 
> Some use case :
> 
>   make CONFIG_DOWNLOAD_FOLDER=../dl/ kernel_menuconfig
>   make CONFIG_BUILD_SUFFIX=test kernel_oldconfig
> 
> and so on...
> 
> When used, they generate build errors because the kernel_*config targets
> are not able to find the correct directories.
> 
> Signed-off-by: Emmanuel Deloget  >
> ---
>  include/toplevel.mk  | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/toplevel.mk 
> b/include/toplevel.mk 
> index d8651d9..02e337a 100644
> --- a/include/toplevel.mk 
> +++ b/include/toplevel.mk 
> @@ -128,13 +128,13 @@ else
>  endif
>  
>  kernel_oldconfig: prepare_kernel_conf
> -$(_SINGLE)$(NO_TRACE_MAKE) -C target/linux oldconfig
> +$(_SINGLE)$(NO_TRACE_MAKE) $(filter CONFIG_%,$(MAKEFLAGS)) -C
> target/linux oldconfig
I think this is the wrong approach, filtering only CONFIG_* variables is
overly specific. The issue with this target is that $(_SINGLE) overrides
MAKEFLAGS.
Please try adding -j1 to the make command line, removing $(_SINGLE).

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

Re: [OpenWrt-Devel] [PATCH] scripts/feeds: observe -p flag for preferential feeds

2015-05-27 Thread Felix Fietkau

On 2015-05-26 17:09, Karl Palsson wrote:
> From: Karl Palsson 
> 
> lookup_target was trampling the $feed variable, resulting in the -p flag
> no longer preferentially installing from the named feed.
> 
> Signed-off-by: Karl Palsson 
> ---
>  scripts/feeds | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/feeds b/scripts/feeds
> index a6be9cc..1330425 100755
> --- a/scripts/feeds
> +++ b/scripts/feeds
> @@ -450,10 +450,10 @@ sub install_package {
>   my $force = shift;
>   my $ret = 0;
>  
> - $feed = lookup_target($feed, $name);
> - $feed and do {
> + $feed_target = lookup_target($feed, $name);
Well, with this change it is simply trampling a different (global)
variable, which is not a good idea either. How about making it use a
local variable instead?

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

Re: [OpenWrt-Devel] [PATCH] sunxi: remove kernel symbol

2015-05-27 Thread Felix Fietkau

On 2015-05-27 00:02, Dirk Neukirchen wrote:
> On 24.05.2015 11:15, Felix Fietkau wrote:
>> On 2015-05-24 11:01, Dirk Neukirchen wrote:
>>>
>>> unify config across platforms
>>> RESOURCE_COUNTERS is deactive on all platforms
>>>
>>> Signed-off-by: Dirk Neukirchen 
>>> ---
>> Removing target/subtarget kernel config lines individually does not make
>> any sense. These files are generated by make kernel_menuconfig or make
>> kernel_oldconfig.
>> 
>> - Felix
>> 
> 
> Thanks for clarifying - _but_ if I rerun "make kernel_menuconfig"
> with current trunk I get several big changesets that might break
> some targets if I look at the symbol changes on some of them:
> 
> Example:
> x86 with selected KPROBES in menuconfig needs 
> # CONFIG_X86_DECODER_SELFTEST is not set
> 
> but
> X86_DECODER_SELFTEST is removed from target/x86/config-3.18 with "make 
> kernel_menuconfig"
> but other symbols from arch/x86/Kconfig.debug are kept in that file
> 
> make target/linux/compile : does not work because the missing symbol
> make kernel_oldconfig : does not add or question this symbol 
Adding it to generic/config-* will fix this.

> a patch that has "make kernel_menuconfig" changes
> for all targets (might be missing some subtargets) is available at:
> https://github.com/plntyk/openwrt-patches/blob/master/kernel_refresh/0016-refreshes-according-to-make-kernel_menuconfig.patch
> (from a tree where some changes regarding kernel version/symbols were already 
> applied)
> 
> I did run "make dirclean" before arch switching and a target/linux/clean run 
> before running make kernel_menuconfig.
> 
> I really dont get it where the menuconfig changes are coming from
> Would patching the arch//configs/*defconfig help/be the correct 
> fix?
That should not be necessary.

> The patch that does this sort of thing for brcm2708 looks really bad 
> (patch #023)
Not sure where this delta is coming from or how this config was
generated. This needs to be looked at more closely.
Either way, all target config files should be kept in a way that make
kernel_menuconfig works properly and does not break stuff.

> "Malta"(-LE) maybe needs a defconfig since kernel_menuconfig wants to switch 
> to the big endian variant
Here's one way to resolve this: copy the generated .config from the
kernel tree for each subtarget somewhere. Then refresh the target config
file. Afterwards, go through each subtarget, replace the config-* file
in there with the saved .config, refresh using kernel_oldconfig afterwards.
This should ensure that the change/refresh will not result in any
effective kernel configuration changes.

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

Re: [OpenWrt-Devel] [PATCH] perf: replace libelf1 select by a depend

2015-05-27 Thread Felix Fietkau

On 2015-05-27 02:13, Mathieu Olivari wrote:
> It was not merged; it stayed pending without resolution since then, so I
> figured I’d find an alternative.
Replacing the select by a depend makes the whole process completely
counterintuitive, so NACK from me on that.

Any package we add to trunk needs to have a maintainer. Is moving the
relevant packages to trunk acked by the current package maintainers?

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

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Richard Clark

On 05/27/2015 05:31 AM, Karl Palsson wrote:
> You don't happen to have force_link set on the interface in question in
> your UCI config do you?

No.  It IS set on the LAN interface, but if I am reading the option
correct that is to force a static assignment by netifd even if no link
is detected (make sense for LAN I think).

Tried it anyway by forcing it to 0 on the LAN config (was there by
default install), and also added it to the WAN interface (under DHCP).
No change in handling :(  Since ethtool doesn't even notice the link
change state I think it might be a network driver issue.

Thanks,
Richard
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Richard Clark

On 05/27/2015 03:59 AM, Christian Mehlis wrote:
> Hi Richard,
> 
> I had this problem a moth ago with this board:
> I found no solution so far...
> 
> Christian

For now I have added a little script in the background that just watches
for the link status using swconfig

swconfig dev ag71xx-mdio.0 port 1 get link | grep -q up
or
swconfig dev ag71xx-mdio.0 port 1 get link | grep -q down

Test the return for success/fail, then issue ifconfig eth0 up/down as
appropriate, and netifd goes about doing what it should have done with
the cable was yanked.

Just an endless loop testing for link up first, since an extra ifconfig
up on an already up IF will do nothing anyway, and I can't assume that
it is going to be 'up' when the script first runs in the init process

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

[OpenWrt-Devel] [PATCHv2] scripts/feeds: observe -p flag for preferential feeds

2015-05-27 Thread Karl Palsson

From: Karl Palsson 

lookup_target was trampling the $feed variable, resulting in the -p flag
no longer preferentially installing from the named feed.

Make sure to use a local variable for this instead.

Signed-off-by: Karl Palsson 
---
Changes since v1:
 Make sure to not just trample a global variable.  Aren't globals fun. Thanks
 to Felix for pointing it out

 scripts/feeds | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/feeds b/scripts/feeds
index a6be9cc..55756d9 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -450,10 +450,10 @@ sub install_package {
my $force = shift;
my $ret = 0;
 
-   $feed = lookup_target($feed, $name);
-   $feed and do {
+   my $this_feed_target = lookup_target($feed, $name);
+   $this_feed_target and do {
$installed_targets{$name} and return 0;
-   install_target($feed, $name);
+   install_target($this_feed_target, $name);
return 0;
};
 
-- 
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created

2015-05-27 Thread Christian Mehlis


Am 27.05.2015 um 16:23 schrieb Bastian Bittorf:

This is the case e.g. if JFFS2 partition is full.

see: https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00246.html
runtime tested on ar71xx with kernel 3.18.14 and r45772 (rebased)
this paritially fixes #19564

Signed-off-by: Bastian Bittorf 


Tested-By: Christian Mehlis 

Test run @45772 on ar71xx is available here:
http://pastebin.com/raw.php?i=ez7rtu2u

Best
Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created

2015-05-27 Thread Jo-Philipp Wich

Hi,

patch is fine with me however there's a typo in the error message:
  "failed to work directory"

This should get corrected (and upstream notified about it as well).

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] perf: replace libelf1 select by a depend

2015-05-27 Thread Mathieu Olivari

Perf is in trunk today, but it has no maintainer listed. Somebody probably 
needs to volunteer.
As of the packages I was planning to import, I'm adding the other maintainers 
to the To: list:
- argp-standalone: Ted Hess 
- bzip2: Steven Barth 
- Luiz Angelo Daros de Luca  

Initial proposal is here: https://patchwork.ozlabs.org/patch/473676/

Thanks,
Mathieu
-Original Message-
From: Felix Fietkau [mailto:n...@openwrt.org] 
Sent: Wednesday, May 27, 2015 8:33 AM
To: Mathieu Olivari; 'Luiz Angelo Daros de Luca'; blo...@openwrt.org
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] perf: replace libelf1 select by a depend

On 2015-05-27 02:13, Mathieu Olivari wrote:
> It was not merged; it stayed pending without resolution since then, so 
> I figured I’d find an alternative.
Replacing the select by a depend makes the whole process completely 
counterintuitive, so NACK from me on that.

Any package we add to trunk needs to have a maintainer. Is moving the relevant 
packages to trunk acked by the current package maintainers?

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

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Richard Clark

On 05/27/2015 05:41 AM, Jo-Philipp Wich wrote:
> Hi Richard,
> 
> the link status is not propagated to the netdev because there's an
> external switch chip between the CPU and the RJ45 plug on the outside.
> 
> There currently is no mechanism to propagate switch port states to Linux
> netdev link states as such an mechanism has various implications.
> 

Ok, that makes sense.  Just my dumb luck that the little portable
GL-Inet I was developing on happens to not have an internal switch, so
everything was fine there.

So currently it looks like good chunk of routers seem to follow the same
block diagram as the original WRT54g and are going to have the same
issue.  All the netifd handling to start/stop services on link state
never gets used.

I have worked around it for now by making a daemon to watch the switch
status events and manually up/down the interface in userspace.

Thanks for the info!

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

Re: [OpenWrt-Devel] [PATCH v2] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created

2015-05-27 Thread Bastian Bittorf

* Jo-Philipp Wich  [27.05.2015 18:40]:
> This should get corrected (and upstream notified about it as well).

e.g. 'failed to create work directory'?

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] Handling native application json formatted configs with uci

2015-05-27 Thread James Hilliard

I'm looking to manage cgminer's json formatted config files using uci, the
part I'm confused about is how to handle edits to the config that are done
by the application(cgminer) itself. Could uci be extended to handle json
formatted configs directly? Using intermediary uci configs could cause sync
issues since edits can come from both cgminer directly or uci.

Example config: https://github.com/ckolivas/cgminer/blob/master/example.conf
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created

2015-05-27 Thread Jo-Philipp Wich

Hi.
> e.g. 'failed to create work directory'?

Yeah, I assume that was the intended meaning of the message.

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created

2015-05-27 Thread Bastian Bittorf

This is the case e.g. if JFFS2 partition is full.

see: https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00246.html
(a small error in a logmessage was changed and reported upstream)

runtime tested on ar71xx with kernel 3.18.11 and r45772
this paritially fixes #19564

Signed-off-by: Bastian Bittorf 
---
 ...-overlayfs-fallback-to-readonly-when-full.patch |  109 
 1 file changed, 109 insertions(+)
 create mode 100644 
target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch

diff --git 
a/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
 
b/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
new file mode 100644
index 000..21f11fd
--- /dev/null
+++ 
b/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
@@ -0,0 +1,109 @@
+[linux-unionfs added to Cc]
+
+On Tue, May 19, 2015 at 09:51:20AM +0200, Bastian Bittorf wrote:
+> Hi Miklos,
+>
+> sorry for writing directly to you, feel free to forward
+> this to the appropriate mailinglist.
+>
+> we have a problem with mainline overlay filesystem on kernel 3.18:
+> https://dev.openwrt.org/ticket/19564
+>
+> 2 things are odd:
+> when the working filesystem is full, overlays fails with:
+>
+> overlayfs: failed to create directory /overlay/work/work
+>
+> what is strange, that we call it with:
+>
+> mount(overlay, "/mnt", "overlay", MS_NOATIME, lowerdir)
+>
+> see here:
+> 
http://nbd.name/gitweb.cgi?p=fstools.git;a=blob;f=libfstools/mount.c;h=81176ce399b4cd8e2d347c0008c13dec92407f55;hb=e6004000ff15d7bd32cf5663e8690fc94d7ec747#l125
+>
+> do you have an idea whats wrong?
+> 1) is it really needed, that we need space for creating dir "/overlay/work"?
+> 2) why does overlay need "/overlay/work/work"?
+
+The work directory is needed for atomic copy-up and similar.  It is not 
actually
+necessary to mount a read-only overlay.  Post 4.0 it is possible to mount the
+overlay without workdir (but even then it won't happen automatically in case 
the
+upper fs is full, so this should be fixed in the latest kernel too).
+
+Could you please try the following patch?  If the workdir can't be created it
+will fall back to mounting the overlay read-only.
+
+Thanks,
+Miklos
+
+---
+ fs/overlayfs/copy_up.c |3 +++
+ fs/overlayfs/dir.c |9 +
+ fs/overlayfs/super.c   |   12 +---
+ 3 files changed, 21 insertions(+), 3 deletions(-)
+
+--- a/fs/overlayfs/copy_up.c
 b/fs/overlayfs/copy_up.c
+@@ -300,6 +300,9 @@ int ovl_copy_up_one(struct dentry *paren
+   struct cred *override_cred;
+   char *link = NULL;
+
++  if (WARN_ON(!workdir))
++  return -EROFS;
++
+   ovl_path_upper(parent, &parentpath);
+   upperdir = parentpath.dentry;
+
+--- a/fs/overlayfs/dir.c
 b/fs/overlayfs/dir.c
+@@ -222,6 +222,9 @@ static struct dentry *ovl_clear_empty(st
+   struct kstat stat;
+   int err;
+
++  if (WARN_ON(!workdir))
++  return ERR_PTR(-EROFS);
++
+   err = ovl_lock_rename_workdir(workdir, upperdir);
+   if (err)
+   goto out;
+@@ -322,6 +325,9 @@ static int ovl_create_over_whiteout(stru
+   struct dentry *newdentry;
+   int err;
+
++  if (WARN_ON(!workdir))
++  return -EROFS;
++
+   err = ovl_lock_rename_workdir(workdir, upperdir);
+   if (err)
+   goto out;
+@@ -506,6 +512,9 @@ static int ovl_remove_and_whiteout(struc
+   struct dentry *opaquedir = NULL;
+   int err;
+
++  if (WARN_ON(!workdir))
++  return -EROFS;
++
+   if (is_dir) {
+   opaquedir = ovl_check_empty_and_clear(dentry);
+   err = PTR_ERR(opaquedir);
+--- a/fs/overlayfs/super.c
 b/fs/overlayfs/super.c
+@@ -740,9 +740,15 @@ static int ovl_fill_super(struct super_b
+   ufs->workdir = ovl_workdir_create(ufs->upper_mnt, workpath.dentry);
+   err = PTR_ERR(ufs->workdir);
+   if (IS_ERR(ufs->workdir)) {
+-  pr_err("overlayfs: failed to create directory %s/%s\n",
+- ufs->config.workdir, OVL_WORKDIR_NAME);
+-  goto out_put_lower_mnt;
++  if (err == -ENOSPC || err == -EROFS) {
++  pr_warning("overlayfs: failed to create work directory 
(%s), mounting read-only\n", err == ENOSPC ? "ENOSPC" : "EROFS");
++  sb->s_flags |= MS_RDONLY;
++  ufs->workdir = NULL;
++  } else {
++  pr_err("overlayfs: failed to create directory %s/%s\n",
++ ufs->config.workdir, OVL_WORKDIR_NAME);
++  goto out_put_lower_mnt;
++  }
+   }
+
+   /*
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created

2015-05-27 Thread Jo-Philipp Wich

On 05/27/2015 06:58 PM, Bastian Bittorf wrote:
> This is the case e.g. if JFFS2 partition is full.
> 
> see: https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00246.html
> (a small error in a logmessage was changed and reported upstream)
> 
> runtime tested on ar71xx with kernel 3.18.11 and r45772
> this paritially fixes #19564
> 
> Signed-off-by: Bastian Bittorf 

Acked-by: Jo-Philipp Wich 

> ---
>  ...-overlayfs-fallback-to-readonly-when-full.patch |  109 
> 
>  1 file changed, 109 insertions(+)
>  create mode 100644 
> target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
> 
> diff --git 
> a/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
>  
> b/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
> new file mode 100644
> index 000..21f11fd
> --- /dev/null
> +++ 
> b/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
> @@ -0,0 +1,109 @@
> +[linux-unionfs added to Cc]
> +
> +On Tue, May 19, 2015 at 09:51:20AM +0200, Bastian Bittorf wrote:
> +> Hi Miklos,
> +>
> +> sorry for writing directly to you, feel free to forward
> +> this to the appropriate mailinglist.
> +>
> +> we have a problem with mainline overlay filesystem on kernel 3.18:
> +> https://dev.openwrt.org/ticket/19564
> +>
> +> 2 things are odd:
> +> when the working filesystem is full, overlays fails with:
> +>
> +> overlayfs: failed to create directory /overlay/work/work
> +>
> +> what is strange, that we call it with:
> +>
> +> mount(overlay, "/mnt", "overlay", MS_NOATIME, lowerdir)
> +>
> +> see here:
> +> 
> http://nbd.name/gitweb.cgi?p=fstools.git;a=blob;f=libfstools/mount.c;h=81176ce399b4cd8e2d347c0008c13dec92407f55;hb=e6004000ff15d7bd32cf5663e8690fc94d7ec747#l125
> +>
> +> do you have an idea whats wrong?
> +> 1) is it really needed, that we need space for creating dir 
> "/overlay/work"?
> +> 2) why does overlay need "/overlay/work/work"?
> +
> +The work directory is needed for atomic copy-up and similar.  It is not 
> actually
> +necessary to mount a read-only overlay.  Post 4.0 it is possible to mount the
> +overlay without workdir (but even then it won't happen automatically in case 
> the
> +upper fs is full, so this should be fixed in the latest kernel too).
> +
> +Could you please try the following patch?  If the workdir can't be created it
> +will fall back to mounting the overlay read-only.
> +
> +Thanks,
> +Miklos
> +
> +---
> + fs/overlayfs/copy_up.c |3 +++
> + fs/overlayfs/dir.c |9 +
> + fs/overlayfs/super.c   |   12 +---
> + 3 files changed, 21 insertions(+), 3 deletions(-)
> +
> +--- a/fs/overlayfs/copy_up.c
>  b/fs/overlayfs/copy_up.c
> +@@ -300,6 +300,9 @@ int ovl_copy_up_one(struct dentry *paren
> + struct cred *override_cred;
> + char *link = NULL;
> +
> ++if (WARN_ON(!workdir))
> ++return -EROFS;
> ++
> + ovl_path_upper(parent, &parentpath);
> + upperdir = parentpath.dentry;
> +
> +--- a/fs/overlayfs/dir.c
>  b/fs/overlayfs/dir.c
> +@@ -222,6 +222,9 @@ static struct dentry *ovl_clear_empty(st
> + struct kstat stat;
> + int err;
> +
> ++if (WARN_ON(!workdir))
> ++return ERR_PTR(-EROFS);
> ++
> + err = ovl_lock_rename_workdir(workdir, upperdir);
> + if (err)
> + goto out;
> +@@ -322,6 +325,9 @@ static int ovl_create_over_whiteout(stru
> + struct dentry *newdentry;
> + int err;
> +
> ++if (WARN_ON(!workdir))
> ++return -EROFS;
> ++
> + err = ovl_lock_rename_workdir(workdir, upperdir);
> + if (err)
> + goto out;
> +@@ -506,6 +512,9 @@ static int ovl_remove_and_whiteout(struc
> + struct dentry *opaquedir = NULL;
> + int err;
> +
> ++if (WARN_ON(!workdir))
> ++return -EROFS;
> ++
> + if (is_dir) {
> + opaquedir = ovl_check_empty_and_clear(dentry);
> + err = PTR_ERR(opaquedir);
> +--- a/fs/overlayfs/super.c
>  b/fs/overlayfs/super.c
> +@@ -740,9 +740,15 @@ static int ovl_fill_super(struct super_b
> + ufs->workdir = ovl_workdir_create(ufs->upper_mnt, workpath.dentry);
> + err = PTR_ERR(ufs->workdir);
> + if (IS_ERR(ufs->workdir)) {
> +-pr_err("overlayfs: failed to create directory %s/%s\n",
> +-   ufs->config.workdir, OVL_WORKDIR_NAME);
> +-goto out_put_lower_mnt;
> ++if (err == -ENOSPC || err == -EROFS) {
> ++pr_warning("overlayfs: failed to create work directory 
> (%s), mounting read-only\n", err == ENOSPC ? "ENOSPC" : "EROFS");
> ++sb->s_flags |= MS_RDONLY;
> ++ufs->workdir = NULL;
> ++} else {
> ++pr_err("overlayfs: failed to create directory %s/%s\n",
> ++   ufs->config.workdir, OVL_WORKDIR_NAME);
> ++goto out_put_lower_mnt;
> ++}
> +

[OpenWrt-Devel] [PATCH v2] sysctl: read settings from /etc/sysctl.d/*.conf

2015-05-27 Thread Stefan Tomanek

This changes makes it possible to store custom settings
in individual files inside the directory /etc/sysctl.d/.

Signed-off-by: Stefan Tomanek 
---
 package/base-files/Makefile|2 ++
 .../base-files/files/etc/hotplug.d/net/00-sysctl   |9 ++---
 package/base-files/files/etc/init.d/sysctl |4 +++-
 package/base-files/files/etc/sysctl.d/local.conf   |1 +
 4 files changed, 12 insertions(+), 4 deletions(-)
 create mode 100644 package/base-files/files/etc/sysctl.d/local.conf

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 0bba313..a5f15fa 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -55,6 +55,8 @@ define Package/base-files/conffiles
 /etc/config/
 /etc/dropbear/
 /etc/crontabs/
+/etc/sysctl.d/local.conf
+/etc/sysctl.d/
 $(call $(TARGET)/conffiles)
 endef
 
diff --git a/package/base-files/files/etc/hotplug.d/net/00-sysctl 
b/package/base-files/files/etc/hotplug.d/net/00-sysctl
index 5d9da8a..7a71652 100644
--- a/package/base-files/files/etc/hotplug.d/net/00-sysctl
+++ b/package/base-files/files/etc/hotplug.d/net/00-sysctl
@@ -1,6 +1,9 @@
 #!/bin/sh
 
-if [ -f /etc/sysctl.conf ] && [ "$ACTION" = add ]; then
-   sed -ne "/^[[:space:]]*net\..*\.$DEVICENAME\./p" /etc/sysctl.conf | \
-   sysctl -e -p - | logger -t sysctl
+if [ "$ACTION" = add ]; then
+   for CONF in /etc/sysctl.conf /etc/sysctl.d/*.conf; do
+   [ ! -f "$CONF" ] && continue;
+   sed -ne "/^[[:space:]]*net\..*\.$DEVICENAME\./p" "$CONF" | \
+   sysctl -e -p - | logger -t sysctl
+   done
 fi
diff --git a/package/base-files/files/etc/init.d/sysctl 
b/package/base-files/files/etc/init.d/sysctl
index 36e29ea..2dfbaf7 100755
--- a/package/base-files/files/etc/init.d/sysctl
+++ b/package/base-files/files/etc/init.d/sysctl
@@ -3,5 +3,7 @@
 
 START=11
 start() {
-   [ -f /etc/sysctl.conf ] && sysctl -p -e >&-
+   for CONF in /etc/sysctl.conf /etc/sysctl.d/*.conf; do
+   [ -f "$CONF" ] && sysctl -p "$CONF" -e >&-
+   done
 }
diff --git a/package/base-files/files/etc/sysctl.d/local.conf 
b/package/base-files/files/etc/sysctl.d/local.conf
new file mode 100644
index 000..891da73
--- /dev/null
+++ b/package/base-files/files/etc/sysctl.d/local.conf
@@ -0,0 +1 @@
+# local sysctl settings can be stored in this directory
-- 
1.7.2.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Gert Doering

Hi,

On Wed, May 27, 2015 at 02:41:31PM +0200, Jo-Philipp Wich wrote:
> For example: consider a switch port group containing five ports, 4
> external RJ45 ports and one internal connected to the SoC - when would
> you consider that interface down? When no port except the CPU one has a
> link? Whenever a cable is plugged into one of the four ports?

I'd consider "no external link at all" to be sufficient criteria to signal
"link down" internally.

(Which is how certain commercial platforms handle this - if "all L2 ports
in a given VLAN" go down, the "L3 routing interface" will also go down, 
and I found that usually to be "what I expect and want to happen")

Now, I'm not saying that this would be trivial to do, but tremendously
useful :-)

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpfIEgajtTyK.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info

2015-05-27 Thread Aleksander Wałęski

On Mon, May 25, 2015 at 4:08 PM, Aleksander Wałęski  wrote:

>> Maybe you and Aleksander can try this patch again?
>
> Sure, I'll flash my device with this and let it run for some time to
> see if there are any problems.
>
Ok, I tested your latest patch and everything seems to work but I
suggest following build flag changes (which I tested in my build):

add --enable-debug-prints=err to ltq-vdsl-app and change
enable-debug-prints to err in ltq-vdsl-vr9. Default debug level in api
seems to be higher, thats why it caused so much spam in kernel log.
"err" seems to be fine. I didn't notice any messages in dmesg during
normal operation nor any other side effects to this. And it might
provide very useful info if something goes wrong. This is much more
important for vdsl_cpe_control app, and that is the reason why I
started to mess with compilation flags to begin with. with debug
prints disabled it strips all help text in the console which makes
playing with it somewhat frustrating. Here is an example of output of
the same command with debug-prints=off on ltq-vdsl-app:

DSL_CPE#>acos
nReturn=-1 (wrong number of parameters/help not available)

and with debug-prints=err

DSL_CPE#>acos
Long Form: AutobootConfigOptionSet
Short Form: acos

Input Parameter
- DSL_boolean_t bWaitBeforeConfigWrite
   false = 0
   true = 1
- DSL_boolean_t bWaitBeforeLinkActivation
   false = 0
   true = 1
- DSL_boolean_t bWaitBeforeRestart
   false = 0
   true = 1
- DSL_boolean_t bAutoContinueWaitBeforeConfigWrite (dsl_cpe_control)
   false = 0
   true = 1
- DSL_boolean_t bAutoContinueWaitBeforeLinkActivation (dsl_cpe_control)
   false = 0
   true = 1
- DSL_boolean_t bAutoContinueWaitBeforeRestart (dsl_cpe_control)
   false = 0
   true = 1

Output Parameter
- DSL_Error_t nReturn

Additionally, I added --disable-dsl-ceoc to ltq-vdsl-app since CEOC is
disabled in API by default anyway.

Again, can someone with ADSL line test what parameters
vdsl_cpe_control actually needs to operate with newest driver and
firmware version (from W9980)? I accidentally compiled driver with
high debbuging level at one point and got this in kernel log:

== Port Mode Control (default) ===
[  438.848000]
[  438.848000] Dual Port Lock  : UNLOCKED
xDSL Mode Lock  : UNLOCKED
[  438.848000]
[  438.848000] Preferred Port Mode : SINGLE
Preferred xDSL Mode : VDSL
[  438.848000]
[  438.848000] Current Port Mode   : NONE
Current xDSL Mode   : NONE
[  438.848000]
[  438.848000]
==
[  438.848000]
== Port Mode Control (current) ===
[  438.848000]
[  438.848000] Dual Port Lock  : LOCKED
xDSL Mode Lock  : LOCKED
[  438.848000]
[  438.848000] Preferred Port Mode : SINGLE
Preferred xDSL Mode : VDSL
[  438.848000]
[  438.848000] Current Port Mode   : SINGLE
Current xDSL Mode   : VDSL
[  438.848000]
[  438.848000]
==

This makes me wonder if maybe TP-LINK firmware is just prepared to
support VDSL by default, but needs a startup parameter to support
ADSL. I still don't think it needs "low level config" though. It makes
sense not to require end user to know annex/tone group connection
requires.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Michael Richardson


Richard Clark  wrote:
>> Hi Richard,
>>
>> the link status is not propagated to the netdev because there's an
>> external switch chip between the CPU and the RJ45 plug on the outside.
>>
>> There currently is no mechanism to propagate switch port states to Linux
>> netdev link states as such an mechanism has various implications.
>>

> Ok, that makes sense.  Just my dumb luck that the little portable
> GL-Inet I was developing on happens to not have an internal switch, so
> everything was fine there.

> So currently it looks like good chunk of routers seem to follow the same
> block diagram as the original WRT54g and are going to have the same
> issue.  All the netifd handling to start/stop services on link state
> never gets used.

So, just to realize that you probably want active DNA[1] anyway, as even
on a device that has directly connected ports, plugging in a dumb switch
will give you link, yet there is really nothing beyond it.

[1]- https://tools.ietf.org/wg/dna/
Detecting Network Attachment
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Karl Palsson

Michael Richardson  wrote:
> 
> 
> So, just to realize that you probably want active DNA[1] anyway, as even
> on a device that has directly connected ports, plugging in a dumb switch
> will give you link, yet there is really nothing beyond it.
> 
> [1]- https://tools.ietf.org/wg/dna/
> Detecting Network Attachment

As a dumb user, I _expect_ to get a link light when I have "dumb" switch
connected, though I'm sure fancy network admins might like DNA.  What I
don't see any purpose in [1] is getting told I have link just because
the non-removable "cable" (pcb traces) between two parts of the board
inside my "dumb" box is in place.  

While I appreciate the design that makes this not working already, when
there _is_ a fixed port, I _do_ expect this to work.  

Sincerely,
Karl Palsson

[1] I'm sure it's very useful for the hw eng bringing up the board mind you :)___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Looking for a Broadcom Asus tester(s)

2015-05-27 Thread Rafał Miłecki

Hi,

With few recent commits OpenWrt can now generate Asus-specific TRX
files for brcm47xx and bcm53xx. The magic is about some extra data at
the end of TRX (so the format differs a bit, even it using the same
file extension and layout).

My request for someone having Broadcom-based Asus devices is:
1) Install original firmware
2) Try to install OpenWrt .trx firmware for that device
3) Let us know if it worked

I don't have any Asus device around, so I'm not sure if OpenWrt
generates really compatible images now. Above way is the only one to
verify it for sure :)

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx: How to integrate UniFi AP Outdoor Plus HSR?

2015-05-27 Thread Stefan Rompf

Hi Kirill,

> So I made a patch for atheros driver and it works. A signal level on
> different frequencies is more or less equal and seems adequate (about
> -30 dbm if a client within a meter from ap).

so you reverse engineered the timer values, the response format and the 's' 
command I had planned looking at next weekend. Very cool work!

Now that talking to the HSR seems mostly solved, this makes me think about 
OpenWrt integration. Currently I see two possibities:

Integration into the kernel driver like your latest patch does.

Caveat: The build process seems to assume that all routers in the 
ar71xx/generic target share the same set of kernel modules. So patching and 
compiling yourself is no problem, but a working image on downloads.openwrt.org 
is not feasible as every router would get the HSR driver. Correct me if I am 
wrong.

Or making ath9k expose the gpio and driving from user space. A generic patch 
for ath9k to register its gpio pins via the standard gpio subsystem. This 
should go upstream to the kernel and may prove usable for other access points 
to.

An Unifi specific user space daemon listens to scan and channel change events 
via netlink (will check next weekend if channel change is broadcasted 
reliably) and tune the filter via sysfs interface accordingly like hsr.c 
tried.

Caveat: Changing ath9k driver is possibly stuff for Designated Driver. May be 
the user space component can fall back to bit banging for Chaos Calmer.

What do you think? What do OpenWrt core developers think? I'd prefer exposing 
gpio and driving from userspace.

Stefan

PS: I've started working on the wiki page 
http://wiki.openwrt.org/toh/ubiquiti/unifi_outdoorplus that I hope to move to 
"supported" soon ;-)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Looking for a Broadcom Asus tester(s)

2015-05-27 Thread Álvaro Fernández Rojas

Hi,

I tested it on my ASUS RT-AC87U and it works like a charm.

Cheers!

El 27/05/2015 a las 22:32, Rafał Miłecki escribió:
> Hi,
> 
> With few recent commits OpenWrt can now generate Asus-specific TRX
> files for brcm47xx and bcm53xx. The magic is about some extra data at
> the end of TRX (so the format differs a bit, even it using the same
> file extension and layout).
> 
> My request for someone having Broadcom-based Asus devices is:
> 1) Install original firmware
> 2) Try to install OpenWrt .trx firmware for that device
> 3) Let us know if it worked
> 
> I don't have any Asus device around, so I'm not sure if OpenWrt
> generates really compatible images now. Above way is the only one to
> verify it for sure :)
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Looking for a Broadcom Asus tester(s)

2015-05-27 Thread Ian Kent

On Wed, 2015-05-27 at 22:32 +0200, Rafał Miłecki wrote:
> Hi,
> 
> With few recent commits OpenWrt can now generate Asus-specific TRX
> files for brcm47xx and bcm53xx. The magic is about some extra data at
> the end of TRX (so the format differs a bit, even it using the same
> file extension and layout).
> 
> My request for someone having Broadcom-based Asus devices is:
> 1) Install original firmware
> 2) Try to install OpenWrt .trx firmware for that device
> 3) Let us know if it worked
> 
> I don't have any Asus device around, so I'm not sure if OpenWrt
> generates really compatible images now. Above way is the only one to
> verify it for sure :)

Has the partition corruption I saw with the RT-AC87U a while ago (when I
tested if it would boot, which it didn't) been sorted out?

I really don't want to risk breaking my device again. I was lucky I was
able to get a build of asuswrt-merlin to go far enough to build
mtd-erase2, actually it's a symlink to the rc utility, (with an
appropriate change) to allow me to fix the problem.

btw, off-topic, I've been able to load the R8000 OpenWrt chk firmware
via Luci a few times now so I don't know what changed but it seems ok
now.

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

Re: [OpenWrt-Devel] Looking for a Broadcom Asus tester(s)

2015-05-27 Thread Rafał Miłecki

On 28 May 2015 at 07:33, Ian Kent  wrote:
> On Wed, 2015-05-27 at 22:32 +0200, Rafał Miłecki wrote:
>> Hi,
>>
>> With few recent commits OpenWrt can now generate Asus-specific TRX
>> files for brcm47xx and bcm53xx. The magic is about some extra data at
>> the end of TRX (so the format differs a bit, even it using the same
>> file extension and layout).
>>
>> My request for someone having Broadcom-based Asus devices is:
>> 1) Install original firmware
>> 2) Try to install OpenWrt .trx firmware for that device
>> 3) Let us know if it worked
>>
>> I don't have any Asus device around, so I'm not sure if OpenWrt
>> generates really compatible images now. Above way is the only one to
>> verify it for sure :)
>
> Has the partition corruption I saw with the RT-AC87U a while ago (when I
> tested if it would boot, which it didn't) been sorted out?

It's not perfect yet, but it works:
http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=beff7e61f2935a447522bc3057c51a0ef828be60
target/linux/bcm53xx/patches-3.18/901-mtd-bcm47xxpart-workaround-for-Asus-RT-AC87U-asus-pa.patch

For DD we'll get a better solution (I started working on it by patch
to linux-mtd for parsers support).


> btw, off-topic, I've been able to load the R8000 OpenWrt chk firmware
> via Luci a few times now so I don't know what changed but it seems ok
> now.

Support for extracting TRX files from bin (Linksys) and chk (Netgear)
was added few months ago.

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Looking for a Broadcom Asus tester(s)

2015-05-27 Thread Rafał Miłecki

On 28 May 2015 at 07:42, Rafał Miłecki  wrote:
> On 28 May 2015 at 07:33, Ian Kent  wrote:
>> On Wed, 2015-05-27 at 22:32 +0200, Rafał Miłecki wrote:
>>> Hi,
>>>
>>> With few recent commits OpenWrt can now generate Asus-specific TRX
>>> files for brcm47xx and bcm53xx. The magic is about some extra data at
>>> the end of TRX (so the format differs a bit, even it using the same
>>> file extension and layout).
>>>
>>> My request for someone having Broadcom-based Asus devices is:
>>> 1) Install original firmware
>>> 2) Try to install OpenWrt .trx firmware for that device
>>> 3) Let us know if it worked
>>>
>>> I don't have any Asus device around, so I'm not sure if OpenWrt
>>> generates really compatible images now. Above way is the only one to
>>> verify it for sure :)
>>
>> Has the partition corruption I saw with the RT-AC87U a while ago (when I
>> tested if it would boot, which it didn't) been sorted out?
>
> It's not perfect yet, but it works:
> http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=beff7e61f2935a447522bc3057c51a0ef828be60
> target/linux/bcm53xx/patches-3.18/901-mtd-bcm47xxpart-workaround-for-Asus-RT-AC87U-asus-pa.patch
>
> For DD we'll get a better solution (I started working on it by patch
> to linux-mtd for parsers support).

For more details, see https://patchwork.ozlabs.org/patch/473018/ (discussion).

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Christian Mehlis


Am 27.05.2015 um 20:57 schrieb Gert Doering:

(Which is how certain commercial platforms handle this - if "all L2 ports
in a given VLAN" go down, the "L3 routing interface" will also go down,
and I found that usually to be "what I expect and want to happen")


This would totally match my usecase.
I like this solution.

Best
Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

38 matches

Mail list logo