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
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
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
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
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
>>> 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
>
> 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
>> 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
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
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
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
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:
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
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
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
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
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
The OpenWrt developers are proud to announce the final release of OpenWrt Chaos
Calmer.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__| ||
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
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 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
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.
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
>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
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
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
> 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
> 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_
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'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
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
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
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
__
> 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
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
The OpenWrt developers are proud to announce the third release candidate of
OpenWrt Chaos Calmer.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__| |
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
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
__
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
__
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
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
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
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
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
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
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
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
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
The OpenWrt developers are proud to announce the first release candidate
of OpenWrt Chaos Calmer.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__| |_
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
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
> 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
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
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
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
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
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
_
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
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
>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
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
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
___
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
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
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)
>>>
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
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
The OpenWrt developers are proud to announce the first release candidate
of OpenWrt Chaos Calmer.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| || | | || _|| _|
|___|| __|_|__|__||||__| |_
Applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
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
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
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
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
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
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
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
Applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Since I avoid ULA like the plague, this probably won't be a problem
for me and global IPv6 addresses will be served. But I'm not convinced
that favoring a ULA prefix (if available) over an ip6prefix is best at
all times.
Nothing is favored, DHCPv6 just hands out ULAs only (if one is there).
still work (since only the ULA-address
cannot be changed immediately).
Is that okay with you or do you see any other issues?
Cheers,
Steven
On 26.03.2015 20:38, Arjen de Korte wrote:
Citeren Steven Barth :
This breaks clients that need fixed IPs (in my case, mostly webmail
clients).
I wonder
On 27.03.2015 10:41, Kevin Darbyshire-Bryant wrote:
On 26/03/2015 23:51, Steven Barth wrote:
Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support
downstream delegation and its DHCPv6 features aren't well integrated
if you have a dynamic prefix e.g. delegated from
The problem is that you try to be "smart" by abusing the ability to set
the address preferred lifetime lower than T1. I don't dispute that it
is allowed by the RFC, but it is definitely not recommended.
There is no formal requirement (not even a SHOULD) that says otherwise.
The recommendation
Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support
downstream delegation and its DHCPv6 features aren't well integrated if
you have a dynamic prefix e.g. delegated from your ISP.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-de
This breaks clients that need fixed IPs (in my case, mostly webmail
clients).
I wonder why they are so sensitive to source-address changes since their
old address is still valid and not deprecated so there is no need to switch.
I would gladly send the DHCPv6 address with 0 preferred lifetime
In that case, I have a lot of bug reports to file, because none of the
DHCPv6 clients I tried were happy with preferred lifetimes of 1 second
on their leases (which includes Windows 7, 8.1 and openSUSE 13.2).
Sorry, I cannot confirm this. I just tried it with both Windows 8.1 and
Debian test
Hello Arjen,
most likely, your DHCPv6 client implementation is faulty and you should
probably file a bug for more than one reason.
If the DHCPv6 server sends values for T1 and / or T2 which are valid the
client must honor them and not try to be "smart" about lifetimes of
addresses.
Besides
Try
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1 bat0'
option proto 'dhcp'
config interface lan6
option ifname @lan
option proto dhcpv6
# option reqprefix no (uncomment if you don't need an IPv6 delegated
prefix)
Cheers,
Stev
config interface 'wan6'
option proto 'static'
option ifname 'eth1'
option ip6addr '2001::50'
config interface 'lq'
option proto 'dslite'
option ip6addr '2001::100'
option peeraddr '2001::200'
option tunlink 'wan6'
In your dslite sectio
Please post:
your complete /etc/config/network
the output of "ubus call network.interface dump"
so we can see what's going on on your system.
Your problem description is not really exhaustive.
Also note that dslite doesn't support ipaddr or netmask parameters since
RFC6333 specifies fixed IPv4
Hello Jeff,
It's a bit of a shame it doesn't work with the current default uclibc,
however have you checked if it works with musl out of the box? That
being the other more embedded-friendly solution here.
Cheers,
Steven
___
openwrt-devel mailing l
Applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
All applied, thanks.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Thanks, applied.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
What does that "sleep 60" do for you here? It doesn't look very sane to me.
___
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
Our dnsmasq init script registers /tmp/dnsmasq.d as an additional
configuration dir, so you can place files there and restart it. However
I'm not sure as to how much we want netifd to do dnsmasq-specific stuff
or how we would do it.
Of course the bad thing here again is that dnsmasq doesn't su
On 05.01.2015 11:28, Russell Senior wrote:
"Steven" == Steven Barth writes:
Steven> Thanks, unfortunately this doesn't compile for me:
Can you email me your .config?
I'll confess I only test-built it with uClibc.
Thanks. That is usually sufficient, though we are think
Thanks, applied.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Thanks, unfortunately this doesn't compile for me:
ccache_cc -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wold-style-definition -Wformat=2 -O2 -Os -pipe
-mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves
-fhonour-copts -Wno-error=unused-but-set-variable -msof
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
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openw
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.
___
openwrt-de
1 - 100 of 204 matches
Mail list logo
