Re: [WireGuard] Seeking Ubuntu PPA Maintainer

[Daniel Kahn Gillmor]

Hi Egbert--

On Wed 2016-11-16 09:34:12 +0900, Egbert Verhage wrote:
> I just copyed the debian folder of the experimental package of the
> debian repo.

I'm the package maintainer in debian.  Glad to hear that my packaging
work has been useful for you.

If you're tracking the debian packaging, you might also be interested in
the revision control history of it:

git clone https://anonscm.debian.org/git/collab-maint/wireguard.git

If you find that there are specific changes to the debian packaging that
you find useful when packaging for ubuntu, i'd be happy to hear about
them.  Also, if you run into packaging difficulties and want someone to
brainstorm with, feel free to reach out.

Regards,

--dkg


signature.asc
Description: PGP signature
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [WireGuard] Seeking Ubuntu PPA Maintainer

[Dan Luedtke]

Hi Egbert,

thank you for maintaining the PPA. I am using it and it works great on my 
servers. I wish the version bumps would happen more often as long as the code 
is experimental. Testing "old" code does not make too much sense (I think we 
mailed a couple of days ago about that). Other from that I strongly support 
Egbert's PPA becoming the official one. Had no problems so far and I like the 
test setup.

Cheers,

Dan

> On 16 Nov 2016, at 02:31, Jason A. Donenfeld  wrote:
> 
> Hey Egbert,
> 
>> On Wed, Nov 16, 2016 at 1:34 AM, Egbert Verhage  wrote:
>> I mailed/called with one of the sys admins and discussed with him about the
>> problem in the AVX2 extention.
>> I think I'm going to mail/call the hosting company again.
> 
> It seems like the crux of the issue is that if they disable AVX2
> instructions, they need to make this known in the CPUID. Otherwise the
> operating system will assume it's there when it isn't.
> 
>> Can give you a vps if you want to. Just 3 euro the month.
> 
> See the attached tarball. Compile the kernel module in there and load
> it BEFORE WireGuard. You might have to manually unload wireguard for
> this to work: "rmmod wireguard && insmod ./avx2disabler.ko && modprobe
> wireguard", for example. It should disable avx2 inside the kernel,
> solving the issue.
> 
> Jason
> 
> ___
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/wireguard

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [WireGuard] Seeking Ubuntu PPA Maintainer

[Egbert Verhage]

On 2016-11-16 01:12, Jason A. Donenfeld wrote:
> Hey Egbert,
>
> Great to see! How much does this deviate from debian's? As far as I
> can tell, you should be able to keep things basically the same.
I just copyed the debian folder of the experimental package of the
debian repo.
Left all the copyrights intact and added my name.
> This isn't okay. Downstream packages really shouldn't be applying
> patches like that. If you revert that, I can list this as the primary
> PPA for WireGuard. With that said, let's actually try to fix this
> issue for good...
Can't agree more, but I wanted to test it and deploy it with ansible,
that was the simplest solution.
> AVX2 is advertised through CPUID. Is it possible that your VPS passes
> through the CPUID from the host while not supporting all instructions?
> Or perhaps, rather, fakes a CPUID that isn't the host's, while only
> supporting instructions of the host? Very mysterious. What hosting
> company is this? Is there a chance I can poke around at this setup? Do
> you know if it's KVM or Xen or VMWare or something else?
It is hosted at PCexterme, dutch company. Cheap and good service. The
use KVM with CloudStack on top of it.
I mailed/called with one of the sys admins and discussed with him about
the problem in the AVX2 extention.
He told me that they disabled AVX already because of the raid 6 system.
It crashes the whole KVM host.

Can give you a vps if you want to. Just 3 euro the month.
> If it turns out that your VPS host just does something horrible, I'll
> look for a way to globally disable kernel usage of AVX2, without
> having to patch WireGuard like that.
If I can found the kernel parmameter for that, I will.
> If it's particular to the host,
> perhaps we can come up with either a particular kernel module to do
> the disabling, or some ungodly hack to /dev/kmem...
You are going above my intellect of the kernel at this point.
>  Are you compiling
> your own kernel for this system, or just using stock Ubuntu kernel?
No not yet. I was planning on this email to tell your my ppa / kernel
problem.
> I'm pretty sure, by the way, that we're using the right detection
> function within WireGuard, seeing as every other place in the tree
> uses the same thing:  
* lib/raid6/avx2.c
* 36: return boot_cpu_has(X86_FEATURE_AVX2) &&
boot_cpu_has(X86_FEATURE_AVX);
I think I'm going to mail/call the hosting company again.
> Thanks a bunch for helping out.
You to with this great this VPN.
> Jason
> ___
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/wireguard

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [WireGuard] Seeking Ubuntu PPA Maintainer

[Jason A. Donenfeld]

Hey Egbert,

Great to see! How much does this deviate from debian's? As far as I
can tell, you should be able to keep things basically the same.


> Testing it constantly on 4 of my servers and works it great!
Happy to hear that.

> Even added a patch for ifupdown to setup WireGuard in
> /etc/network/interfaces
Cool!


> The only downside is that I disabled AVX2 cpu extention in the code,
> because of kernel panics on VPS's by a hosting company
> (https://eggiecode.org/wg-kernel-panic.png).

This isn't okay. Downstream packages really shouldn't be applying
patches like that. If you revert that, I can list this as the primary
PPA for WireGuard. With that said, let's actually try to fix this
issue for good...

AVX2 is advertised through CPUID. Is it possible that your VPS passes
through the CPUID from the host while not supporting all instructions?
Or perhaps, rather, fakes a CPUID that isn't the host's, while only
supporting instructions of the host? Very mysterious. What hosting
company is this? Is there a chance I can poke around at this setup? Do
you know if it's KVM or Xen or VMWare or something else?

If it turns out that your VPS host just does something horrible, I'll
look for a way to globally disable kernel usage of AVX2, without
having to patch WireGuard like that. If it's particular to the host,
perhaps we can come up with either a particular kernel module to do
the disabling, or some ungodly hack to /dev/kmem... Are you compiling
your own kernel for this system, or just using stock Ubuntu kernel?

I'm pretty sure, by the way, that we're using the right detection
function within WireGuard, seeing as every other place in the tree
uses the same thing: https://paste.kde.org/pdljfawf7/79eh62 .

Thanks a bunch for helping out.

Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [WireGuard] Seeking Ubuntu PPA Maintainer

[Egbert Verhage]

On 2016-11-15 21:44, Jason A. Donenfeld wrote:
> Hey folks,
>
> Looks like there are various Ubuntu PPAs for WireGuard floating
> around. I'd like to officially endorse one on the install section of
> the website. Is anybody interested in being the Ubuntu downstream for
> WireGuard?
>
> Thanks,
> Jason
> ___
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/wireguard

Hey Jason,

I'm trying to maintain one now, but it is my first one and trying to
keep it up to date.
https://launchpad.net/~eggiecode/+archive/ubuntu/wireguard

Testing it constantly on 4 of my servers and works it great!
Even added a patch for ifupdown to setup WireGuard in
/etc/network/interfaces

The only downside is that I disabled AVX2 cpu extention in the code,
because of kernel panics on VPS's by a hosting company
(https://eggiecode.org/wg-kernel-panic.png).

Greetz,
Egbert Verhage

Below example config of wireguard in network/interfaces

iface wg0 inet wireguard
netmask 255.255.255.0
address 192.168.2.254
wg_config /etc/network/wg0.ini

up ip -4 route add 10.20.1.0/24 dev wg0
pre-down ip -4 route del 10.20.1.0/24 dev wg0
up ip -4 route add 10.20.3.0/24 dev wg0
pre-down ip -4 route del 10.20.3.0/24 dev wg0
up ip -4 route add 10.20.2.0/24 dev wg0
pre-down ip -4 route del 10.20.2.0/24 dev wg0

iface wg0 inet6 wireguard
netmask 64
address fd4a:2831:fc20:f528:fe::1

up ip -6 route add 2001:41d0:2:5c39::/64 dev wg0
pre-down ip -6 route del 2001:41d0:2:5c39::/64 dev wg0
up ip -6 route add 2a00:f10:700:5f::/60 dev wg0
pre-down ip -6 route del 2a00:f10:700:5f::/60 dev wg0
up ip -6 route add 2001:41d0:d:2a83::/64 dev wg0
pre-down ip -6 route del 2001:41d0:d:2a83::/64 dev wg0

(Forgot to send it to the mailinglist.)

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard

[WireGuard] Seeking Ubuntu PPA Maintainer

[Jason A. Donenfeld]

Hey folks,

Looks like there are various Ubuntu PPAs for WireGuard floating
around. I'd like to officially endorse one on the install section of
the website. Is anybody interested in being the Ubuntu downstream for
WireGuard?

Thanks,
Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [WireGuard] Wireguard in OpenWRT/LEDE: FYI: Pull Request

[Dan Lüdtke]

Hi,

thanks for the various feedback, guys! Here is the next round:

https://github.com/openwrt/packages/pull/3514
and
https://github.com/openwrt/luci/pull/852

Cheers,

Dan

> On 13 Nov 2016, at 23:52, Dan Lüdtke  wrote:
> 
> Hi again,
> 
> here is the pull request for LuCi:
> https://github.com/openwrt/luci/pull/848
> 
> Please support this pull request as well.
> 
> Thanks for all the beta testers and also to Jason and Baptiste for their help.
> 
> It was a great pleasure supporting this project.
> 
> Cheers,
> 
> Dan
> 
> 
>> On 13 Nov 2016, at 23:35, Dan Lüdtke  wrote:
>> 
>> Hi all,
>> 
>> first step of OpenWRT/LEDE integration is making sure the helper script for 
>> configuring the interface is installed. The corresponding pull request can 
>> be found here:
>> https://github.com/openwrt/packages/pull/3512
>> 
>> Please support this pull request.
>> Once it is accepted, the GUI (luci) will follow.
>> 
>> Thanks,
>> 
>> Dan
>> ___
>> WireGuard mailing list
>> WireGuard@lists.zx2c4.com
>> http://lists.zx2c4.com/mailman/listinfo/wireguard
> 
> ___
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/wireguard

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

[David Ahern]

On 11/15/16 7:45 AM, Hannes Frederic Sowa wrote:

>> @@ -1012,6 +1013,16 @@ static int ip6_dst_lookup_tail(struct net *net,
>> const struct sock *sk,
>>  }
>>  #endif
>>
>> +addr_type = ipv6_addr_type(>saddr);
>> +if (addr_type == IPv6_ADDR_ANY)
>> +return 0;
>> +
>> +err = -EINVAL;
>> +bind_to_dev = __ipv6_addr_src_scope(addr_type) <=
>> IPV6_ADDR_SCOPE_LINKLOCAL;
>> +if (!ipv6_chk_addr(net, >saddr, bind_to_dev ?
>> (*dst)->dev : NULL, 0) &&
>> +!ipv6_chk_acast_addr_src(net, (*dst)->dev, >saddr))
>> +goto out_err_release;
>> +
>>  return 0;
>>
>>  out_err_release:
>>
> 
> We should not use (*dst)->dev, as this is the resulting device after the
> lookup and not necessarily corresponds to the device the user asked for.

To be consistent with IPv4 the saddr check is done before the lookup and dst 
and flow oif should not be used. Handling LL addresses are trickier and perhaps 
this is not the right place to enforce that check since it requires a specific 
device which is only really known after lookup. Why not add the if saddr is LL 
verification as part of the route selection? e.g, add something like 
rt6_device_match to ip6_pol_route (the device match call is only used for 
ip6_pol_route_lookup and not ip6_pol_route - why is that?).




___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

[Hannes Frederic Sowa]

Hey Jason,

On 15.11.2016 01:45, Jason A. Donenfeld wrote:
> I'll have a better look at this. Perhaps this should be modeled on
> what we currently do for userspace, which might amount to something
> more or less like:

Cool, thanks!

> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 6001e78..0721915 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -925,6 +925,7 @@ static int ip6_dst_lookup_tail(struct net *net,
> const struct sock *sk,
>  #endif
>  int err;
>  int flags = 0;
> +int addr_type, bind_to_dev;
> 
>  /* The correct way to handle this would be to do
>   * ip6_route_get_saddr, and then ip6_route_output; however,
> @@ -1012,6 +1013,16 @@ static int ip6_dst_lookup_tail(struct net *net,
> const struct sock *sk,
>  }
>  #endif
> 
> +addr_type = ipv6_addr_type(>saddr);
> +if (addr_type == IPv6_ADDR_ANY)
> +return 0;
> +
> +err = -EINVAL;
> +bind_to_dev = __ipv6_addr_src_scope(addr_type) <=
> IPV6_ADDR_SCOPE_LINKLOCAL;
> +if (!ipv6_chk_addr(net, >saddr, bind_to_dev ?
> (*dst)->dev : NULL, 0) &&
> +!ipv6_chk_acast_addr_src(net, (*dst)->dev, >saddr))
> +goto out_err_release;
> +
>  return 0;
> 
>  out_err_release:
> 

We should not use (*dst)->dev, as this is the resulting device after the
lookup and not necessarily corresponds to the device the user asked for.
Thus you need to pass in fl6.flowi6_oif. Thus to kill the necessary
ifindex->net_device lookup, I would suggest to move
ipv6_chk_addr_and_flags to use ifindex instead of net_device (0
corresponds to the net_device == NULL case). It seems to me this would
make the code easier. ipv6_chk_addr can simply pass down dev->ifindex to
ipv6_chk_addr.

Probably for checking anycast address you need to look up the
net_device, thus use dev_get_by_index_rcu. But probably the unicast
filter will already hit thus the whole traversing of anycast addresses
won't happen in normal cases. This could be separated to its own function.

In the non-strict case we don't necessarily need bind_to_dev?

Bye,
Hannes

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard