Sorry, beat you again by 20 minutes :P
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Looks good and applies. Usually the Signed-off-by is at the end of the
commit message though.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
On 02.05.2015 13:33, Daniel Golle wrote:
r45593 includes l2tp_ip6 in the kmod-l2tp-ip package.
This is not feasible for several reasons:
- in a given setup one usually uses either l2tp_ip or
l2tp_ip6, but never both
I disagree here, if you e.g. use a hostname and resolve that before
conn
Hello Linus,
thanks for the patch. I have two questions here.
#1 Why should this be done for v6 but not for v4?
#2 If the intention is to respond to MLD queries why should the firewall
allow reception of report messages?
Cheers,
Steven
___
openw
Anyway, I get that argument, but it could still be solved by
adding +IPV6:kmod-l2tp-ip6 as a dependency to kmod-l2tp-ip.
If it's really about the packaging overhead, it would also
be possible to only include l2tp_ip6.ko in FILES if IPV6 is set,
thus getting rid of the kmod-ipv6 dependency on n
Fine with me in principle, howeverI find the name "force_ps" to be
misleading since the option does not override or enforce anything. Maybe
"default_ps" would be a more suitable name?
Cheers,
Steven
On 11.05.2015 18:30, Hans Dedecker wrote:
Default packet steering behavior can be configured
Applied, thanks.
On 12.05.2015 13:11, Hans Dedecker wrote:
The default packet steering behavior can be configured via the parameter
default_ps in the global section; the default value is true to keep
backwards compatibility.
Device packet steering (rps/xps) config can still be used to override t
Applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
The OpenWrt developers are proud to announce the first release candidate
of OpenWrt Chaos Calmer.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__| |_
Thanks, and sorry for the mess. I probably ran the compile-check on the
wrong kernel-version.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
On 21.05.2015 20:32, Michael Richardson wrote:
> Steven Barth wrote:
> > - Added support for 464XLAT (CLAT)
>
> Is this signaled in some way by DHCPv6?
> If so, I imagine that there is an RFC# which says how it works, could be
> listed here, so that google will find CC
Ok thanks for the suggestion. I added some ietf references to the homepage.
Cheers,
Steven
Am 22. Mai 2015 16:29:12 MESZ, schrieb Michael Richardson :
>
>Steven Barth wrote:
>>> Steven Barth wrote:
>>> > - Added support for 464XLAT (CLAT)
>>>
The patch is malformed and cannot be applied.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Is that okay with you as well https://dev.openwrt.org/changeset/45867 ?
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Do you by chance remember what was the behavior of the Linux kernel's
intenral querier was.
I mean does it use the usual L3-address of the bridge as source? How
does it behave in the presence of other queriers either on WiFi stas or
other bridge ports?
Thanks,
Steven
___
Thanks for the quick reply.
On 03.06.2015 08:26, Linus Lüssing wrote:
> For IPv6 and a non-zero IPv4 source address it'll use the normal
> IGMP/MLD querier election mechanism, meaning the one with the lowest
> IP address will become the selected querier and the only one querying
> on the link.
So
>Steven, could you elaborate a little more on the scenario and
>explain why it is a must to shut up automatically when having a
>local user-space querier? If people are able to manually install and
>configure a complex multicast router, aren't they capable of
>manually disabling the bridge queri
Applied, we have to cleanup kmod-sched at some point and throw out all
the crap nobody uses anyway.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Your patch is mangled and doesn't apply.
On another note I hope we will see the final soon...
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Nope, mangled still.
See "MUA-SPECIFIC HINTS" on https://git-scm.com/docs/git-format-patch to
fix Thunderbird though tbh. using git-send-email is easier in most
cases, see https://git-scm.com/docs/git-send-email especially "EXAMPLE"
at the very end.
Cheers,
Steven
_
Indeed, you can have a look at
http://patchwork.ozlabs.org/project/openwrt/list/ to see and download
the patches extracted from the mails (also the old ones).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin
It's fine, he's just cleaning up after me *ducks and hides*.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Thanks for the hint, I updated the package-definitions.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Thanks, I already applied the other two.
On 10.06.2015 10:39, Hans Dedecker wrote:
> +ppp_select_ipaddr()
> +{
> + local interface="$1"
> + local addrs=$(uci_get "network.${interface}.ipaddr")
> + local netmask=$(uci_get "network.${interface}.netmask")
Any particular reason you are re
> UCI is read as network_get_subnets only returns info for active
> interfaces; e.g. if the referred interface in the unnumbered parameter
> is down it's not possible to install the host dependency based on the
> IP address for the PPP interface.
> Did not (yet) find a way to circumvent this iss
addresses.
Please let me know if that works for you.
Cheers,
Steven
On 10.06.2015 14:52, Steven Barth wrote:
>
>
>
>> UCI is read as network_get_subnets only returns info for active
>> interfaces; e.g. if the referred interface in the unnumbered parameter
>> i
Applied, thanks.
On 12.06.2015 09:26, Hans Dedecker wrote:
> Adds PPP unnumbered support via the parameter unnumbered which points to a
> logical OpenWRT interface.
> The PPP proto shell handler will "borrow" an IP address from the unnumbered
> interface (if multiple
> IP addresses are present t
The OpenWrt developers are proud to announce the first release candidate
of OpenWrt Chaos Calmer.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__| |_
Since you are replying to the Chaos Calmer announcement, have you
actually tried it with the CC RC2 or only BB as you mentioned?
If not, then please try if CC makes a difference to you.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https
Thanks, applied to trunk and CC.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
That commit got reverted 4 months later and was never really in use for
long. Source-Destination routing has been used to replace it for egress
traffic, i.e. there are simply no external (e.g. default) routes that
have a matching source-restriction.
For ingress traffic the stateful firewall handle
You should see an unreachable route for your own local ULA /48.
Also if your clients try to use your local ULA as source to reach
anything outside of the ULA (e.g. global addresses) this is blocked
(there is no matching route - simpler explanation to my previous post).
I don't see any particular p
Source-Destination matching is done in the regular routing table.
E.g. for my he.net connection the v6 routing table looks like this:
default from 2001:470:xx:yyy::/64 dev 6in4-henet proto static metric 1024
default from 2001:470:::/48 dev 6in4-henet proto static metric 1024
if you try to
oldpackages are obsolete and in many instances riddled with security issues.
They should not be used at all.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi Etienne,
I don't get your issue. 46119 only unifies the override variables,
meaning if a package maintainer wants to override e.g. RELRO he now
only needs to add PKG_RELRO:=0 instead of adding two for both RELRO
modes.
Cheers,
Steven
___
openwrt-de
Applied, thanks.
Am 06.07.2015 um 18:29 schrieb Hans Dedecker:
> Signed-off-by: Hans Dedecker
> ---
> package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
> b/package/netw
Applied.
Am 06.07.2015 um 23:37 schrieb Rafał Miłecki:
> Using pipe automatically switches service to block buffering which kind
> of breaks our logging. We won't get anything from stdout FD until the
> buffer gets filled fully or the service exits. This makes log messages
> appear with an unwante
The reason for the commit was that supporting hardening such as SSP
accross 3 libcs is a PITA to maintain. I'm fine if someone comes up
with a patch that would fix it, though.
In general, you suggest to always enabled UCLIBCs SSP options and get
rid of the GCCs libssp?
Cheers,
Steven
__
Thanks for the effort. However, I personally think we should rather phase out
uclibc
completely and focus on musl which has a much cleaner codebase. I don't think
it is
worth in the long run to maintain support for both libcs given our limited
ressources.
Cheers,
Steven
__
Hi everyone,
I just pushed a few experimental changes to trunk for odhcpd.
#1 Unsolicited RAs are now also sent via unicast to known neighbors
This may help address an issues commonly seen in some android phones.
Some popular devices seem to ignore MC RAs during standby / display off,
thus once
The OpenWrt developers are proud to announce the third release candidate of
OpenWrt Chaos Calmer.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__| |
Sorry, small mistake. Kernel is 3.18.17 in RC3.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> Does this "Fixed broken IPv6 downstream DHCPv6-PD and onlink-route
> handling" fix the issue with loosing the default gateway for IPv6 and
> only fixing when you reboot the router ?
I haven't heard of such an issue. This might be something specific to
your ISP which is outside of our range or m
I don't think we should be tracking RCs any longer. I did this for 2.73
mainly due to the security exploit and there not being a stable update,
plus DNSSEC was pretty screwed before that. I think we should go back to
backporting individual fixes via patches instead.
Cheers,
Steven
__
Add a section like this:
config lan6
option proto dhcpv6
option ifname @lan
And yes, proto dhcpv6 also works with RAs only.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinf
dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:677074 (661.2 KiB) TX bytes:677074 (661.2 KiB)
>
> On Fri, Jul 24, 2015 at 5:32 PM, Steven Barth <mailto:cy...@openwrt.org>> wrote:
>
> Add a section like this:
>
> co
I'm not sure what you are trying to accomplish. If you are connecting a router
with a default
OpenWrt image with default configuration to an ISP or IPv6 router which offers
prefix delegation,
everything works out of the box including client configuration. You don't need
to touch a single
config
Hello Jean-Michel,
according to your Wiki-Entry stateful addressing does work,
no need to do anything with dnsmasq.
Quoting your ifconfig output
" addr inet6: 2a01:e35:87d8:::953/128 Scope:Global"
is clearly a stateful address (/128) and your host got the host-id
953 for stateful adressing.
> I could solve all issues and write a complete HOWTO (in French only at
> first).http://wiki.openwrt.org/doc/howto/freebox
That is nice to hear.
> OpenWRT seems to provide at the same time stateful and stateless
> adressing.
Where you have option dhcpv6 and option ra you can add an option ra_
> Thanks ! I could update my docs and add acknowledgment for your kind
> help.http://wiki.openwrt.org/doc/howto/freebox?&#acknowledgmentsremerciements
> The only missing part in stateful only configuration is the the default IPv6
> gateway fe80::5642:49ff:fe87: on local network.
> Do you kno
Hello Yousong,
thanks for your patch.
Shouldn't there by a timeout cancel path somewhere in case the protocol
gets removed after the timer was armed but before it was fired?
I could imagine it causing memory corruption otherwise.
Cheers,
Steven
___
o
Hi Linus,
one of these two kernel patches break IPv6 over WiFi completely.
https://dev.openwrt.org/changeset/46719 works
https://dev.openwrt.org/changeset/46723 is broken with default settings,
but works when setting option igmp_snooping 0.
symptoms are:
"IPv6: wlan0: IPv6 duplicate address fe80
>Ok, I was able to easily reproduce the issue here. Looking at the
>tcpdump the wifi client receives its own Neighbor Solicitation
>again, reflected through the bridge-hairpin option.
Why are we reflecting packets back to the originator anyway? Could it not be
excluded?
Btw. once we are bit m
Am 02.09.2015 um 05:17 schrieb Linus Lüssing:
> Currently, multicast packets from an STA are sent to any according
> multicast listener directly through the bridge multicast-to-unicast
> feature. Unfortunately, so far this includes the originating STA, too,
> resulting in multicast packets being e
NAK.
Not many package build systems honors CPPFLAGS so this solution is impractical,
since it effectively disables fortification for many of them.
To my knowledge c-ares is the only package enforcing this kind of behavior
so it should be fixed to work with our buildsystem instead.
Hello everyone,
as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of
the base images. As a replacement, it is now possible to login to the root-
account via SSH without a password prompt whenever no root password is set,
e.g. after a flash without keeping config, factory reset
Hello Michael,
that is interesting, though I guess since these are mainly our default
it shouldn't be too hard for someone manufacturing to change the config
and readd a simple init-script for telnetd if that is really required.
Lack of entropy doesn't seem to be too much of an issue here, in fac
Hello Matti,
thanks, I very much support this patch.
One little thing:
proto_add_ipv6_route "::0" 0 "$gateway_6"
should be
proto_add_ipv6_route "::0" 0 "$gateway_6" "" "" "${ip_6}/${ip_prefix_length}"
otherwise this might break IPv6 connectivity in the presence of other
IPv6 connections. In ge
The OpenWrt developers are proud to announce the final release of OpenWrt Chaos
Calmer.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__| ||
Well it's not yet abandoned we still have to migrate a lot of
stuff under target/ and in the feeds. ifconfig and route won't
go away before that happens.
Besides I guess it's a more pressing issue now with IPv6 and so on
where the old tools are relatively useless. As we are making some
more ground
Using --dnssec-no-timecheck is impractical since it reacts to SIGHUP which
is already overloaded and might be triggered by e.g. config changes.
Btw. an ntp hotplug infrastructure exists:
https://dev.openwrt.org/changeset/43421
Please also consider that some devices have an RTC, so disabling timec
There is already "option boguspriv 1" so I do not really see the point.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Okay, we can do this, however we need to figure 3 things out first.
1. Disable boguspriv, doing both is unintuitive.
2. Make sure it doesn't broke reverse resolving locally known hosts,
i.e. those in the hostfiles and those that have a DHCP lease.
3. Make sure that doesn't break applications that
NAK. Use "option ip4table" and "option ip6table" which works with
all protocols already.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Alexander,
I don't have a problem with that particular patch. However since the
other patch was redundant and the only user of this one it seemed
redundant to me as well. If you have another usecase for this then
please let us know.
Cheers,
Steven
On 29.09.2015 11:37, Alexander Couzens wrote:
One important point was IIRC, migrating from one stable branch to another is
awkward
since the history is different, so rebasing custom changes on top is painful.
All in all there was relatively overwhelming feedback of most of the people at
the
summit that there lifes would be very much easier
Please read our package submission guidelines here
https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md
and once your submission complies, create a pull
request at: https://github.com/openwrt/packages
Cheers,
Steven
___
openwrt-devel mailing
Let's face it though: the current workflow wrt. core patches is crappy.
1. Go to patchwork, see if there is a patch
2. If you want to comment, switch to mail client, find thread, write reply.
3. If you want to commit: download patch, go to command line, see if it applies
4. Then manually go back t
>> Let's face it though: the current workflow wrt. core patches is crappy.
>>
>> 1. Go to patchwork, see if there is a patch
>> 2. If you want to comment, switch to mail client, find thread, write reply.
>> 3. If you want to commit: download patch, go to command line, see if it
>> applies
>> 4. T
>
> Step 5 is unnecessary, patchwork sends emails on status changes.
Okay, it seems it does this only for the original submitter, right?
I guess it might come in handy to send it to the ML as well, or at
least make that possible in the WebUI.
> I usually copy the mbox link from patchwork and do t
>>> What would your preferred workflow be? Please list the exact series of
>>> steps for it.
>> So to summarize, based on the current workflow:
>> 1. Be able to send mails (and change status) from within patchwork, e.g.
>> how you can do it in trac, just that it gets send out to the ML and the
Hello Bryan,
thanks a lot for your efforts. I would suggest to submit the patchset
to this list (with added Signed-Off-By tags) and we can discuss the
individual ones here then.
Thanks,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt
I'm sorry but this patch doesn't apply:
Applying patch #532998 using 'git am'
Description: [OpenWrt-Devel,1/2,netifd] multicast flag control
Applying: multicast flag control
error: patch failed: device.c:40
error: device.c: patch does not apply
error: patch failed: system-linux.c:1091
error: syste
Hey everyone,
I took the time last week to create a full-history git-mirror with
branches, author mapping and release tags. It is currently on github,
but it will probably end up on git.openwrt.org in the end.
Note: Do NOT send us pull requests to this repository, they will be
ignored. Send patch
You are most likely missing a route to the remote tunnel endpoint
(192.168.11.5).
The system doesn't know which interface and next hop to send the
tunneled packets to, thats why its blocking the tunnel bringup.
Cheers,
Steven
___
openwrt-devel maili
I don't see this argument as very convincing. I mean they still have
control even if the client ORO's 121, they could simply ignore it. On
top of that I think there are enough clients already (Windows at least
IIRC) who do ORO for 121 by default.
So, my personal take on this is, we could ORO 1
Hi Baptiste,
in general our current firewalling approach is to keep defaults for IPv4
and IPv6 relatively close (not considering NAT here of course). Opening
up the IPv6 firewall by default would be unexpected and I don't really
like the approach for that matter and honestly I don't trust clie
Hi Sergey,
the oldpackages feed is unsupported and will not be updated any more.
If you want to submit packages or adopt packages from oldpackages which
are not there yet please go to https://github.com/openwrt/packages and
make a pull request there.
Cheers,
Steven
_
Hi Dirk,
thanks for your help. I'll try to add some more documentation for the
IPv6 stuff in the near future.
In general the aim is to make stuff comply with RFC 7084 (successor of
6204) as closely as possible (with only 1 or 2 exceptions on purpose).
In general I'm not sure if anyone has re
Hi Baptiste,
thanks for the report.
I renamed the xl2tpd netifd protocol to "l2tpv2" and kept the l2tpv3 as
"l2tp" as documented in the wiki.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi
tbh. we should get rid of that option network stuff.
I merged it anyway at first so we can get some experience with this
gre-integration.
Normally you should use something like this instead:
config interface mygre
option proto 'gre'
option ipaddr '203.0.113.2'
option pee
To be fair I introduced IFLA_IPTUN_ stuff earlier with MAP-encapsulation
support. My general impression was that we do not care about <3.10
targets any more.
So even if Hans provides some patches for GRE it will not help much
since MAP-support does the same.
Cheers,
Steven
Hi Florian,
I pushed a netifd revision 77a865b5b3ac476e05ff80f3c10d86686285c0da
which disables
ds-lite, map and gre using ifdefs if IFLA_IPTUN_MAX is not defined in
the kernel headers.
Could you please check if that does the trick for you (note: I did not
bump the netifd-Makefile in trunk ye
Hi Valent,
we decided to reorganize the packages feed in June, since lots of the
packages in there were unmaintained and we had lot's of patches we
couldn't review. The new feed resides on github which makes contributing
more straigt-forward. See https://github.com/openwrt/packages.
Now the
her in one package repository.
There might be a few more packages in the final but what is in RC3 now
(rsync is still running btw.) is a pretty good estimate of what will be
there.
Cheers,
Steven
Am 13.08.2014 um 12:46 schrieb Aaron Z:
On Wed, Aug 13, 2014 at 4:13 AM, Steven Barth w
Please file a bug against CURL itself, this issue is outside of our scope.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi Bastian,
you should try:
procd_set_param limits core="unlimited"
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
k that miniupnp is also
>having
>a similar issue where it dies silently after a few days.
>Can I apply the same method to debug miniupnp ??
>
>Regards,
>Luis Garcia
>
>
>On Tue, Aug 19, 2014 at 10:45 AM, Bastian Bittorf
>
>wrote:
>
>> * Steven Barth [19.08.2014
On another note: I just backported an upstream fix for a race condition.
Might be related to this issue or might not. Please try to test with
latest trunk or bb-branch.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
htt
Please see https://forum.openwrt.org/viewtopic.php?id=52219
Am 20.08.2014 um 15:03 schrieb Bastian Bittorf:
* Steven Barth [13.08.2014 10:48]:
The current status of "oldpackages" is this:
If you are using trunk and want to use the possibly outdated packages
you have to enable the o
Hi Richard,
could you please post the output of:
ifstatus wan
and
ifstatus wan6
when said situation occurs?
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-deve
Please try with:
option dhcpv6 disabled
instead of "none"
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
"disabled" is the same as omitting the dhcpv6 option. "none" is not valid in
this context and causes havoc it seems ;)___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Yeah, the issue was in the tons of work-arounds needed to deal with
Linux' onlink-route handling before 3.14. I added another one because
they are so nice and likeable. This should hopefully do the trick again,
until next time.
Cheers,
Steven
___
o
Well it seems to be still somewhat used in embedded stuff, e.g. my
5-year old HP ethernet/802.11g printer/scanner/whatever still uses MLDv1
/ IGMPv2 to do its MDNS / SSDP business.
Another idea would maybe be to translate MLDv1 / IGMPv2 reports into
appropriate MLDv2/IGMPv3 equivalents before
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 no
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
https://lists.openwrt.org/cgi-bin/mailman/listinfo/o
s, if I'm allowed ]
Thanks
Alex
On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth <mailto:cy...@openwrt.org>> wrote:
There you go. It would be nice if anyone could maintain a package
for openvswitch in the packages or routing-feed then.
est on Github.
>
>Thanks
>Alex
>
>On Fri, Sep 12, 2014 at 5:11 PM, Steven Barth
>wrote:
>
>> Hi Alexandru,
>>
>> sure go ahead. I think there are already some package-definitions on
>> github https://github.com/pichuang/openvwrt/ which you can bas
Hello Hans,
thanks for the patch. However can't you rather reuse some of the code
provided by the "sit" tunnel-type of system_add_ip_tunnel? The current
patch looks like duplicating a lot of that.
Cheers,
Steven
Am 01.10.2014 um 13:41 schrieb Hans Dedecker:
Adds IPIP tunnel support to net
1 - 100 of 204 matches
Mail list logo
