[LEDE-DEV] [PATCH] wireguard: bump to 20180304
Changes: * queueing: skb_reset: mark as xnet This allows cgroups to classify packets. * contrib: embedded-wg-library: add ability to add and del interfaces * contrib: embedded-wg-library: add key generation functions The embeddable library gains a few extra tricks, for people implementing plugins for various network managers. * crypto: read only after init * allowedips: fix comment style * messages: MESSAGE_TOTAL is unused * global: in gnu code, use un-underscored asm * noise: fix function prototype Small cleanups. * compat: workaround netlink refcount bug An upstream refcounting bug meant that in certain situations it became impossible to unload the module. So, we work around it in the compat code. The problem has been fixed in 4.16. * contrib: keygen-html: rewrite in pure javascript * Revert "contrib: keygen-html: rewrite in pure javascript" We nearly moved away from emscripten'ing the fiat32 code, but the resultant floating point javascript was just too terrifying. * Kconfig: require DST_CACHE explicitly Required for certain frankenkernels. * compat: use correct -include path Fixes certain out-of-tree build systems. * noise: align static_identity keys Gives us better alignment of private keys. * wg-quick: if resolvconf/interface-order exists, use it * wg-quick: if resolvconf/run/iface exists, use it Better compatibility with Debian's resolvconf. * contrib: add extract-handshakes kprobe example Small utility for extracting ephemeral key data from the kernel's memory. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- package/network/services/wireguard/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/network/services/wireguard/Makefile b/package/network/services/wireguard/Makefile index b45923596c..ba9fafa87f 100644 --- a/package/network/services/wireguard/Makefile +++ b/package/network/services/wireguard/Makefile @@ -11,12 +11,12 @@ include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=wireguard -PKG_VERSION:=0.0.20180202 +PKG_VERSION:=0.0.20180304 PKG_RELEASE:=1 PKG_SOURCE:=WireGuard-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=https://git.zx2c4.com/WireGuard/snapshot/ -PKG_HASH:=ee3415b482265ad9e8721aa746aaffdf311058a2d1a4d80e7b6d11bbbf71c722 +PKG_HASH:=efb1652f0da67fb2731040439b6abb820a5e2f1bc177aa15c5dce68ea3327787 PKG_LICENSE:=GPL-2.0 Apache-2.0 PKG_LICENSE_FILES:=COPYING -- 2.16.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
Hi Stijn, That was quick. Thanks! Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
On Sun, Oct 8, 2017 at 3:04 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > In that case, I'll take a closer look at the patches LEDE ships for > the package and merging them into the upstream repo. If you don't wind up removing that, future packages won't need to include that patch any longer: https://git.zx2c4.com/ipset-dns/commit/?id=ade2cf88e933f4f90451e0a6171f0aa4a523f989 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
On Sun, Oct 8, 2017 at 3:02 PM, Florian Fainelliwrote: > Still using ipset-dns here, thanks for the reminder, I should probably > migrate to dnsmasq now to achieve the same goals. There may be other > users out there though ;) Cool, okay, good to know! In that case, I'll take a closer look at the patches LEDE ships for the package and merging them into the upstream repo. Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] ipset-dns - does anybody actually use this?
Hey, I'm upstream on the ipset-dns project: https://git.zx2c4.com/ipset-dns/about/ It's a part of a core LEDE repo: https://git.lede-project.org/?p=source.git;a=tree;f=package/network/services/ipset-dns Pretty soon after I wrote ipset-dns, I thought it was kind of a hassle, and so I rewrote the whole thing instead as a patch to dnsmasq, submitted it upstream to Simon, and it was accepted. This seems to work much more easily than my original ipset-dns, and I imagine it's what most people use for that kind of thing on LEDE. Funny enough, when I look at the git repo for ipset-dns, on February 15, 2013, I made the "initial commit." On the 23rd, 8 days later, I added a note telling people to use dnsmasq instead. In spite of this, it went into LEDE, and I assume people used it in between then and whenever my patch inside of dnsmasq was released in a version that was inside of LEDE. But this was all years ago. So, I'm wondering: does anybody actually use ipset-dns? Does it have any utility? As cool as it is having a piece of my code in the core LEDE repo, I can't help wondering if it should be removed... If somebody still uses it, great; that's the beauty of open source. But if not, it's something to think about removing maybe. Just FYI. Regards, Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] per-cpu IRQ stack on MIPS
Here's the raw diff of this series directly from -next, in case it helps: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/rawdiff/?id=3cc3434fd6307d06b53b98ce83e76bf9807689b9=fe8bd18ffea5327344d4ec2bf11f47951212abd0~ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] per-cpu IRQ stack on MIPS
On Sun, Jan 15, 2017 at 3:03 PM, Felix Fietkauwrote: > I'd like to run a few more tests today before I merge it, just to make > sure it doesn't break stuff for the release. Of course. Let me know if you run into any difficulties. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] per-cpu IRQ stack on MIPS
Hey Felix, On Wed, Jan 11, 2017 at 10:59 AM, Felix Fietkauwrote: >> It prevents crashes when lots of different networking drivers are >> stacked on top of eachother, like gre+l2tp+somethingelse. > I've pushed the backport of these changes to my staging tree at > https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary > > I've already tested it on a MT7621 board and it works fine, please test > it on more devices. It might be prudent to get this patch in before the freeze closes for the upcoming LEDE version. It's an important stability fix for MIPS. Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?
Actually, > I think the problem with wireguard in github issue 3790 [1] is that > wireguard requires NFPROTO_{IPV4,IPV6} "hashlimit" module and > netfilter subsystem will try to load ipt_hashlimit and ip6t_hashlimit > which are aliases of xt_hashlimit, but we have aliases along with > other modinfoinfo stripped from kernel modules with patch > 204-module_strip.patch. If indeed the alises are being stripped from those modules, then the kernel's auto module loader won't find them, and that would indeed be a problem. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?
Hey all, It's not possible to depend directly on xt_hashlimit, because we don't use any symbols in it. Instead, Netfilter forces us to go through helper function, which load xt_hashtable dynamically. This works fine on most systems, where the kernel calls out to modprobe at runtime in order to get xt_hashtable. However, OpenWRT doesn't ship modprobe (I think?), so there's no kernel autoloading. Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] per-cpu IRQ stack on MIPS
Hey folks, You might considering backporting this patchset to the LEDE/OpenWRT kernel: http://www.spinics.net/lists/mips/msg65937.html It prevents crashes when lots of different networking drivers are stacked on top of eachother, like gre+l2tp+somethingelse. Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: enable pcrypt
On Wed, Nov 16, 2016 at 8:35 PM, Felix Fietkauwrote: > It's in my staging tree and will make it to the main repo soon. Good to hear. Thanks. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: enable pcrypt
Hi Felix, Patchwork was changed to "accepted" -- http://patchwork.ozlabs.org/patch/694517/ -- but this hasn't shown up in the actual LEDE repo. What's up? Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kernel: enable pcrypt
This is a powerful API for parallel crypto from which many other modules can benefit. It only winds up being turned on on SMP systems, which means this adds 0 bytes to the kernel on tiny machines, while only adding a small bit to SMP systems for big performance improvements. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- target/linux/generic/config-3.18 | 2 +- target/linux/generic/config-4.1 | 2 +- target/linux/generic/config-4.4 | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/target/linux/generic/config-3.18 b/target/linux/generic/config-3.18 index 8b70c7d..c61a4b3 100644 --- a/target/linux/generic/config-3.18 +++ b/target/linux/generic/config-3.18 @@ -762,7 +762,7 @@ CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_PCOMP is not set # CONFIG_CRYPTO_PCOMP2 is not set -# CONFIG_CRYPTO_PCRYPT is not set +CONFIG_CRYPTO_PCRYPT=y # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set diff --git a/target/linux/generic/config-4.1 b/target/linux/generic/config-4.1 index 68bd849..4fae342 100644 --- a/target/linux/generic/config-4.1 +++ b/target/linux/generic/config-4.1 @@ -792,7 +792,7 @@ CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_PCOMP is not set # CONFIG_CRYPTO_PCOMP2 is not set -# CONFIG_CRYPTO_PCRYPT is not set +CONFIG_CRYPTO_PCRYPT=y # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set diff --git a/target/linux/generic/config-4.4 b/target/linux/generic/config-4.4 index 28e7068..843154d 100644 --- a/target/linux/generic/config-4.4 +++ b/target/linux/generic/config-4.4 @@ -791,7 +791,7 @@ CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_PCOMP is not set # CONFIG_CRYPTO_PCOMP2 is not set -# CONFIG_CRYPTO_PCRYPT is not set +CONFIG_CRYPTO_PCRYPT=y # CONFIG_CRYPTO_POLY1305 is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set -- 2.10.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: expose configuration for padata
On Fri, Nov 11, 2016 at 5:06 PM, Baptiste Jonglezwrote: > Looks good to me, I didn't see an increase in kernel size when selecting > this option on ar71xx (I looked at the size of > "build_dir/target-mips_24kc_musl-1.1.15/linux-ar71xx_generic/linux-4.4.30/vmlinuz") Right. What happens on this platform is since there's no SMP, that option gets automatically deactivated, so the net effect is zero. On SMP systems, it forces CONFIG_PADATA to be selected, which is the option we actually want. > > However, I had to do a "make clean", because selecting > KERNEL_CRYPTO_PCRYPT does not cause all kmod packages to be rebuilt for > the new kernel config: This is what I've seen happen too when changing any kernel related options at all. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kernel: expose configuration for padata
The padata API is a powerful framework for doing parallel jobs inside the kernel, on which various modules in the package feed can depend, such as WireGuard. There is no item text, so that it does not show up in menuconfig, as this is only supposed to be an option selected as a dependency. There as already precedent for this behavior, with CONFIG_KERNEL_RELAY, on which several packages depend. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- config/Config-kernel.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/config/Config-kernel.in b/config/Config-kernel.in index d8ca76c..9aca2a0 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -224,6 +224,9 @@ config KERNEL_PROC_PAGE_MONITOR config KERNEL_RELAY bool +config KERNEL_CRYPTO_PCRYPT + bool + config KERNEL_KEXEC bool "Enable kexec support" -- 2.10.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] wireguard: select parallel encryption engine
On non SMP systems, this doesn't wind up doing anything or adding any code at all. On SMP systems, this adds a little bit of code, and makes encryption use all cores. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- net/wireguard/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/wireguard/Makefile b/net/wireguard/Makefile index 7387673..c5c014c 100644 --- a/net/wireguard/Makefile +++ b/net/wireguard/Makefile @@ -89,7 +89,7 @@ define KernelPackage/wireguard CATEGORY:=Kernel modules SUBMENU:=Network Support TITLE:=Wireguard kernel module - DEPENDS:=@IPV6 +kmod-udptunnel4 +kmod-udptunnel6 +kmod-ipt-hashlimit + DEPENDS:=@IPV6 +@KERNEL_CRYPTO_PCRYPT +kmod-udptunnel4 +kmod-udptunnel6 +kmod-ipt-hashlimit FILES:= $(PKG_BUILD_DIR)/src/wireguard.$(LINUX_KMOD_SUFFIX) AUTOLOAD:=$(call AutoLoad,33,wireguard) endef -- 2.10.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev