Re: [OpenWrt-Devel] [PATCH 3/4] dnsmasq: Add config option to enable DNSSEC validation
Hi, On Sun, Jun 15, 2014 at 12:26 AM, Yousong Zhou wrote: > It will be more complete if dnsmasq-dhcpv6 is also covered by this > config option. Even better is letting this option depend on the > actual dnsmasq build variant selected. As mentioned in the cover letter: while the config option shows up between dnsmasq and dnsmasq-dhcpv6, it already influences both. I'm not sure how the configuration should look like... A submenu per variant? (your suggestion of 'letting this option depend on the actual dnsmasq build variant' sounds like that is what you mean?) A submenu below the variants to configure them all? In any case, I'm not sure how to solve that ;) Can you point me to an example or documentation how to express that? Thanks, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
Hi, On Sun, Jun 15, 2014 at 11:13 AM, Steven Barth wrote: > 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. I posted a patch to fix nettle-mini builds to the dnsmasq list. Once a fix is merged I'll include that in this package. The ipkg suggestion sounds nice, but, as Zhou mentioned, that'll give 4 variants already. Is that really what we want? Regards, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On Mon, Jun 16, 2014 at 10:12 AM, Andre Heider wrote: >> 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. > I posted a patch to fix nettle-mini builds to the dnsmasq list. Once a > fix is merged I'll include that in this package. > The ipkg suggestion sounds nice, but, as Zhou mentioned, that'll give > 4 variants already. Is that really what we want? 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. regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
Hi, thanks for this. my intention was more to add one build-variant dnsmasq-full with standard + dhcpv6 + authoritative + dnssec. As dnssec adds hundreds of KB of dependencies anyway I don't think the 10 or 20 KB of the other features make it particularly worse or worth adding variants 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 wrote: 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. I posted a patch to fix nettle-mini builds to the dnsmasq list. Once a fix is merged I'll include that in this package. The ipkg suggestion sounds nice, but, as Zhou mentioned, that'll give 4 variants already. Is that really what we want? Regards, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: RT-N56U support fixes and factory image creation
Hi Mikko,
On 11/06/2014 17:01, Mikko Hissa wrote:
> @@ -0,0 +1,28 @@ +--- a/drivers/mtd/mtdpart.c 2014-04-27
> 10:09:21.566294160 +0300 b/drivers/mtd/mtdpart.c 2014-06-09
> 11:27:48.952211672 +0300 +@@ -793,8 +793,11 @@ + { + struct { +
> __be32 magic; +- __be32 pad[2]; ++ __be32 pad0[2];
> + __be32
> size; ++ __be32 pad1[4]; ++ __be32 name[7]; ++
> __be32
> kern_size; + } hdr; +size_t len; + +@@ -804,7 +807,11 @@ + if
> (len != sizeof(hdr) || hdr.magic != cpu_to_be32(UBOOT_MAGIC)) +
> return; + +- len = be32_to_cpu(hdr.size) + 0x40; ++ if
> (hdr.kern_size != 0 && hdr.name[0] == 0) ++ len =
> be32_to_cpu(hdr.kern_size); ++else ++ len =
> be32_to_cpu(hdr.size)
> + 0x40; ++ + __mtd_add_partition(master, "rootfs", part->offset +
> len, +part->mtd.size - len, false); + }
This bit look weird. the kern_size field certainly is not part of the
standard uimage header can we be sure that this field will always be 0
for none rt-n56u units ?
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On Mon, Jun 16, 2014 at 10:15 AM, Nikos Mavrogiannopoulos wrote: > On Mon, Jun 16, 2014 at 10:12 AM, Andre Heider wrote: >>> 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. >> I posted a patch to fix nettle-mini builds to the dnsmasq list. Once a >> fix is merged I'll include that in this package. >> The ipkg suggestion sounds nice, but, as Zhou mentioned, that'll give >> 4 variants already. Is that really what we want? > > 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. DNSSEC support adds a dependency. Even with libnettle-mini that's already 167K on my ar71xx. But yes, with support compiled in its can be disabled at runtime, see patch 4. Regards, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
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 of the core or important services use nettle. It would be nice to see dnsmasq interacting with a more mainstream embedded crypto library like polarssl or so. Also I would probably let all the DNSSEC deployment and the dnsmasq implementation mature a bit more before considering to enable it by default for everyone. But thats just my personal opinion. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On Mon, Jun 16, 2014 at 10:31 AM, Steven Barth wrote: > 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 of the core or important services use nettle. It would be nice to see > dnsmasq interacting with a more mainstream embedded crypto library like > polarssl or so. 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. > Also I would probably let all the DNSSEC deployment and the dnsmasq > implementation mature a bit more before considering to enable it by default > for everyone. But thats just my personal opinion. Well, it will never mature if it is not distributed :) regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On Mon, Jun 16, 2014 at 10:16 AM, Steven Barth wrote: > my intention was more to add one build-variant dnsmasq-full with standard + > dhcpv6 + authoritative + dnssec. As dnssec adds hundreds of KB of > dependencies anyway I don't think the 10 or 20 KB of the other features make > it particularly worse or worth adding variants for every possible > combination. 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? Regards, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
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 + backed by a company there is more interest in avoiding another case of heartbleed or similar but I guess we will see about that. Companies are not necessarily evil. Plus nobody said anything about dropping nettle support. Maybe just a little abstraction layer for the crypto stuff would be useful so that other libraries can be used. Heck maybe even add openssl support. That is 10x bigger but still 100x more reusable in terms of other daemons but not necessarily a candidate for default builds either. Also I would probably let all the DNSSEC deployment and the dnsmasq implementation mature a bit more before considering to enable it by default for everyone. But thats just my personal opinion. Well, it will never mature if it is not distributed :) Well, you are not the one getting all the bugreports about mysterious DNS disfunction with certain zones then :P Anyway personally I would like to at least have prepackaged dnssec support ready for installation so people don't have to compile themselves thats one step closer to general adoption than just having a buildoption somewhere deep down in menuconfig. Once Andre sends his next batch of patches we can think about merging it, but that would mean I would have to move nettle to the core repo and adopt it myself since we don't want to have dependencies from core to any of the feeds. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
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 have standard, dhcpv6 and full. Does that make sense? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On 16.06.2014 10:40, Nikos Mavrogiannopoulos wrote: > On Mon, Jun 16, 2014 at 10:31 AM, Steven Barth wrote: >> > 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 of the core or important services use nettle. It would be nice to see >> > dnsmasq interacting with a more mainstream embedded crypto library like >> > polarssl or so. > 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. > according to https://polarssl.org/how-to-get you can use the polarssl library properly under copyleft GPL2. if they offer additional licenses does not matter. ..ede ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On Mon, Jun 16, 2014 at 10:52 AM, Steven Barth wrote: > >> 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 have standard, dhcpv6 and full. Does that make > sense? D'oh, got it now. Sounds good to me. I'll do just that for the next set. Thanks, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] AA: IPv6 bug on TP-Link TL-WR841N v8 (patch available)
Hi, There is a bug in AA regarding IPv6 multicast support for the AR9341 switch (at least on a TP-Link TL-WR841N v8 device). Basically, it breaks IPv6 Neighbour Discovery, which seriously limits IPv6 functionality. See this ticket: https://dev.openwrt.org/ticket/15448 In particular, a patch is available: https://dev.openwrt.org/attachment/ticket/15448/0001-AR934X-Enable-unicast-multicast-flooding-to-the-CPU-.patch Is it possible to apply this patch to the AA branch? I have been using this patch for two months now, applied to the latest AA, and it works fine. I've used it on multiple TL-WR841N v8, in particular during a large event with hundreds of IPv6 wireless clients. Thanks a lot, Baptiste pgp3WM377BUl9.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On Mon, Jun 16, 2014 at 10:53 AM, wrote: >> 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. > according to > https://polarssl.org/how-to-get > you can use the polarssl library properly under copyleft GPL2. if they offer > additional licenses does not matter. That's what I already mentioned. The difference with open-source software is the missing "how to contribute page" (I consider the presence of a developer community a vital part of being open source). Otherwise, tomorrow you could be left with a GPLv2 codebase that is outdated an unmaintained if the X company desires that the GPLv2 codebase they release is no longer a good marketing approach. Another risk is to wait for years (or eternity) to get features that paying customers get (see matrixssl). On Mon, Jun 16, 2014 at 10:51 AM, Steven Barth wrote: >> 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 + backed by a company >there is more interest in avoiding another case of heartbleed You could be right, but I'd expect a different set of bugs to be present rather than no bugs. Being commercial doesn't imply there are no bugs. My experience shows the contrary (and both openssl and gnutls are far from being non-commercial as they are backed from several companies that either contribute code or hire their developers). The advantage small implementations have initially over gnutls and openssl is the fact that they are smaller and support much less features, thus they are easy to check and have a smaller attack vector. Their disadvantage is that they need to get in par with the features of the other libraries (see for example how supporting cryptodev and modern algorithms improves performance in a small system [0], thus using a mainstream implementation pays off). In any case my opinion is biased as I am working on gnutls. regards, Nikos [0]. http://nmav.gnutls.org/2012/04/in-some-embedded-systems-space-may.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On 16.06.2014 11:56, Nikos Mavrogiannopoulos wrote: > On Mon, Jun 16, 2014 at 10:53 AM, wrote: >>> 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. >> according to >> https://polarssl.org/how-to-get >> you can use the polarssl library properly under copyleft GPL2. if they offer >> additional licenses does not matter. > > That's what I already mentioned. The difference with open-source > software is the missing "how to contribute page" (I consider the > presence of a developer community a vital part of being open source). > Otherwise, tomorrow you could be left with a GPLv2 codebase that is > outdated an unmaintained if the X company desires that the GPLv2 > codebase they release is no longer a good marketing approach. > Another risk is to wait for years (or eternity) to get features that > paying customers get (see matrixssl). > well, i guess our open-source definition differs here ;) i tend to use the definition of the open source initiative http://opensource.org/osd understandably you'd prefer maintained code. but in reality even big oss projects die or are split up or forked or, or, or.. so what is left is that you can take a past and current maintenance status as a variable in your decision making only, no more, no less. ..ede ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/4] dnsmasq: Add config option to enable DNSSEC validation
On Mon, Jun 16, 2014 at 09:57:20AM +0200, Andre Heider wrote: > Hi, > > On Sun, Jun 15, 2014 at 12:26 AM, Yousong Zhou wrote: > > It will be more complete if dnsmasq-dhcpv6 is also covered by this > > config option. Even better is letting this option depend on the > > actual dnsmasq build variant selected. > > As mentioned in the cover letter: while the config option shows up > between dnsmasq and dnsmasq-dhcpv6, it already influences both. > > I'm not sure how the configuration should look like... > A submenu per variant? (your suggestion of 'letting this option depend > on the actual dnsmasq build variant' sounds like that is what you > mean?) > A submenu below the variants to configure them all? > > In any case, I'm not sure how to solve that ;) Can you point me to an > example or documentation how to express that? I have the following sitting in my local tree for enabling ipset support of dnsmasq. But I am not sure how this should be adapted to get merged into the trunk if build variants are preferred over config options in the case of dnsmasq. +define Package/dnsmasq/config/Default + if PACKAGE_$(1) + config PACKAGE_dnsmasq_$(2)_ipset +bool "Build with ipset support." +default n + config PACKAGE_dnsmasq_$(2)_auth +bool "Build with the facility to act as an authoritative DNS server." +default n + endif +endef + +Package/dnsmasq/config=$(call Package/dnsmasq/config/Default,dnsmasq,nodhcpv6) +Package/dnsmasq-dhcpv6/config=$(call Package/dnsmasq/config/Default,dnsmasq-dhcpv6,dhcpv6) + Package/dnsmasq-dhcpv6/conffiles = $(Package/dnsmasq/conffiles) TARGET_CFLAGS += \ -ffunction-sections -fdata-sections \ - $(if $(CONFIG_IPV6),,-DNO_IPV6) -DNO_IPSET -DNO_AUTH + $(if $(CONFIG_IPV6),,-DNO_IPV6) \ + $(if $(CONFIG_PACKAGE_dnsmasq_$(BUILD_VARIANT)_ipset),,-DNO_IPSET) \ + $(if $(CONFIG_PACKAGE_dnsmasq_$(BUILD_VARIANT)_auth),,-DNO_AUTH) Regards. yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] Added luci configuration for ocserv
On Sat, 2014-06-07 at 00:19 +0200, Nikos Mavrogiannopoulos wrote: > > This applies to ocserv at the github packages repository of openwrt: > > https://github.com/openwrt/packages > > Hello any comments one the above two additions? I'm mostly worried how > can that be added to luci as these programs are in the extra packages of > openwrt. Is there a repository for extra luci modules as well? Hello, Any plans to adopt these patches to luci? I'm not sure which list is more appropriate for that. Initial openconnect support was already sent since 2012, but was never included. Is there a reason for that? I currently maintain them out-of-tree as patches at: https://github.com/nmav/luci-openconnect/commits/openconnect but it doesn't make much sense, as adding uci configuration to the packages without luci support only makes them more difficult to use. regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Patch] [Resend] Add terminfo file in ncurses
Didn't hear back on this, and realized I didn't quite format the previous email correctly. Ran into a problem SSHing into an Openwrt router from a Fedora machine. Fedora sets terminfo to xterm-256color, but ncurses installed in openwrt doesn't include that file in the firmware. This causes a few unintended problems, namely nano fails to launch. Attached patch adds xterm-256color to the files installed by ncurses. Signed-off-by: Jonathan Bennett diff --git a/package/libs/ncurses/Makefile b/package/libs/ncurses/Makefile index 62ffdfb..26b7bf5 100644 --- a/package/libs/ncurses/Makefile +++ b/package/libs/ncurses/Makefile @@ -101,7 +101,7 @@ ifneq ($(HOST_OS),FreeBSD) mv dir (echo -ne "\xdir"); \ done \ ) - for file in a/ansi d/dumb l/linux r/rxvt r/rxvt-unicode s/screen v/vt100 v/vt102 x/xterm x/xterm-color; do \ + for file in a/ansi d/dumb l/linux r/rxvt r/rxvt-unicode s/screen v/vt100 v/vt102 x/xterm x/xterm-color x/xterm-256color; do \ $(INSTALL_DIR) $(1)/usr/share/terminfo/`dirname file`; \ $(CP) $(PKG_INSTALL_DIR)/usr/share/terminfo/file \ $(1)/usr/share/terminfo/file; \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] /var/state/wireless not being updated any more?
On Thu, Jun 12, 2014 at 8:28 PM, Gui Iribarren wrote: > On 06/12/2014 09:13 PM, Shankar Unni wrote: > > Ping? > > > > How can I look up the current state of the various wireless interfaces > using "uci" now? > > > > http://wiki.openwrt.org/doc/uci/network#determining.linux.interface.names > > The uci state vars are deprecated and not used anymore for network > related information Quoting jow in the forum[0] > Use /lib/functions/network.sh: > > source /lib/functions/network.sh > > if network_get_ipaddr addr "wan"; then > echo "IP is $addr" > fi > Is this cached or refreshed every call? Can the IP/interface change in between network_get_ calls and I get stale data? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] /var/state/wireless not being updated any more?
Hi, the data is cached upon the first call. To force a resync, run "network_flush_cache". ~ Jow signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Howto force mips64
hello, I can be a beta test if you want :-) Enviada do meu iPhone > Em 04/06/2014, às 10:05, John Crispin escreveu: > > octeon is currently only partially working. we will push a fix to > trunk in the next few days. experimental patch is currently in > testing. please be patient for a few dyas > > >> On 04/06/2014 14:36, Edison Figueira Junior wrote: >> Howto force to use mips64 for target octeon? >> >> >> >> >> ___ openwrt-devel >> mailing list openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
