Hi Sergey,
did a quick review of the series and it looks good. i will merge it as
is so that we don't loose too much time. we can do the rest of the
review cleanup on the linux-mips. i have pushed the patches just now,
please check if i merged them correctly/
John
On 12/09/2014 04:00,
Am 12.09.2014 um 03:48 schrieb Linus Lüssing:
Another idea would maybe be to translate MLDv1 / IGMPv2 reports into
appropriate MLDv2/IGMPv3 equivalents before sharing them on the
bridge to prevent the suppression.
Hm, IGMPv2/MLDv1 to IGMPv3/MLDv2 should be relatively easy. But
I'm currently
2014-09-12 10:51 GMT+04:00, John Crispin blo...@openwrt.org:
Hi Sergey,
did a quick review of the series and it looks good. i will merge it as
is so that we don't loose too much time. we can do the rest of the
review cleanup on the linux-mips. i have pushed the patches just now,
please check
Hello,
We're using OpenVSwitch on OpenWRT, and we've been looking into an upgrade
from 2.0 to 2.3.
Seems that OVS, is dependent on libatomic, which is not exported from the
toolchain, though it is built.
We've found this patch in patchwork.
http://patchwork.openwrt.org/patch/5019/
[ Sorry for
There you go. It would be nice if anyone could maintain a package for
openvswitch in the packages or routing-feed then.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Awesome.
Thanks for updating it.
If nobody else wants to step forward for maintaining the OVS feed, I'll
fully commit to maintaining it.
[ Well, that is, if I'm allowed ]
Thanks
Alex
On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth cy...@openwrt.org wrote:
There you go. It would be nice if
Commit b79e808 added O_CLOEXEC marking of ubus socket which requires
_GNU_SOURCE define to be set on some systems to avoid compilation issue.
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CMakeLists.txt
As described in the OpenWRT network wiki
(http://wiki.openwrt.org/doc/uci/network#options.valid.for.all.protocol.types)
common interface uci parameters can be defined like mtu/macaddr/... which
override the default interface values.
This is working fine when old style vlan configuration is used
On Friday 12 September 2014 15:13:11 Hans Dedecker wrote:
Now I'm a bit puzzled if the oberved behavior (need to define mtu/macaddr in
the device section to make override work) is expected behavior by design
choice or does it need to be considered as bug ?
I believe macaddress and mtu are
Hi Alexandru,
sure go ahead. I think there are already some package-definitions on
github https://github.com/pichuang/openvwrt/ which you can base the
package on.
I think the easiest way would be to read our guidelines at:
https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md
and
On Fri, Sep 12, 2014 at 3:50 PM, Gioacchino Mazzurco g...@eigenlab.org wrote:
On Friday 12 September 2014 15:13:11 Hans Dedecker wrote:
Now I'm a bit puzzled if the oberved behavior (need to define mtu/macaddr in
the device section to make override work) is expected behavior by design
choice
Hey Steven,
At the moment we use this one as base:
https://github.com/hschaa/openvswitch-feed
I did also take a look also at pichuang's repo.
I'll take a look at multiple versions and try to pull in all the cleanest
elements from each.
Then do some tests and come back with a pull request on
Oh fine with me as well. Use whatever version or patches you think works best.
I was just suggesting a starting point in case you needed one. Feel free to
ignore it though.
Cheers,
Steven
On 12. September 2014 16:26:16 MESZ, Alexandru Ardelean
ardeleana...@gmail.com wrote:
Hey Steven,
At
On Friday 12 September 2014 16:21:53 Hans Dedecker wrote:
Just it needs to be made clear this is the vision for the future as
currently there's confusion as the wiki documentation does not align
the actual implementation
Yeah the wiki need to be updated
14 matches
Mail list logo
