Re: Instability during large transfers
On 02/17/17 07:36, Jason A. Donenfeld wrote: Thanks very much for the excellent debugging output. I'll try to reproduce this as well on my systems. I assume you have not been able to reproduce this issue. The stack trace does indicate that the OOPS is happening in padata, not in wireguard, so I wonder if this is some bug caused either by grsecurity or by something else that was then fixed, but since your kernel is a bit old (4.7.10) maybe the fix didn't make it. In either case, I'll try to reproduce on that kernel and on newer kernels and will get back to you. I presume you have most PaX options turned on? Since this is on 4.7.10 (that is pre-4.9), this is not related to the other bug recently reported. I have disabled all grsecurity/PaX options in my kernel config (attached) and was able to trigger the bug again. This is with WireGuard commit f97b7e34bda436ac4572697a8770837eec7470b6 and debugging enabled. Again attached is the dmesg. I used the same SSH cat /dev/zero | dd of=/dev/null as before. This time I got "192656101376 bytes (193 GB, 179 GiB) copied, 41643 s, 4.6 MB/s" before the connection was broken. Interestingly, when the firewall came back up, I again had the issue where devices were continuing to handshake, but no data went through (and I could confirm this with the wireguard debug output in dmesg). I was unable to reproduce this issue with a spare laptop (ThinkPad X220), even after leaving it running for about three days. Since the router has a rather weak Atom CPU (http://ark.intel.com/products/78866), I suspect maybe a race condition due to the high load might be involved? Is there anything else I can do to debug this? Enable some kernel debugging option? Try a vanilla kernel? Try a newer kernel? Thanks, Jason Thanks, Samuel Holland panic_grsec_disabled.config.gz Description: application/gzip panic_grsec_disabled.dmesg.gz Description: application/gzip ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Encapsulation
Hi, Just out of curiosity, how does a "wireguard packet' look like on the wire ?? I'm guessing: Ethernet IP UDP |--| | IP | | WG payload | |--| What's in the box is encrypted Is that right ?? If not, what does it look like? Thanks, James ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ wireguard-devel] Purge old peer
On 01.03.2017 14:47, Nicolas Prochazka wrote: > Hello, > we hare using wireguard with a lot of client, with a lot of > dynamically generated peer key. > So we have, server side, a lot of peers that are become obsoletes > At this time, we delete peer , based on latest handshake > delta time > , with wg command. > Is the best thing to do ? is it possible to implement an auto purge of > old peer ? > > user handling, somehow "user-state" is something which may better parseable in terms of "wg" output - but to implement it in wireguard itself opens a whole lot of topics. And i prefer solutions build around the kernel modul itself and keep it quite impossible to trigger an invalidation of any peer (by manipulating time servers or exploiting some strange timeissues like leap seconds, timezones etc.) - especially since this is the special usecase for many2one connections, like your Serverexample. -- make the world nicer, please use PGP encryption ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
[ wireguard-devel] Purge old peer
Hello, we hare using wireguard with a lot of client, with a lot of dynamically generated peer key. So we have, server side, a lot of peers that are become obsoletes At this time, we delete peer , based on latest handshake > delta time , with wg command. Is the best thing to do ? is it possible to implement an auto purge of old peer ? Regards, Nicolas Prochazka. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RTNETLINK answers: Operation not supported
On 2017-02-28 17:08, William Clark wrote: > Hello, > > So I wanted to try WireGuard but unfortunately I can't get pas this part: > ip link add dev wg0 type wireguard. > > When ever I run the command "ip link add dev wg0 type wireguard" > I get the output: > RTNETLINK answers: Operation not supported > > This both happens on CentOS 7 and Fedora 25 and Ubuntu 16.04. > > CentOS 7 Kernel: > Linux hostname 3.10.0-514.6.2.el7.x86_64 #1 SMP Thu Feb 23 03:04:39 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > Fedora 25 Kernel: > Linux hostname 4.9.7-x86_64-X #2 SMP Thu Feb 2 15:43:55 EST 2017 x86_64 > x86_64 x86_64 GNU/Linux > > I've tried installing Linux headers too, but no luck and I've rebooted after > the upgrade too, and still no luck. > > Thanks a lot. If the following commands do not succeed, the wireguard kernel module was not installed correctly: $ modprobe wireguard $ lsmod | grep wireguard wireguard 126976 0 x_tables 28672 2 xt_hashlimit,wireguard ip6_udp_tunnel 16384 1 wireguard udp_tunnel 16384 1 wireguard ipv6 401408 162 nf_conntrack_ipv6,nf_defrag_ipv6,wireguard,bridge ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
