btw. What is the policy on pushing on that repository? Should be
commits
restricted to the maintained packages or extend to any possible
package?
You can commit / propose (via pull request) any packages you want to maintain
as long as the packaged version is still supported upstream and has
Hello Jacob,
please note that we are not going to accept patches for the (old)
packages feed anymore.
See: https://forum.openwrt.org/viewtopic.php?id=51078 and the referenced
mail for details.
If you like you can adopt this package and maintain it in our new github
feed:
Hi Andre,
could you please add nettle-mini support and make this a build variant
instead of a config option, please?
Build variant has the advantage that we can precompile it as ipks
because we cannot enable dnssec by default.
Otherwise thanks for your work.
Cheers,
Steven
for every
possible combination.
Cheers,
Steven
Am 16.06.2014 10:12, schrieb Andre Heider:
Hi,
On Sun, Jun 15, 2014 at 11:13 AM, Steven Barth cy...@openwrt.org wrote:
could you please add nettle-mini support and make this a build variant
instead of a config option, please?
Build variant has
Hi Nikos,
Is there a reason for not having dnssec by default? If there is a way
to disable it, I believe it will only be beneficial to have it in.
The main problem here is that this increase the default image size
significantly plus we can't even reuse all the added crypto code because
none
On the contrary I'd prefer if it doesn't. Nettle is an open project
under LGPL that anyone can contribute and can be reused by a variety
of software; polarssl is closed commercial project under a commercial
license with a GPLv2 exception.
Oh well, I sometimes have the feeling if its open-source
That sounds better, but on the other side users wanting only dhcpv6
then get quite a lot of DNSSEC bloat.
I don't have numbers at hand, but we could explore static
libnettle-mini linking?
No, I wasn't thinking about dropping the dhcpv6 variant just to add the
full variant as number 3 so we
Applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Ah sorry, seems I forgot to send a reply here.
I noticed your initial patch was mangled but since it was trivial I
applied it manually already:
https://dev.openwrt.org/changeset/41212
Thanks and Cheers,
Steven
___
openwrt-devel mailing list
Hi Ondrej,
thanks for your efforts. However we are not accepting patches for the
old packages feed any more. However feel free to import, update and
maintain the 2 packages in the new feed at
https://github.com/openwrt/packages. You can send a Pull Request there.
Cheers,
Stevem
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
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
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
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
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
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
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 cy...@openwrt.org
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
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
bitt...@bluebottle.com
wrote:
* Steven Barth cy...@openwrt.org [19.08.2014 12:49]:
procd_set_param
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
Please see https://forum.openwrt.org/viewtopic.php?id=52219
Am 20.08.2014 um 15:03 schrieb Bastian Bittorf:
* Steven Barth cy...@openwrt.org [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
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
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
___
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
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
, that is, if I'm allowed ]
Thanks
Alex
On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth cy...@openwrt.org
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.
Cheers,
Steven
On Fri, Sep 12, 2014 at 5:11 PM, Steven Barth cy...@openwrt.org
wrote:
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
Your change completely disables reloading which breaks in case of wan
switching to a different interface or if lan interfaces are coming up.
I commited a change
https://github.com/openwrt-routing/packages/commit/8bc38fccc73b40e9599b897e335f2e7a5a67e879
which should avoid restarts in case wan
Merged with some modifications.
Thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi Gianluca,
thanks for your patch. However instead of adding wrappers to every
single application I'd rather like us to add the optstring '-' extension
to musl as a patch.
Cheers,
Steven
___
openwrt-devel mailing list
That change was actually intentional so 6rd is setup if its available
unless you disable it with iface6rd=0.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Hello Hans,
Thank you very much for your patches. I've commited them to the github repo and
will do some testing probably next week. If all works out i will get them live
afterwards.
Cheers,
Steven___
openwrt-devel mailing list
Hello Nathan,
Thanks for your patches. I already had a quick look at them and found that i
already addressed some of this in odhcpd which will replace 6relayd in the near
future. I will go through the others later again.
Cheers,
Steven___
Hello Hans,
could you please explain your patch again. I didn't quite get the
paragraph you've written. It seems the sentence is a bit garbled.
Thanks,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Hello Gui,
thanks for your report. I just updated odhcp6c to generate the routes
and addresses in netifd in a better way. The old method seemed to have
some races that could lead to the behaviour you have seen. Could you
please retest with the new odhcp6c and see if that works better for you?
Hello Heiner,
thanks, however overriding the kernel behavior is intentional as its
handling of e.g. routes is very limited. Also getting address from both
the kernel and through dhcpv6 to netifd to the kernel causes conflicts
such as the ones you noted. If you want to use Kernel RA-handling
Hello Henning,
i find it very strange that your ISP doesn't offer public addresses on
the WAN interface however I think this is actually standards compliant
so we have to deal with it.
please see: https://dev.openwrt.org/changeset/40422
I added an option weakif which allows you to specify an
Applied, thanks. Will probably take care of AA later today.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi Gert,
i find it very strange that your ISP doesn't offer public addresses on
the WAN interface however I think this is actually standards compliant
so we have to deal with it.
It's called IPv4 exhaustion... DS-Lite is one of the way to deal
with it (which effectively gives you only one NAT
Hi Gert,
There has been quite a bit of discussion in the ISP camp regarding WAN
IPv6 addresses. It's not actually straightforward what to do as an ISP,
so multiple variants exist
- RA for WAN, DHCPv6-PD for LAN
- DHCPv6-IA for WAN, DHCPv6-PD for LAN
- require use of an IPv6
Hi Henning,
yeah that is another side-effect of your - well - irregular
ISP-behaviour. I will try to put it on the TODO but it's not very high
on the list as its more or less cosmetic, sorry I'm a little short on
time at the moment.
Cheers,
Steven
Applied, thanks. Will get into OpenWrt with next netifd-bump.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi Gert,
In regular OpenWrt ip6assign means that - as already written - a /60 (if
available) is taken from the DP and the assigned to the given interface.
That value was chosen rather arbitrarily. The first /64 of that DP is
handed out via RA and stateful DHCPv6 (IA_NA). The rest of the /60
Hi Gert,
you are right its a bit unusual and you may very well consider it bad
practice and if I have enough time it will hopefully solve it in a
better way at some point.
The reasoning behind this is that this way the DHCPv6 (PD) server can
easily learn about the whole available prefix
Applied, thx.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Am 02.05.2014 21:00, schrieb Gert Doering:
Ah! So it's a reservation for downstream-DHCPv6-PD.
It's still slightly confusing, tbh, to see the ifconfig and route values
point the /60 towards the actual interface. But maybe that's just me :-)
- it certainly isn't causing problems, just to say
Hi Gert,
Am 02.05.2014 23:14, schrieb Gert Doering:
Hi,
On Fri, May 02, 2014 at 10:56:07PM +0200, Gert Doering wrote:
... so, something I am missing... :-/
Oh well. First thing is I should have looked at 'ifstatus wan_6' which
indeed tells me WAN is working:
root@OpenWrt:/etc/config#
Just did a quick test with hnet against ISC dhcp behaving the same
(IA_PD-only) and it worked out fine.
Am 03.05.2014 07:59, schrieb Steven Barth:
Hi Gert,
Am 02.05.2014 23:14, schrieb Gert Doering:
Hi,
On Fri, May 02, 2014 at 10:56:07PM +0200, Gert Doering wrote:
... so, something I am
Hi Gert,
well thanks for testing.
answers are inline.
Hi,
thanks for your help so far. (Side question: if people feel this is getting
off-topic for openwrt-devel, I'll take it offline. For now I keep the CC:
because I think other people might end up running into this, and google
might
Hi Gioacchino,
it seems the kernel expects a big-endian value as vlan protocol, so you
should probably try wrapping cfg-proto in htons when passing it to
nla_put_u16.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Hi Matti,
thanks for the patches. A few notes though:
I don't particularly like the dhcp-approach. Including the script
directly looks hackish and also it wouldn't work for DHCP and RA/DHCPv6
in parallel. Instead I would suggest to bring up the interface without
any addresses and at the end
Hello Developers,
it has been some time since our latest stable release, so we are
currently busy preparing the first RC for Barrier Breaker. But before we
want to do the actual builds we need to take care of the packages feed
which has been neglected for a quite a while. A lot of packages
Hi Kristian,
at first: thanks for your feedback. I really like the general idea of
this patch, however:
1) Instead of using the interface index to decide on interface metric, a
table-option is added to interfaces. This way, users are sure which tables will
be used for policy routing and can
Hi Thomas,
I don't think the DHCPv6 client is the right place to do this.
You should rather configure PPP and select the interface identifier in
its configuration as this patch would completely defeat the purpose of
IPv6CP.
Regards,
Steven
___
On 18.06.2013 01:15, Thomas Bächler wrote:
You're confusing me even more - how does the patch relate to ipv6cp?
In ipv6cp, I am assigned a link-local address by the provider. I may be
wrong, but doesn't my peer expect that I use this link-local address in
its routing table in order to
On 18.06.2013 14:32, Gert Doering wrote:
Hi,
On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote:
I think this change is useful (without having looked at the actual code),
for exactly these reasons. With the IPv6CP handshake, you'll arrive at
something the provider controls - but then
Thanks for the hint. It is fixed upstream now. I will update the OpenWrt
revision when some more bugs pile up.
Cheers,
Stevem
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 25.06.2013 00:15, Thomas Bächler wrote:
Am 18.06.2013 14:57, schrieb Steven Barth:
Allright fine, you guys have convinced me.
I just commited a modified version of that patch to trunk.
Please test it.
On AA, there's a missing line
proto_config_add_string ifaceid
Thanks for the report. It should be fixed now.
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Thanks. Should be fixed now.
Cheers,
Steven___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi,
thanks to you all for your contributions.
I've commited something based upon this in
https://dev.openwrt.org/changeset/37866
This also adds proper packaging for kernel-modules and iptables-modules.
I moved the IPv6-NAT stuff out of regular NAT-stuff as it doesn't really
fit in (many
I'm sorry but the @wan syntax does indeed work. It works for me and many
other people using the new IPv6 stack. Could it be that you are using an
old version of netifd for some reason? (e.g. you updated / installed
only some of the new IPv6 packages on top of the 12.09 release).
If there is
http://wiki.openwrt.org/doc/uci/network6#native.ipv6.connection
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi Bastian,
I just commited a fix although it wasn't really a race.
Please try with the latest revision.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi Nathan,
I've seen this being reported by someone else already a few months ago
also involving Comcast (
https://forum.openwrt.org/viewtopic.php?pid=191916#p191916 ). It seems
they have a rather weird way of sending out Router Advertisements every
3 seconds at some locations which is
Hi Nathan,
actually it's not that easy. Especially if the contents are the same
this means an update. This is because most contents of the RA contain a
validity timer in seconds.
Thus if you sent 2 successive RAs with the same contents with a 3 second
difference the second RA increases the
Hi Nathan,
I just pushed an update to netifd.
Could you please check if the current version improves behaviour for you?
Also alternatively could you please check in your /etc/config/6relayd if
compat_ula is set to 1 and if so remove it or set it to 0?
Cheers,
Steven
On 02.10.2013 07:35, Nathan Hintz wrote:
Hi Steven:
netifd eventually crashed:
Tue Oct 1 21:57:58 2013 daemon.notice netifd: wan6 (1382):
Segmentation fault
Could this be due to continuing to call system_add_address(dev, a_new);
without
ever calling system_del_address(dev,
Sorry about the fuzz and thanks for the patch.
Applied in r38287.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hello Hans,
thanks for the report. I put in on my todo list. I have a few other
netifd changes staged somehwere anyway and will hopefully be able fix
this issue soon.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Hi Bastian,
I recently added openssl as a generic build dependency for OpenWrt as
part of the new package signing infrastructure thus I don't think using
openssl sha256 is problematic.
Can you give an example please where there is an openssl without sha256
support?
Thanks,
Steven
Hello Hans,
I finally commited a netifd update yesterday which should take care of that.
Regards,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hello Everyone,
you may have noticed LuCI the Lua Configuration Interface in the official
release announcement for Kamikaze 8.08
As there was not much information about this project in the past and we
noticed several people asking in different places for it we like to make a
little
Hello wlanmac,
at first thank you for your feedback.
will it be difficult to remove overall or will the LuCI code be mixed up
with non-GUI scripts?
It's just a separate set of packages: not more, not less.
As for LuCI, I would like to know more about why Lua and hence LuCI? You
say It's not
Yeah, sounds like many scripting languages...
except shell ;-)
Agreed, there is always some distribution specific glue needed. I'm
leaning toward a 'meta configuration' (in XML) which can be edited,
verified, and translated into distro specific configurations.
Ah I see you added another
Hello Everyone,
much work has been done this week and thanks to your feedback and opinions we
are happy to inform you about the latest project updates.
After the recent discussions about user-friendly vs. full-featured interfaces
we decided to split up LuCI into two parts LuCI Administration
Try this:
uci add firewall rule
uci set [EMAIL PROTECTED]
uci set [EMAIL PROTECTED]
uci set [EMAIL PROTECTED]
uci set [EMAIL PROTECTED]
uci commit firewall
Greetings
Cyrus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Is it, or will it some day get Luci driven to operate as seamlessly as
native firmware upgrades?
Is this seamless enough:
http://dev.luci.freifunk-halle.net/sysupgrade.png
;-)
Greetings
Cyrus
___
openwrt-devel mailing list
thats why UCI was invented
I would have suggested some kind of on disk nvram emulation for such
non-nvram capable systems so that the nvram paradigm remains the same
for nvram capable systems and is emulated for others that have, say,
persistent disk.
Why emulate a 1 dimensional limited
NAK, this would break source-dest-routing for IPv6 (documentation seems
to be wrong here).
Maybe we should use RTA_PREFSRC for IPv4 and RTA_SRC for IPv6?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Thanks, applied.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
On 03.12.2014 11:15, Hans Dedecker wrote:
Config support to force the IGMP host version on device level; possible values
are:
1|igmpv1: IGMP version 1
2|igmpv2: IGMP version 2
3|igmpv3: IGMP version 3
Thanks Hans.
However, I don't really see the point of the string logic, it
On 03.12.2014 11:39, Hans Dedecker wrote:
Regarding the MLD version wouldn't it be preferable to have this as a
different UCI parameter as I could imagine different versions in use
for MLD and IGMP. Quite a lot of ISP's are still stuck to IGMPv2 in
their network while they're using MLDv2
Hi Tomer,
I am currently working on a kernel module which offloads traffic from
the Networking stack.
This is part of a project which optimizes IP forwarding for low end
routers that have weak CPU and low on memory.
Sounds interesting. Other approaches of speeding up forwarding are btw.
also
Hi Gergely,
my name is Gergely Kiss, I have recently started creating patches for openwrt
and I'm about to publish some packages to the packages repository (some ported
from oldpackages, others are brand new).
Sounds good, thanks. Please read and follow our guidelines when doing
pull
Hi Gergely,
this is the wrong place to post package-related patches and issues.
Please do a pull requests here instead
https://github.com/openwrt/packages/pulls
and for issues please use: https://github.com/openwrt/packages/issues
Cheers,
Steven
-level openwrt firewall is reloaded. In fact there is already a
user-script hook.
Cheers,
Steven
Best Regards,
Tomer
On Mon, Dec 15, 2014 at 9:18 AM, Steven Barth cy...@openwrt.org wrote:
Hi Tomer,
Regarding the firewall package - its probably a dumb question, but isn't
this the reason
applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
There were no firewall changes for quite a while really and IPv6
configuration hasn't been touched for quite a while either and if you
have ruled out the igmp_snooping as a source of error then thats a bit
confusing.
OpenWrt switched from using kernel-mode IPv6 RA handling (SLAAC) to
NAK, unless you deal with all the dnsmasq-dhcpv6 and dnsmasq-full
missing in opkg tickets afterwards ;)
On a more serious note, some people depend on the precompiled stuff and
they would probably not welcome that change all too much.
___
You can watch any repository you like. If something goes wrong its
probably either github's or your browser's (or its addons') fault.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
1 - 100 of 190 matches
Mail list logo
