[LEDE-DEV] [PATCH] wireguard: bump to 20180304

2018-03-05 Thread Jason A. Donenfeld
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?

2017-10-08 Thread Jason A. Donenfeld
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?

2017-10-08 Thread Jason A. Donenfeld
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?

2017-10-08 Thread Jason A. Donenfeld
On Sun, Oct 8, 2017 at 3:02 PM, Florian Fainelli  wrote:
> 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?

2017-10-07 Thread Jason A. Donenfeld
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

2017-01-15 Thread Jason A. Donenfeld
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

2017-01-15 Thread Jason A. Donenfeld
On Sun, Jan 15, 2017 at 3:03 PM, Felix Fietkau  wrote:
> 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

2017-01-15 Thread Jason A. Donenfeld
Hey Felix,

On Wed, Jan 11, 2017 at 10:59 AM, Felix Fietkau  wrote:
>> 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?

2017-01-12 Thread Jason A. Donenfeld
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?

2017-01-12 Thread Jason A. Donenfeld
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

2017-01-10 Thread Jason A. Donenfeld
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

2016-11-16 Thread Jason A. Donenfeld
On Wed, Nov 16, 2016 at 8:35 PM, Felix Fietkau  wrote:
> 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

2016-11-16 Thread Jason A. Donenfeld
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

2016-11-14 Thread Jason A. Donenfeld
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

2016-11-11 Thread Jason A. Donenfeld
On Fri, Nov 11, 2016 at 5:06 PM, Baptiste Jonglez
 wrote:
> 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

2016-11-09 Thread Jason A. Donenfeld
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

2016-11-09 Thread Jason A. Donenfeld
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