Re: [OpenWrt-Devel] openwrt-devel Digest, Vol 125, Issue 91

2016-05-22 Thread Vonger 
l一



Regards
Vonger在 openwrt-devel-requ...@lists.openwrt.org，2016年5月21日 上午12:04写道：Send openwrt-devel mailing list submissions to
	openwrt-devel@lists.openwrt.org
To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
or, via email, send a message with subject or body 'help' to
	openwrt-devel-requ...@lists.openwrt.org
You can reach the person managing the list at
	openwrt-devel-ow...@lists.openwrt.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openwrt-devel digest..."
Today's Topics:
   1. [PATCH 03/13] ar71xx: enable sysupgrade for the	OpenMesh
  OM2P-HSv3 (Sven Eckelmann)
   2. [PATCH 04/13] package/om-watchdog: add OpenMesh	OM2P-HSv3
  support (Sven Eckelmann)
   3. [PATCH 05/13] package/uboot-envtools: add OpenMesh	OM2P-HSv3
  support (Sven Eckelmann)
   4. [PATCH 06/13] ar71xx: add OM2P-HSv3 to the OM2P	profile
  (Sven Eckelmann)
   5. [PATCH 07/13] ar71xx: add kernel support for the	OpenMesh
  MR1750v2 (Sven Eckelmann)
   6. [PATCH 08/13] ar71xx: add user-space support for	the OpenMesh
  MR1750v2 (Sven Eckelmann)
   7. [PATCH 09/13] ar71xx: enable sysupgrade for the	OpenMesh
  MR1750v2 (Sven Eckelmann)
--
Message: 1
Date: Fri, 20 May 2016 18:03:50 +0200
From: Sven Eckelmann 
To: openwrt-devel@lists.openwrt.org
Cc: Sven Eckelmann 
Subject: [OpenWrt-Devel] [PATCH 03/13] ar71xx: enable sysupgrade for
	the	OpenMesh OM2P-HSv3
Message-ID:
	<1463760240-12418-3-git-send-email-sven.eckelm...@open-mesh.com>
Signed-off-by: Sven Eckelmann 
---
 target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 +
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++
 2 files changed, 3 insertions(+)
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
index bc362a7..270ef40 100644
--- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
@@ -47,6 +47,7 @@ platform_check_image_target_openmesh()
 			[ "$board" = "om2p-lc" ] && return 0
 			[ "$board" = "om2p-hs" ] && return 0
 			[ "$board" = "om2p-hsv2" ] && return 0
+			[ "$board" = "om2p-hsv3" ] && return 0
 			echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform"
 			return 1
 			;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 9f8a14b..2e01419 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -321,6 +321,7 @@ platform_check_image() {
 	om2pv2 | \
 	om2p-hs | \
 	om2p-hsv2 | \
+	om2p-hsv3 | \
 	om2p-lc | \
 	om5p | \
 	om5p-an | \
@@ -579,6 +580,7 @@ platform_do_upgrade() {
 	om2pv2 | \
 	om2p-hs | \
 	om2p-hsv2 | \
+	om2p-hsv3 | \
 	om2p-lc | \
 	om5p | \
 	om5p-an | \
-- 
2.8.1
--
Message: 2
Date: Fri, 20 May 2016 18:03:51 +0200
From: Sven Eckelmann 
To: openwrt-devel@lists.openwrt.org
Cc: Sven Eckelmann 
Subject: [OpenWrt-Devel] [PATCH 04/13] package/om-watchdog: add
	OpenMesh	OM2P-HSv3 support
Message-ID:
	<1463760240-12418-4-git-send-email-sven.eckelm...@open-mesh.com>
Signed-off-by: Sven Eckelmann 
---
 package/kernel/om-watchdog/files/om-watchdog.init | 1 +
 1 file changed, 1 insertion(+)
diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd] bridge: make learning and unicast-flood configurable per bridge port

2016-05-22 Thread Linus Lüssing 
Tuning these two options allows a more fine grained configuration of the
forwarding database (fdb) of a bridge.

The former allows to enable or disable the learning of the presence of
MAC addresses behind a bridge port. (default: enabled on all ports)

The latter allows to tune the behaviour in case a destination MAC address
of a frame is unknown to the fdb, like only flooding on specific ports or
not flooding on any port. (default: flood on all ports, except incoming)

This can be useful to create a dumb hub, for instance for monitoring
purposes. Or in larger layer 2 mesh networks to avoid keeping redundant
databases (e.g. with the batman-adv translation table).

Signed-off-by: Linus Lüssing 
---
 device.c   |   18 ++
 device.h   |6 ++
 system-linux.c |   18 ++
 3 files changed, 42 insertions(+)

diff --git a/device.c b/device.c
index 9344e1b..0e07615 100644
--- a/device.c
+++ b/device.c
@@ -51,6 +51,8 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = "multicast_to_unicast", 
.type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_MULTICAST_ROUTER] = { .name = "multicast_router", .type = 
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_MULTICAST] = { .name ="multicast", .type = BLOBMSG_TYPE_BOOL 
},
+   [DEV_ATTR_LEARNING] = { .name ="learning", .type = BLOBMSG_TYPE_BOOL },
+   [DEV_ATTR_UNICAST_FLOOD] = { .name ="unicast_flood", .type = 
BLOBMSG_TYPE_BOOL },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -177,6 +179,8 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
s->multicast : os->multicast;
n->multicast_to_unicast = s->multicast_to_unicast;
n->multicast_router = s->multicast_router;
+   n->learning = s->learning;
+   n->unicast_flood = s->unicast_flood;
n->flags = s->flags | os->flags | os->valid_flags;
 }
 
@@ -295,6 +299,16 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s->flags |= DEV_OPT_MULTICAST;
}
 
+   if ((cur = tb[DEV_ATTR_LEARNING])) {
+   s->learning = blobmsg_get_bool(cur);
+   s->flags |= DEV_OPT_LEARNING;
+   }
+
+   if ((cur = tb[DEV_ATTR_UNICAST_FLOOD])) {
+   s->unicast_flood = blobmsg_get_bool(cur);
+   s->flags |= DEV_OPT_UNICAST_FLOOD;
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -939,6 +953,10 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, "multicast_router", 
st.multicast_router);
if (st.flags & DEV_OPT_MULTICAST)
blobmsg_add_u8(b, "multicast", st.multicast);
+   if (st.flags & DEV_OPT_LEARNING)
+   blobmsg_add_u8(b, "learning", st.learning);
+   if (st.flags & DEV_OPT_UNICAST_FLOOD)
+   blobmsg_add_u8(b, "unicast_flood", st.unicast_flood);
}
 
s = blobmsg_open_table(b, "statistics");
diff --git a/device.h b/device.h
index ac77cfb..4a88c05 100644
--- a/device.h
+++ b/device.h
@@ -45,6 +45,8 @@ enum {
DEV_ATTR_MULTICAST_TO_UNICAST,
DEV_ATTR_MULTICAST_ROUTER,
DEV_ATTR_MULTICAST,
+   DEV_ATTR_LEARNING,
+   DEV_ATTR_UNICAST_FLOOD,
__DEV_ATTR_MAX,
 };
 
@@ -88,6 +90,8 @@ enum {
DEV_OPT_MULTICAST_TO_UNICAST= (1 << 14),
DEV_OPT_MULTICAST_ROUTER= (1 << 15),
DEV_OPT_MULTICAST   = (1 << 16),
+   DEV_OPT_LEARNING= (1 << 17),
+   DEV_OPT_UNICAST_FLOOD   = (1 << 18),
 };
 
 /* events broadcasted to all users of a device */
@@ -149,6 +153,8 @@ struct device_settings {
bool multicast_to_unicast;
unsigned int multicast_router;
bool multicast;
+   bool learning;
+   bool unicast_flood;
 };
 
 /*
diff --git a/system-linux.c b/system-linux.c
index 351a994..621f99b 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -372,6 +372,16 @@ static void 
system_bridge_set_startup_query_interval(struct device *dev, const c
  dev->ifname, val);
 }
 
+static void system_bridge_set_learning(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl("/sys/class/net/%s/brport/learning", dev->ifname, 
val);
+}
+
+static void system_bridge_set_unicast_flood(struct device *dev, const char 
*val)
+{
+   system_set_dev_sysctl("/sys/class/net/%s/brport/unicast_flood", 
dev->ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -648,6 +658,14 @@ int system_bridge_addif(struct device *bridge, struct 
device *dev)
system_bridge_set_multicast_router(dev, buf, false);
}
 
+   if (dev->settings.flags & DEV_OPT_LEARNING &&
+   !dev->settings.learning)
+   system_bridge_set_learning(dev,

Re: [OpenWrt-Devel] netifd: adding default route + route via previous default route

2016-05-22 Thread Nikos Mavrogiannopoulos 
On Sun, 2016-05-15 at 20:50 +0800, Yousong Zhou wrote:

> > > I remember `proto_add_host_dependency` can be used to instruct
> > > netifd
> > > to setup such a route.  But it looks like the relevant code for
> > > openconnect.sh is now commented out.
> > It was causing an infinite loop, and I could not understand through
> > code what the add_host_dependency was supposed to do. Do you have
> > any
> > information about this function?
> `proto_add_host_dependency` takes 3 arguments.
> 
>  - The 1st is the logical interface name we are adding dependency for
>  - The 2nd is the host the above interface will depend on
>  - The 3rd is also a logical interface name.  It's optional and is
> for
> explicitly specifying which logical interface the 1st argument
> depends on.
> 
> If the 3rd argument is not given, netifd will try to find the logical
> interface which provides route to to the specified host (2nd
> argument)
> and a host route will be available.  The 1st logical interface will
> also be added to the list of "users" of that logical interface and
> will be notified of it's up/down/update
> event.
> I guess the problem with openconnect.sh may be that the 3rd argument
> was using the incorrect type.  Is that `vpn-$config` meant to be a
> linux system interface name?  We can try just not passing the 3rd
> argument and see how it works.

That was most helpful, thank you. The issue seems to be addressed now.

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