Re: MacOS app update needed

[Bruno]

Hi,

I'm sorry if my question was awkward. Like I said, it works well.

I never asked for useless development. I'm just surprised last commits 
are not included in a release.


We also had a constructive chat in November (with Diab Neiroukh) on this 
list. You made an appreciated change, but the question remained opened.


I really admire your work and simply asked if something was planned. I 
understand you have priorities and won't bother you any longer.


Regards.

Bruno

Le 22/09/2022 à 14:04, Lewis Donzis a écrit :

- On Sep 22, 2022, at 6:43 AM, Jason A. Donenfeld ja...@zx2c4.com wrote:

On Wed, Sep 21, 2022 at 10:22 AM Bruno  wrote:


Hi,

Windows Client project don't feel alive either. Last commit has 6 months
and last release is 9 month old.

Same, here https://git.zx2c4.com/wireguard-windows/log/ and here
https://github.com/WireGuard/wireguard-windows

Version 0.5.3 works well, but I suppose it can be even better!


That seems pretty uncalled for. Folks asking for a wireguard-apple
update have good reason to do so -- there are outstanding bugs and
pull requests. But for wireguard-windows/wireguard-nt? C'mon now --
that's received some *extremely* active development, stabilizing after
nearly weekly updates for some time. Are there outstanding pull
requests for it? So your note here really isn't appreciated. The
WireGuard project doesn't churn out code and updates just for the sake
of writing code and doing updates. Things need to have rationale.
There will be updates to wireguard-windows/wireguard-nt at some point
when development makes sense there. But right now? Is there something
pending? Instead maybe be thankful that that software has reached a
point of stability where project development energies can go into more
pressing tasks, such as wireguard-apple.

Jason


I could not agree more.  What a world we live in where code that hasn't been touched for 
a few months is considered stale, rather than being rewarded and appreciated for 
reliability and stability.  Jason, congratulations on not needing to touch that code for 
six months!  Much of the beauty of Wireguard is its simplicity, to the point that it can 
be done "right", and it really shouldn't need to be touched!

Re: MacOS app update needed

[Bruno]

Hi,

Windows Client project don't feel alive either. Last commit has 6 months 
and last release is 9 month old.


Same, here https://git.zx2c4.com/wireguard-windows/log/ and here 
https://github.com/WireGuard/wireguard-windows


Version 0.5.3 works well, but I suppose it can be even better!

Any plans for some update?

Regards

Bruno

Le 21/09/2022 à 09:52, Houman a écrit :

Hi Simon,

Not only that, even the repo
https://github.com/WireGuard/wireguard-apple hasn't been updated since
27 Sep 2021.
There are a number of useful contributions in the form of pull
requests waiting there to be approved for over 8 months.

The project feels abandoned, which is such a shame.

Regards,
Houman

Re: [Windows Client] Out of date Title scare my users

[Bruno UT1]

Hi,

I validate what Diab said. It's a good start, hoping option 5 will be 
possible later.


Thank you for changes.

Have a good day.

Le 26/11/2021 à 10:17, lazerl...@thezest.dev a écrit :
I assume you've chosen the "reword" route instead of any larger 
changes, for the better or worse (though as Bruno said, it would be 
great if 5) is considered somewhere down the line).


Since this route was chosen, I suggest that we also reword the update 
prompt itself as I feel that is equally responsible for users 
"freaking out". After all, it is literally telling users to contact 
their sysadmin instantly for each update. I propose something along 
the lines of the following patch (though I guess il8n will be a bit of 
a pain):


```
From 76ea8a81cf327527089bfea8209bf4f2faa1b6cf Mon Sep 17 00:00:00 2001
From: Diab Neiroukh 
Date: Fri, 26 Nov 2021 09:12:15 +
Subject: [PATCH] ui: Don't explicitly tell users to contact their 
sysadmin for

 updates.

The wording used here practically told users to instantly contact their
system administrators for every update. We can reword it to instead to
implicitly suggest that they contact their system administrator if
the update has not been applied for "a relatively long time".

Signed-off-by: Diab Neiroukh 
---
 ui/updatepage.go | 2 +-
 zgotext.go   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ui/updatepage.go b/ui/updatepage.go
index 96fc87f3..76a8dced 100644
--- a/ui/updatepage.go
+++ b/ui/updatepage.go
@@ -65,7 +65,7 @@ func NewUpdatePage() (*UpdatePage, error) {
 button.SetText(l18n.Sprintf("Update Now"))

 if !IsAdmin {
-    button.SetText(l18n.Sprintf("Please ask the system 
administrator to update."))
+    button.SetText(l18n.Sprintf("There is an update available. 
The system administrator should update soon."))

 button.SetEnabled(false)
 status.SetText(l18n.Sprintf("Status: Waiting for 
administrator"))

 }
diff --git a/zgotext.go b/zgotext.go
index efbb9a80..e35974aa 100644
--- a/zgotext.go
+++ b/zgotext.go
@@ -235,7 +235,7 @@ var messageKeyToIndex = map[string]int{
 "Packet with invalid IP version from 
%v":   215,

"Peer":  100,
 "Persistent 
keepalive:":    54,
-    "Please ask the system administrator to 
update.":   275,
+    "There is an update available. The system administrator should 
update soon.": 275,
 "Preshared 
key:":   51,
 "Protocol version must be 
1":   85,

 "Public key:":  46,

Re: [Windows Client] Out of date Title scare my users

[Bruno UT1]

Hi Diab,

Thank you for the detailed explanation.

My suggestion to add a new registry key seemed easy, but I understand a 
limited number of options is important.


From your alternatives :

1) Probably the easiest to implement. It's not my favorite, but it would 
be better no doubt.


2) I used Network Configuration Operators for everyone because no other 
option was available. It's not great as you said, but users need to 
start and stop the VPN sometimes. I can't remove all rights.


3) Do you suggest a "read only" interface ? I looks like the opposite of 
what I need, the less users see the better.


4) It seems pretty complicate for a small improvement. Like you I'm not 
fan, but why not if Jason like it. It can but combined with the first 
option.


5) I like this option, but I supposed it wasn't possible. If it is, a 
group that can only access to the list of tunnels and start or stop them 
is a good solution for my environment. Removing Network Configuration 
Operators rights would be an improvement.


To summarize, the option 5 is what I'm looking for from the beginning. 
But if it's to complicate (or impossible) to do, the first one looks 
like a good start.


Rewording can be done easily and quickly (before a better solution is 
chosen, if possible). In that case, I indicate that I mainly use the 
french localization (it explains my poor english language level). Maybe 
the french version seems more aggressive that the english one? I don't 
know who leads this language translation, but I suggest him (or her) to 
change the Windows title "Obsolète" (out of date) to something softer, 
or nothing in the title just the update tab.


Thank for your time too,

Bruno ANDRY


Le 25/11/2021 à 15:23, lazerl...@thezest.dev a écrit :

Dear Bruno,

Whilst I understand the frustration that having hundreds of users can 
cause, I don't believe simply reverting the change [as proposed by 
Jason] is the correct solution. I've come up with a few alternative 
solutions, but before I present them I'd just like to give a brief 
introduction into why I requested that change in the first place.


WireGuard on Windows exclusively provides a GUI to users of the 
Administrators group, as well as a limited GUI to users of the Network 
Configuration Operators group when the `LimitedOperatorUI` DWORD is 
set. The latter is helpful for users who wish to separate their 
personal and administrator accounts (to protect themselves against the 
plethora of UAC exploits, amongst other security issues) where 
otherwise the user would have to switch accounts to switch tunnels. 
However, the GUI shown to Network Configuration Operators lacked any 
information about updates. This lead to users in such setups to not be 
informed about any updates unless they switched out to the 
Administrator account and or kept an eye on the releases online. This 
is quite a problem as users could be running ancient versions of 
WireGuard for relatively long periods of time without the knowledge 
that they are doing so (some users may even assume WireGuard 
automatically updates). As such, I asked Jason if he could add the 
ability for non-admins to at least be informed of an update which lead 
to where we are today.


After speaking to Jason "off the mailing list", he stated he wouldn't 
like to add any more configuration options (via the Registry or within 
the GUI) nor any metadata to updates so bearing that in mind I came up 
with a few alternatives:


1) Rewording the update prompt for non-admins to appear less 
"aggressive". Currently, the prompt is "Please ask the system 
administrator to update." but this could be changed to something along 
the lines of "There is an update available. The system administrator 
will update when necessary." which should reduce most, if not all, 
users from contacting you unnecessarily. I can throw up a patch for 
this if Jason agrees.


2) Avoiding users seeing the UI at all, where unnecessary. If your 
users do not need *control* of the WireGuard configuration, then 
avoiding showing them the UI altogether could be an option. I don't 
know your system as well as you do, of course, so I can't assure that 
this solution is valid. However, having hundreds of users as Network 
Configuration Operators sounds a little "worrying" to me.


3) Showing an even more limited UI for unprivileged users. If the 
users still need some form of UI, then an even more limited UI could 
be presented to users not part of the Administrators nor the Network 
Configuration Operators groups. This would lack any form of control, 
and could still be under the same `LimitedOperatorUI` Registry DWORD, 
or not if is deemed "safe enough for the masses". If it is, you could 
say the semantics refer to "Limited [User or Network] Operator UI".


4) Updates could be hidden from the UI for

[Windows Client] Out of date Title scare my users

[Bruno UT1]

Hi,

Thank you again for your great work.

I have a suggestion for the Windows Client (maybe applicable for others).

I install Wireguard in my university on about 500 computers in 2 phases:

Phase 1 : validation

Phase 2 : production

So my end users have not, most of the time, the last version. They have 
"Out of date" in the Wireguard window title and some of them call the 
helpdesk, thinking they have a problem.


I can't deploy all versions as soon as they are available, I can't 
activate automatic update and my users have no admin rights. So my 
suggestion is to add a new admin registry key to hide update, or not 
check them at all.


Is that possible ?

Regards

Re: WireGuard with obfuscation support

[Bruno Wolff III]

On Mon, Sep 27, 2021 at 14:36:28 +0500,
 Roman Mamedov  wrote:

On Mon, 27 Sep 2021 04:14:35 -0500
Bruno Wolff III  wrote:


This isn't a simple problem. The assumption is that someone is seeing
your network traffic and blocking it.


The assumption is that there's an appliance at the ISP which has a DROP rule
for UDP with 4 fixed bytes at a fixed offset. It has five hundreds other rules
to process as well, so it can't spend "too much" time on specifically WG.


They are still going to see it  even if you disguise it.


With obfuscation there would be UDP packets of random junk, and it would be a
much harder job to come up with a rule to drop those without affecting
anything else.


If your ISP is blocking your Wireguard traffic call them up and complain.

Re: WireGuard with obfuscation support

[Bruno Wolff III]

On Mon, Sep 27, 2021 at 12:34:39 +0500,
 Roman Mamedov  wrote:

On Mon, 27 Sep 2021 02:11:30 -0500

Don't over-estimate the resources available to DPIs, if there aren't easy
ways to block, it might be almost as good as unblockable.

And it is far from all cases that hiding traffic would result in bad
consequences. Just hiding it enough so it evades the dumb automated filter,
many people will thank you.


If someone is having their Wireguard traffic blogged, there is a good 
chance that they will be negative consequences to trying to evade the 
block. Just getting detected will often be enough to trigger these 
consequences, even if the traffic is getting through.


This isn't a simple problem. The assumption is that someone is seeing 
your network traffic and blocking it. They are still going to see it 
even if you disguise it. So you are going to need to disquise it as 
something that whoever is watching isn't going to care about. That 
is going to vary a lot depending on who is watching. You may also need 
to hide who you are communicating with. In some cases that will be even 
more important.


There are going to be a number of ways to detect Wireguard traffic and 
it is pretty unlikely that the bar for detection can be raised enough to 
be relevant with a few simple changes to the protocol.


This suggest that Wireguard is not the correct place to be doing these 
things. As suggested in another followup, this fits a lot closer to 
tor's mission and that would probably be a better place to look for 
help.

Re: WireGuard with obfuscation support

[Bruno Wolff III]

On Mon, Sep 27, 2021 at 09:53:08 +0900,
 Nico Schottelius  wrote:


I'd appreciate if wireguard upstream would take this in, maybe even
supporting multiple / dynamic listen ports.


The problem is mostly orthogonal to Wireguard. There isn't going to be a 
one size fits all solution for hiding traffic. Failures in hiding traffic 
are potentially very bad for individuals. As such general solutions are 
not something you can recommend universally to people, as amateurs are 
not going to be able to make good decisions about the risks and some may 
get themselves tortured and killed.


This may not be something the developers for Wireguard want to be 
responsible for.

Windows Client - issue with LimitedOperatorUI rights

[Bruno UT1]

Hi !

I install Wireguard Client on Windows 10 systems.

My users are not administrators, so the registry key LimitedOperatorUI 
is set to 1.


My issue is that the client has to run at least once as administrator to 
work for "Network Configuration Operators".


My script adds users to the administrative group, create the registry 
key then installs Wireguard Client:


 - If i don't use the parameter |DO_NOT_LAUNCH, |I have a popup telling 
me I need administrator rights. I don't want that popup, be everything 
works after a reboot.


 - If I use the parameter |DO_NOT_LAUNCH,| ||I don't have the popup but 
Wireguard don't start, even after a reboot. If I run Wireguard as 
administrator, it's unlocked for other users.


 - A third possibility is to install the client after a reboot, so the 
rights are good, |DO_NOT_LAUNCH |is not needed and no popup appears. But 
I don't want to force that reboot (I use SCCM and it don't like reboots 
before install is complete).


So I think there is a first start issue that needs administrator rights 
even with LimitedOperatorUI  active.


Regards,

Bruno

ps: I send another message (06/28) for another issue. I received "Your 
message to WireGuard awaits moderator approval" but message isn't posted 
and i got no notification from the moderator. Am I doing something wrong ?

||

Windows Client - Issue with Tray Icon

[Bruno UT1]

Hi Wireguard Community!

I think I found a small bug with Wireguard Windows Client. I made tests 
with version 0.3.14, 0.3.15 and 0.3.16 with the same behavior.


My users are not administrators, so the registry key LimitedOperatorUI 
is set to 1.


I made a script with wireguard.exe /installtunnelservice to 
automatically open the tunnel on some conditions. The script runs as 
administrator.


When the script starts, the tunnel is opened and the status is Active in 
the main Window but the stays off on the tray.


If the computer reboot, everything is back to normal but I can't force a 
reboot.


Without the reboot, if the user try to activate the tunnel from the tray 
in fact the already opened tunnel is closed. After that, the tray has 
the good status again, but it disturbs the users.


It's probably the fact that two distinct users are involved. Is there a 
possibility to synchronize the status?


Thank you for this great VPN,

Regards.

Bruno

Re: Wireguard not available for CentOS Stream

[Bruno Wolff III]

On Mon, Jan 04, 2021 at 13:42:22 -0600,
 Joe Doss  wrote:

On 1/4/21 1:20 PM, Jack Craig wrote:

how is fedora looking? is it stable enough for a small home network?


It's in the Fedora kernel and I use it daily. It works great and it is
very stable.


Wireguard works fine in Fedora. I have two laptops that route everything 
but dhcp to my home router (no matter what network they are on) via 
a wireguard tunnel. My home router provides them with endpoints that have 
static IP addresses. I also use it for my work desktop so that I can reach it 
from home even though it is behind NAT.

Re: WireGuard connecting hosts WAN->LAN

[Bruno Wolff III]

On Sat, Mar 14, 2020 at 16:33:44 +0100,
 Germano Massullo  wrote:

A simple question to Wireguard developers, since while asking for help
in OpenWRT forum[1] I have been told that I am asking a thing that
Wireguard cannot do, so I want to ask upstream if it is possible or not

Scenario:
A = internet (WAN) host (WireGuard IP 10.1.1.3)
B = OpenWRT router (WireGuard IP 10.1.1.1)
C = LAN host (WireGuard IP 10.1.1.2)

I want to:
1) connect A to C passing through B. I don't want to expose C to
internet at all, (so no things like port forwarding)
2) A must have C public key (and viceversa), so in case of B being
compromised, the A<->C VPN will not be compromised.

In a few words, I want B to just route forwards packages from A to C.


This set of requirements seems odd.
Do you not trust C to be able to properly ignore unwanted packets?

It is possible to have C ignore layer 3 traffic (DHCP traffic is special) 
that is not using the tunnel. Inbound you block all traffic not 
destined for the tunnel's port. Outbound you block all traffic not 
tagged as tunnel traffic. (Wireguard provides a way to tag tunnel traffic.) 
The default route should be through the tunnel. Tunnel traffic should be 
routed through B. The configuration gets trickier if you want to send 
traffic to A's external address as then you have a routing dependency not 
based on the destination address. You can do this by having two routing 
tables using the tag to pick which table gets used.

Wireguard is now in Linus' tree

[Bruno Wolff III]

Linus pulled in net-next about a half hour ago. So WireGuard is now 
officially upstream. Yeah!

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

wireguard-tools and "make all"

[Bruno Wolff III]

Is "make all" intentionally not provided in wireguard-tools? While you can 
do "make" instead of "make all", you need to run make twice to do 
the equivalent of "make clean all".

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

Re: ENDPROC and ENTRY changing in 5.5

[Bruno Wolff III]

On Thu, Dec 05, 2019 at 16:11:50 +0100,
 "Jason A. Donenfeld"  wrote:

Thanks. Fixes for this and two other 5.5 changes are in the master branch.


Thanks. I confirmed it builds now. I'll be testing that it works in a few 
hours when I get back. If it doesn't, I'll let you know.

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

ENDPROC and ENTRY changing in 5.5

[Bruno Wolff III]

There are a few commits changing ENTRY to SYM_FUNC_START and ENDPROC 
to SYM_FUNC_END and a few other related changes.

A few example commits authored by Jiri Slaby:
6dcc5627f6aec4cb1d1494d06a48d8061db06a04
6d685e5318e51b843ca50adeca50dc6300bf2cbb
5e63306f1629527799e34a9814dd8035df6ca854
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: WireGuard to port to existing Crypto API

[Bruno Wolff III]

Are there going to be two branches, one for using the current API and one 
using Zinc?

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

Commit 4659d637e271d7f2814c6763035553331cca3a3f seems broken

[Bruno Wolff III]

I got builds error with 4659d637e271d7f2814c6763035553331cca3a3f, but not 
with dcca03f27879701d7377109517176a3aae86619f.


[bruno@laptop2 src]$ make 
KERNELDIR=/lib/modules/5.3.0-0.rc6.git2.2.fc32.x86_64/build clean all
 CLEAN   /home/bruno/WireGuard/src
 CLEAN   /home/bruno/WireGuard/src/Module.symvers
 CLEAN   /home/bruno/WireGuard/src/tools/{wg,*.o,*.d}
 CC [M]  /home/bruno/WireGuard/src/main.o
 CC [M]  /home/bruno/WireGuard/src/noise.o
 CC [M]  /home/bruno/WireGuard/src/device.o
 CC [M]  /home/bruno/WireGuard/src/peer.o
 CC [M]  /home/bruno/WireGuard/src/timers.o
 CC [M]  /home/bruno/WireGuard/src/queueing.o
 CC [M]  /home/bruno/WireGuard/src/send.o
 CC [M]  /home/bruno/WireGuard/src/receive.o
 CC [M]  /home/bruno/WireGuard/src/socket.o
 CC [M]  /home/bruno/WireGuard/src/peerlookup.o
 CC [M]  /home/bruno/WireGuard/src/allowedips.o
 CC [M]  /home/bruno/WireGuard/src/ratelimiter.o
 CC [M]  /home/bruno/WireGuard/src/cookie.o
 CC [M]  /home/bruno/WireGuard/src/netlink.o
 CC [M]  /home/bruno/WireGuard/src/crypto/zinc/chacha20/chacha20.o
 PERLASM /home/bruno/WireGuard/src/crypto/zinc/chacha20/chacha20-x86_64.S
 AS [M]  /home/bruno/WireGuard/src/crypto/zinc/chacha20/chacha20-x86_64.o
 CC [M]  /home/bruno/WireGuard/src/crypto/zinc/poly1305/poly1305.o
 PERLASM /home/bruno/WireGuard/src/crypto/zinc/poly1305/poly1305-x86_64.S
 AS [M]  /home/bruno/WireGuard/src/crypto/zinc/poly1305/poly1305-x86_64.o
 CC [M]  /home/bruno/WireGuard/src/crypto/zinc/chacha20poly1305.o
 CC [M]  /home/bruno/WireGuard/src/crypto/zinc/blake2s/blake2s.o
 AS [M]  /home/bruno/WireGuard/src/crypto/zinc/blake2s/blake2s-x86_64.o
 CC [M]  /home/bruno/WireGuard/src/crypto/zinc/curve25519/curve25519.o
 LD [M]  /home/bruno/WireGuard/src/wireguard.o
 Building modules, stage 2.
 MODPOST 1 modules
 CC  /home/bruno/WireGuard/src/wireguard.mod.o
 LD [M]  /home/bruno/WireGuard/src/wireguard.ko
 CC  /home/bruno/WireGuard/src/tools/wg.o
 CC  /home/bruno/WireGuard/src/tools/config.o
 CC  /home/bruno/WireGuard/src/tools/show.o
 CC  /home/bruno/WireGuard/src/tools/mnlg.o
 CC  /home/bruno/WireGuard/src/tools/terminal.o
 CC  /home/bruno/WireGuard/src/tools/ipc.o
ipc.c: In function ‘userspace_get_wireguard_interfaces’:
ipc.c:189:8: warning: implicit declaration of function 
‘userspace_has_wireguard_interface’; did you mean 
‘userspace_get_wireguard_interfaces’? [-Wimplicit-function-declaration]
 189 |   if (!userspace_has_wireguard_interface(ent->d_name))
 |^
 |userspace_get_wireguard_interfaces
At top level:
ipc.c:143:13: warning: ‘userspace_has_wireguard_iface’ defined but not used 
[-Wunused-function]
 143 | static bool userspace_has_wireguard_iface(const char *iface)
 | ^
 CC  /home/bruno/WireGuard/src/tools/encoding.o
 CC  /home/bruno/WireGuard/src/tools/curve25519.o
 CC  /home/bruno/WireGuard/src/tools/setconf.o
 CC  /home/bruno/WireGuard/src/tools/genkey.o
 CC  /home/bruno/WireGuard/src/tools/showconf.o
 CC  /home/bruno/WireGuard/src/tools/pubkey.o
 CC  /home/bruno/WireGuard/src/tools/set.o
 LD  /home/bruno/WireGuard/src/tools/wg
/usr/bin/ld: ipc.o: in function `ipc_list_devices':
ipc.c:(.text+0xf39): undefined reference to `userspace_has_wireguard_interface'
/usr/bin/ld: ipc.o: in function `ipc_get_device':
ipc.c:(.text+0x109a): undefined reference to `userspace_has_wireguard_interface'
/usr/bin/ld: ipc.o: in function `ipc_set_device':
ipc.c:(.text+0x1e64): undefined reference to `userspace_has_wireguard_interface'
collect2: error: ld returned 1 exit status
make[1]: *** [: wg] Error 1
make: *** [Makefile:59: tools] Error 2

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

Re: Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

On Fri, May 17, 2019 at 13:12:07 +0200,
 "Jason A. Donenfeld"  wrote:

Thanks for getting this started. This commit should take care of it:

https://git.zx2c4.com/WireGuard/commit/?id=7a83d1e6da8aa27da8fd4d06e6b7d11198c7c049


Thanks for the fix. I'm using it with Fedora's 5.2.0-0.rc0.git8.1.fc31.x86_64 
kernel successfully. (Note not all arches built successfully with that 
kernel, but it was the latest for x86_64 I could get right now for testing 
a 5.2 kernel with the new fix.)

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

Re: Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

On Wed, May 15, 2019 at 06:18:30 -0500,
 Bruno Wolff III  wrote:
Now I'm looking at: f6ad55a6a184ebdf3d98a90eab0895f73ce9797e Merge 
branch 'nla_nest_start', which looks like it might also cause a 
problem.


Changing nla_nest_start to nla_nest_start_noflag didn't seem to help.

In case anyone else is working on getting wireguard to work with 5.2, 
I'm attaching my latest test diff.
diff --git a/src/netlink.c b/src/netlink.c
index b179b3184725..dd46487e0888 100644
--- a/src/netlink.c
+++ b/src/netlink.c
@@ -74,7 +74,7 @@ static int get_allowedips(struct sk_buff *skb, const u8 *ip, 
u8 cidr,
 {
struct nlattr *allowedip_nest;
 
-   allowedip_nest = nla_nest_start(skb, 0);
+   allowedip_nest = nla_nest_start_noflag(skb, 0);
if (!allowedip_nest)
return -EMSGSIZE;
 
@@ -94,7 +94,7 @@ static int
 get_peer(struct wg_peer *peer, struct allowedips_node **next_allowedips_node,
 u64 *allowedips_seq, struct sk_buff *skb)
 {
-   struct nlattr *allowedips_nest, *peer_nest = nla_nest_start(skb, 0);
+   struct nlattr *allowedips_nest, *peer_nest = nla_nest_start_noflag(skb, 
0);
struct allowedips_node *allowedips_node = *next_allowedips_node;
bool fail;
 
@@ -156,7 +156,7 @@ get_peer(struct wg_peer *peer, struct allowedips_node 
**next_allowedips_node,
else if (*allowedips_seq != peer->device->peer_allowedips.seq)
goto no_allowedips;
 
-   allowedips_nest = nla_nest_start(skb, WGPEER_A_ALLOWEDIPS);
+   allowedips_nest = nla_nest_start_noflag(skb, WGPEER_A_ALLOWEDIPS);
if (!allowedips_nest)
goto err;
 
@@ -190,7 +190,7 @@ static int wg_get_device_start(struct netlink_callback *cb)
struct wg_device *wg;
int ret;
 
-   ret = nlmsg_parse(cb->nlh, GENL_HDRLEN + genl_family.hdrsize, attrs,
+   ret = nlmsg_parse_deprecated(cb->nlh, GENL_HDRLEN + 
genl_family.hdrsize, attrs,
  genl_family.maxattr, device_policy, NULL);
if (ret < 0)
return ret;
@@ -247,7 +247,7 @@ static int wg_get_device_dump(struct sk_buff *skb, struct 
netlink_callback *cb)
up_read(&wg->static_identity.lock);
}
 
-   peers_nest = nla_nest_start(skb, WGDEVICE_A_PEERS);
+   peers_nest = nla_nest_start_noflag(skb, WGDEVICE_A_PEERS);
if (!peers_nest)
goto out;
ret = 0;
@@ -450,7 +450,7 @@ static int set_peer(struct wg_device *wg, struct nlattr 
**attrs)
int rem;
 
nla_for_each_nested(attr, attrs[WGPEER_A_ALLOWEDIPS], rem) {
-   ret = nla_parse_nested(allowedip, WGALLOWEDIP_A_MAX,
+   ret = nla_parse_nested_deprecated(allowedip, 
WGALLOWEDIP_A_MAX,
   attr, allowedip_policy, NULL);
if (ret < 0)
goto out;
@@ -561,7 +561,7 @@ static int wg_set_device(struct sk_buff *skb, struct 
genl_info *info)
int rem;
 
nla_for_each_nested(attr, info->attrs[WGDEVICE_A_PEERS], rem) {
-   ret = nla_parse_nested(peer, WGPEER_A_MAX, attr,
+   ret = nla_parse_nested_deprecated(peer, WGPEER_A_MAX, 
attr,
   peer_policy, NULL);
if (ret < 0)
goto out;
@@ -596,12 +596,10 @@ struct genl_ops genl_ops[] = {
 #endif
.dumpit = wg_get_device_dump,
.done = wg_get_device_done,
-   .policy = device_policy,
.flags = GENL_UNS_ADMIN_PERM
}, {
.cmd = WG_CMD_SET_DEVICE,
.doit = wg_set_device,
-   .policy = device_policy,
.flags = GENL_UNS_ADMIN_PERM
}
 };
@@ -617,6 +615,7 @@ __ro_after_init = {
.name = WG_GENL_NAME,
.version = WG_GENL_VERSION,
.maxattr = WGDEVICE_A_MAX,
+   .policy = device_policy,
.module = THIS_MODULE,
.netnsok = true
 };
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

Now I'm looking at: f6ad55a6a184ebdf3d98a90eab0895f73ce9797e Merge branch 
'nla_nest_start', which looks like it might also cause a problem.

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

Re: Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

On Wed, May 15, 2019 at 05:50:14 -0500,
 Bruno Wolff III  wrote:
I think 8cb081746c031fb164089322e2336a0bf5b3070c netlink: make 
validation more configurable for future strictness, might be the other 
commit causing problems. Some nla functions have changed. It looks 
like renamed, deprecated versions of the functions will exist for a 
while. So it should be easy for me to test this today. In the long 
using the deprecared functions will not be desired.


Wireguard built with the deprecated versions of nlmsg_parse and 
nla_parse_nested (and .policy moved to genl_family), but I'm still getting:

Unable to modify interface: Invalid argument
When running:
wg setconf wg0 /etc/wireguard/config

So I still don't know if I'm doing something wrong or missing yet another 
change.

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

Re: Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

I think 8cb081746c031fb164089322e2336a0bf5b3070c netlink: make validation 
more configurable for future strictness, might be the other commit causing 
problems. Some nla functions have changed. It looks like renamed, 
deprecated versions of the functions will exist for a while. So it should 
be easy for me to test this today. In the long using the deprecared 
functions will not be desired.

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

Re: Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

On Mon, May 13, 2019 at 16:21:10 -0500,
 Bruno Wolff III  wrote:

On Mon, May 13, 2019 at 15:24:53 -0500,
Bruno Wolff III  wrote:

On Mon, May 13, 2019 at 14:52:13 -0500,
Bruno Wolff III  wrote:

Wireguard isn't building on 5.2 right now because of commit:
3b0f31f2b8c9fb348e4530b88f6b64f9621f83d6 genetlink: make policy common to family



I'm slowly trying to work on this, but if someone who knows what they are 
doing wants to just get it done, feel free.


The commit that breaks things was developed on an old enough kernel that 
it was a problem with the compat stuff being out of sync. I'm trying various 
merge points to try to find a good place to test if there is a separate 
problem or if my change for that one is bad. The builds take a while so 
this hasn't been happening quickly.

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

Re: Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

On Mon, May 13, 2019 at 15:24:53 -0500,
 Bruno Wolff III  wrote:

On Mon, May 13, 2019 at 14:52:13 -0500,
Bruno Wolff III  wrote:

Wireguard isn't building on 5.2 right now because of commit:
3b0f31f2b8c9fb348e4530b88f6b64f9621f83d6 genetlink: make policy common to family

I've got Wireguard building, but need to do basic testing, then add 
a kernel version test in and do some other testing. If that all goes 
OK I'll submit a signed off patch to the list.


It looks to be a very simple change to netlink.c, but I could have 
easily missed something subtle.


wg (the config tool) doesn't work with my change, so there probably is 
more needed than just moving .policy to the family structure in the 
kernel. I'll continue looking at it, but it might need someone better 
than me to look at it eventually.


There is also a small chance that there are multiple issues. I may need 
to test before and after the commit I identified to see if this is the 
case.

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

Re: Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

On Mon, May 13, 2019 at 14:52:13 -0500,
 Bruno Wolff III  wrote:

Wireguard isn't building on 5.2 right now because of commit:
3b0f31f2b8c9fb348e4530b88f6b64f9621f83d6 genetlink: make policy common to family

I've got Wireguard building, but need to do basic testing, then add a 
kernel version test in and do some other testing. If that all goes OK 
I'll submit a signed off patch to the list.


It looks to be a very simple change to netlink.c, but I could have 
easily missed something subtle.


wg (the config tool) doesn't work with my change, so there probably is more 
needed than just moving .policy to the family structure in the kernel. I'll 
continue looking at it, but it might need someone better than me to look at it 
eventually.

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

Working on change for: genetlink: make policy common to family

[Bruno Wolff III]

Wireguard isn't building on 5.2 right now because of commit:
3b0f31f2b8c9fb348e4530b88f6b64f9621f83d6 genetlink: make policy common to family

I've got Wireguard building, but need to do basic testing, then add a kernel 
version test in and do some other testing. If that all goes OK I'll submit 
a signed off patch to the list.


It looks to be a very simple change to netlink.c, but I could have easily 
missed something subtle.

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

Re: [PATCH] global: the _bh variety of rcu helpers have been unified

[Bruno Wolff III]

On Thu, Mar 14, 2019 at 23:14:39 -0600,
 "Jason A. Donenfeld"  wrote:

---
Hey Bruno,

Based on your research, how does the below strike you? It's certainly
not pretty, but I'm struggling to come up with a better solution.


I think anything that doesn't try to keep the _bh versions around is going to 
be ugly. But keeping the _bh versions is not going to be acceptible upstream, 
so that doesn't seem to be an option. What you did looks pretty good 
given the constraints.


In the talk I saw, the motivation for the change was that mismatching 
rcu functions caused security issues, though I don't know how practical 
it is to exploit those mistakes. So I worry a bit about breaking things 
in old kernels accidentally, in the future. I don't have any good ideas for 
automatically catching misuse in new code.


I did try the version you committed, yesterday, and it seemed to work 
fine on a 5.1 kernel.

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

Re: [PATCH] Merge two rcu types

[Bruno Wolff III]

On Thu, Mar 14, 2019 at 12:58:41 -0600,
 "Jason A. Donenfeld"  wrote:

IIRC, the _bh variant of those functions has been aliased to non-_bh
since a few versions. Do you know the first time it was the same?


At this point I don't know. I knew of the change because I usually like to 
watch Paul's talks and watched his LCA talk not too long ago. I got the 
impression that he started working on the change in the last year, so it 
probably doesn't go back too many kernels.


I should be able to look at this some this weekend. It might be beyond my skill 
to do acceptibly, but I'm interested in giving it a shot. rc1 won't be out 
until the end of the weekend so there is a bit of time yet.

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

[PATCH] net/netfilter/nf_nat_core.h was removed by d2c5c103b1337f590b7edf1509a6e294bdf22402

[Bruno Wolff III]

It looks like net/netfilter/nf_nat_core.h isn't needed any more and things
seemed to work without it.

Signed-off-by: Bruno Wolff III 
---
 src/compat/compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compat/compat.h b/src/compat/compat.h
index 7a61e4c1a5cd..2dcdbaeb0ad6 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -792,7 +792,9 @@ struct __kernel_timespec {
 #include 
 #include 
 #include 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
 #include 
+#endif
 static inline void new_icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
 {
enum ip_conntrack_info ctinfo;
-- 
2.21.0

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

Re: [PATCH] Merge two rcu types

[Bruno Wolff III]

On Thu, Mar 14, 2019 at 07:32:11 -0500,
 Bruno Wolff III  wrote:


In case it isn't obvious, the patch I supplied is only good for 5.1+ 
kernels. I'm not sure how you wanted to handle doing compatibility for 
older kernels and didn't even have a good idea how to start.


If I want to try to rework this myself so that the main code is going to 
be usable upstream, but it still works with older kernels, is there a 
suggested approach. Using the old names in the main code using macros 
to make it work isn't going to fly upstream. I'm not sure that replicating 
large chunks of code in compat is a good idea either.

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

Re: [PATCH] net/netfilter/nf_nat_core.h was removed by d2c5c103b1337f590b7edf1509a6e294bdf22402

[Bruno Wolff III]

On Thu, Mar 14, 2019 at 00:14:52 -0500,
 Bruno Wolff III  wrote:

It looks like net/netfilter/nf_nat_core.h isn't needed any more and things
seemed to work without it.


I'll redo this one with a signed off by. Probably late tonight.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [PATCH] net/netfilter/nf_nat_core.h was removed by d2c5c103b1337f590b7edf1509a6e294bdf22402

[Bruno Wolff III]

On Thu, Mar 14, 2019 at 18:10:24 +1100,
 Aleksa Sarai  wrote:


For future reference, you want to send a patch series. The way I do it
is I first generate all of the patches:


Thanks. That isn't what I was trying to do here, but something I might 
do in the future. Here the two patches were separate, nit part of the 
series. I got confused in that I thought the mail wasn't getting set 
and tried a few different varients of the --smtp-server= option, most 
of which actually worked.



You're also missing a Signed-off-by:, but I'm not sure if WireGuard
contributions require those (you can add them with `git commit -s`).


Can you set up your config to do that automatically or are you supposed 
to do that manually for each commit to make sure you really mean it?


In this case, one patch is trivial and the other needs to be reworked, 
so I doubt it matters.

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

Re: [PATCH] Merge two rcu types

[Bruno Wolff III]

On Thu, Mar 14, 2019 at 00:16:08 -0500,
 Bruno Wolff III  wrote:

Paul McKenney made it harder to mess up ending rcu sections with an
incorrect function call by using the same functions to end multiple
types of rcu sections.


There are a number of commits involved in this change, but this commit 
has a pretty explicit comment about doing the renames I did.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8d1da4000b0b95bf95d3e13b7450eec5428da1e
netfilter: Replace call_rcu_bh(), rcu_barrier_bh(), and synchronize_rcu_bh()
Now that call_rcu()'s callback is not invoked until after bh-disable
regions of code have completed (in addition to explicitly marked
RCU read-side critical sections), call_rcu() can be used in place
of call_rcu_bh().  Similarly, rcu_barrier() can be used in place of
rcu_barrier_bh() and synchronize_rcu() in place of synchronize_rcu_bh().
This commit therefore makes these changes.

In case it isn't obvious, the patch I supplied is only good for 5.1+ 
kernels. I'm not sure how you wanted to handle doing compatibility for 
older kernels and didn't even have a good idea how to start.

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

Re: [PATCH] net/netfilter/nf_nat_core.h was removed by d2c5c103b1337f590b7edf1509a6e294bdf22402

[Bruno Wolff III]

Sorry about the duplicates. I git confused trying to use git email-send.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[PATCH] net/netfilter/nf_nat_core.h was removed by d2c5c103b1337f590b7edf1509a6e294bdf22402

[Bruno Wolff III]

It looks like net/netfilter/nf_nat_core.h isn't needed any more and things
seemed to work without it.
---
 src/compat/compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compat/compat.h b/src/compat/compat.h
index 7a61e4c1a5cd..2dcdbaeb0ad6 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -792,7 +792,9 @@ struct __kernel_timespec {
 #include 
 #include 
 #include 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
 #include 
+#endif
 static inline void new_icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
 {
enum ip_conntrack_info ctinfo;
-- 
2.21.0

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

[PATCH] net/netfilter/nf_nat_core.h was removed by d2c5c103b1337f590b7edf1509a6e294bdf22402

[Bruno Wolff III]

It looks like net/netfilter/nf_nat_core.h isn't needed any more and things
seemed to work without it.
---
 src/compat/compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compat/compat.h b/src/compat/compat.h
index 7a61e4c1a5cd..2dcdbaeb0ad6 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -792,7 +792,9 @@ struct __kernel_timespec {
 #include 
 #include 
 #include 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
 #include 
+#endif
 static inline void new_icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
 {
enum ip_conntrack_info ctinfo;
-- 
2.21.0

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

[PATCH] net/netfilter/nf_nat_core.h was removed by d2c5c103b1337f590b7edf1509a6e294bdf22402

[Bruno Wolff III]

It looks like net/netfilter/nf_nat_core.h isn't needed any more and things
seemed to work without it.
---
 src/compat/compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compat/compat.h b/src/compat/compat.h
index 7a61e4c1a5cd..2dcdbaeb0ad6 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -792,7 +792,9 @@ struct __kernel_timespec {
 #include 
 #include 
 #include 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
 #include 
+#endif
 static inline void new_icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
 {
enum ip_conntrack_info ctinfo;
-- 
2.21.0

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

[PATCH] Merge two rcu types

[Bruno Wolff III]

Paul McKenney made it harder to mess up ending rcu sections with an
incorrect function call by using the same functions to end multiple
types of rcu sections.

I replaced synchronize_rcu_bh with synchronize_rcu, rcu_barrier_bh
with rcu_barrier and call_rcu_bh with call_rcu.

I'm not sure how this should be done with compat. Using the old names
and fixing things with a macro isn't going to be liked for new code.

I don't know for sure this is really the correct way to fix things.
---
 src/allowedips.c | 6 +++---
 src/device.c | 6 +++---
 src/noise.c  | 2 +-
 src/peer.c   | 8 
 src/socket.c | 2 +-
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/allowedips.c b/src/allowedips.c
index bfb6020f350e..592501e39bc3 100644
--- a/src/allowedips.c
+++ b/src/allowedips.c
@@ -112,7 +112,7 @@ static void walk_remove_by_peer(struct allowedips_node 
__rcu **top,
if (!node->bit[0] || !node->bit[1]) {
rcu_assign_pointer(*nptr, DEREF(
   &node->bit[!REF(node->bit[0])]));
-   call_rcu_bh(&node->rcu, node_free_rcu);
+   call_rcu(&node->rcu, node_free_rcu);
node = DEREF(nptr);
}
}
@@ -300,12 +300,12 @@ void wg_allowedips_free(struct allowedips *table, struct 
mutex *lock)
RCU_INIT_POINTER(table->root6, NULL);
if (rcu_access_pointer(old4)) {
root_remove_peer_lists(old4);
-   call_rcu_bh(&rcu_dereference_protected(old4,
+   call_rcu(&rcu_dereference_protected(old4,
lockdep_is_held(lock))->rcu, root_free_rcu);
}
if (rcu_access_pointer(old6)) {
root_remove_peer_lists(old6);
-   call_rcu_bh(&rcu_dereference_protected(old6,
+   call_rcu(&rcu_dereference_protected(old6,
lockdep_is_held(lock))->rcu, root_free_rcu);
}
 }
diff --git a/src/device.c b/src/device.c
index 2866dd98ff4e..779c41521ea9 100644
--- a/src/device.c
+++ b/src/device.c
@@ -94,7 +94,7 @@ static int wg_pm_notification(struct notifier_block *nb, 
unsigned long action,
mutex_unlock(&wg->device_update_lock);
}
rtnl_unlock();
-   rcu_barrier_bh();
+   rcu_barrier();
return 0;
 }
 
@@ -244,7 +244,7 @@ static void wg_destruct(struct net_device *dev)
destroy_workqueue(wg->packet_crypt_wq);
wg_packet_queue_free(&wg->decrypt_queue, true);
wg_packet_queue_free(&wg->encrypt_queue, true);
-   rcu_barrier_bh(); /* Wait for all the peers to be actually freed. */
+   rcu_barrier(); /* Wait for all the peers to be actually freed. */
wg_ratelimiter_uninit();
memzero_explicit(&wg->static_identity, sizeof(wg->static_identity));
skb_queue_purge(&wg->incoming_handshakes);
@@ -468,5 +468,5 @@ void wg_device_uninit(void)
 #ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&pm_notifier);
 #endif
-   rcu_barrier_bh();
+   rcu_barrier();
 }
diff --git a/src/noise.c b/src/noise.c
index 4405125e7a0a..2e05e2740685 100644
--- a/src/noise.c
+++ b/src/noise.c
@@ -132,7 +132,7 @@ static void keypair_free_kref(struct kref *kref)
keypair->entry.peer->internal_id);
wg_index_hashtable_remove(keypair->entry.peer->device->index_hashtable,
  &keypair->entry);
-   call_rcu_bh(&keypair->rcu, keypair_free_rcu);
+   call_rcu(&keypair->rcu, keypair_free_rcu);
 }
 
 void wg_noise_keypair_put(struct noise_keypair *keypair, bool unreference_now)
diff --git a/src/peer.c b/src/peer.c
index 996f40b919ca..0c7e942f6893 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -99,7 +99,7 @@ static void peer_make_dead(struct wg_peer *peer)
/* Mark as dead, so that we don't allow jumping contexts after. */
WRITE_ONCE(peer->is_dead, true);
 
-   /* The caller must now synchronize_rcu_bh() for this to take effect. */
+   /* The caller must now synchronize_rcu() for this to take effect. */
 }
 
 static void peer_remove_after_dead(struct wg_peer *peer)
@@ -171,7 +171,7 @@ void wg_peer_remove(struct wg_peer *peer)
lockdep_assert_held(&peer->device->device_update_lock);
 
peer_make_dead(peer);
-   synchronize_rcu_bh();
+   synchronize_rcu();
peer_remove_after_dead(peer);
 }
 
@@ -189,7 +189,7 @@ void wg_peer_remove_all(struct wg_device *wg)
peer_make_dead(peer);
list_add_tail(&peer->peer_list, &dead_peers);
}
-   synchronize_rcu_bh();
+   synchronize_rcu();
list_for_each_entry_safe(peer, temp, &dead_peers, peer_list)
peer_remove_after_dead(peer);
 }
@@ -228,7 +228,7 @@ static void kref_release(struct kref *refcount)
wg_

[PATCH] net/netfilter/nf_nat_core.h was removed by d2c5c103b1337f590b7edf1509a6e294bdf22402

[Bruno Wolff III]

It looks like net/netfilter/nf_nat_core.h isn't needed any more and things
seemed to work without it.
---
 src/compat/compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compat/compat.h b/src/compat/compat.h
index 7a61e4c1a5cd..2dcdbaeb0ad6 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -792,7 +792,9 @@ struct __kernel_timespec {
 #include 
 #include 
 #include 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
 #include 
+#endif
 static inline void new_icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
 {
enum ip_conntrack_info ctinfo;
-- 
2.21.0

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

Re: Pre 5.1-rc1 build issue

[Bruno Wolff III]

On Wed, Mar 13, 2019 at 14:44:33 -0600,
 "Jason A. Donenfeld"  wrote:

On Wed, Mar 13, 2019 at 12:53 PM Bruno Wolff III  wrote:

I got something that seems to be working. So I'm good until the real fixes
are ready.


Perhaps your [fake?!] fixes could become the real fixes if you ran
`git send-email` to the mailing list?


I'll look at what I did to make sure I didn't make an unwanted rcu change. 
From Paul's talk it looks like there is a bit of a merger of a couple 
of rcu types to keep developers from getting confused and I think the 
unknown functions (that used to be known) should now call the non _bh 
version.


For the network include file I didn't include it any more. The correct 
fix is probably an ifdef based on kernel version or something like 
that.


So it might be useful to look at the changes I did, but I would be wary 
of committing them as is. It'll take me maybe an hour to double check 
and try it again on another system.

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

Re: Pre 5.1-rc1 build issue

[Bruno Wolff III]

On Wed, Mar 13, 2019 at 13:38:18 -0500,
 Bruno Wolff III  wrote:

Commit 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d2c5c103b1337f590b7edf1509a6e294bdf22402
removed net/netfilter/nf_nat_core.h, which breaks wireguard builds for 
5.1.0-0.rc0.git5.2.fc31.x86_64.


It sounds like it isn't needed any more from the commit message.


There are also some rcu changes that I just guessed on fixes for. I think 
this change was covered in Paul McKenney's LCA talk in January.


I got something that seems to be working. So I'm good until the real fixes 
are ready.

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

Pre 5.1-rc1 build issue

[Bruno Wolff III]

Commit 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d2c5c103b1337f590b7edf1509a6e294bdf22402
removed net/netfilter/nf_nat_core.h, which breaks wireguard builds for 
5.1.0-0.rc0.git5.2.fc31.x86_64.


It sounds like it isn't needed any more from the commit message.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [ANNOUNCE] WireGuard Snapshot `0.0.20190123` Available

[Bruno Wolff III]

On Wed, Jan 23, 2019 at 21:32:20 +0100,
 "Jason A. Donenfeld"  wrote:

On Wed, Jan 23, 2019 at 2:40 PM Jason A. Donenfeld  wrote:

  * netlink: use __kernel_timespec for handshake time

  This readies us for Y2038. See https://lwn.net/Articles/776435/ for more info.


Sorry, I didn't realize that link was still paywalled. Have a
subscriber link instead:


It will probably unlock in just over 3 hours.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Android and Manjaro road warriors behind dynamic IP addresses/Carrier Grade NAT?

[Bruno Wolff III]

On Sat, Dec 29, 2018 at 14:49:56 +0100,
 "Rene 'Renne' Bartsch, B.Sc. Informatics"  wrote:


Is there any way for Wireguard peers with static IP addresses to push endpoint 
information of all connected peers to all other peers?
Or at least a hook which allows to dump changing endpoints into a file in 
real-time?


I have a /29 at home and I have set up 2 laptops to have static IP addresses 
that can be used to connect to them, no matter what network they are 
connected to.


I use a local router to relay the traffic.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: The Linux Plumbers Conference videos are up

[Bruno Wolff III]

On Tue, Dec 04, 2018 at 02:03:47 -0600,
 Bruno Wolff III  wrote:


Thanks. That explains why I can't get there, even though there is a 
path. That drop down appears to only work with javascript enabled, 
which I don't normally have enabled.


This might be a gecko bug. When I use lynx I see the dropdown. The code 
doesn't look like it should need javascript to be displayed.

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

Re: The Linux Plumbers Conference videos are up

[Bruno Wolff III]

On Tue, Dec 04, 2018 at 18:55:49 +1100,
 Aleksa Sarai  wrote:

On 2018-12-04, Bruno Wolff III  wrote:

> Thanks Bruno. I've updated the webpage with these:
> https://www.wireguard.com/presentations/

I've never been able to find a link to the presentations starting from the
main wireguard page. There is probably a link to it someplace as searches
find the presentations, but it would be nice if there was an easy to find
link from the main page to make it easier to get to (without a separate
bookmark).


Interworkings > Presentations is a link to this page.


Thanks. That explains why I can't get there, even though there is a path. 
That drop down appears to only work with javascript enabled, which I don't 
normally have enabled.

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

Re: The Linux Plumbers Conference videos are up

[Bruno Wolff III]

On Tue, Dec 04, 2018 at 01:47:41 +0100,
 "Jason A. Donenfeld"  wrote:

Thanks Bruno. I've updated the webpage with these:
https://www.wireguard.com/presentations/


I've never been able to find a link to the presentations starting from the 
main wireguard page. There is probably a link to it someplace as searches 
find the presentations, but it would be nice if there was an easy to find 
link from the main page to make it easier to get to (without a separate 
bookmark).

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

The Linux Plumbers Conference videos are up

[Bruno Wolff III]

The links redirect to youtube.

Zinc
https://linuxplumbersconf.org/event/2/contributions/254/attachments/152/225/go

WireGuard
https://linuxplumbersconf.org/event/2/contributions/66/attachments/158/240/go
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: WireGuard for iOS - TestFlight

[Bruno Wolff III]

On Mon, Nov 05, 2018 at 22:27:24 +0100,
 "Jason A. Donenfeld"  wrote:

Hey folks,

For the last few weeks, Roopesh and I have been hard at work on the
WireGuard for iOS app. Today we're happy to share a


I thought you went on vacation, as it was so quite since V8 got posted.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [PATCH 0/7] Allow changing the transit namespace

[Bruno Wolff III]

On Sat, Sep 08, 2018 at 14:18:34 +0200,
 Julian Orth  wrote:


wg set  transit-net 

The distinction is made based on the format of the argument. If it is an
unsigned 32 bit integer, then it is interpreted as a process id.
Otherwise it is interpreted as a file path. /proc does not need to be
mounted to use the process id interpretation. To force the
interpretation as a file-path, use a ./ prefix.


Ambiguity is generally not a good idea (especially for security applications). 
It's not my decision, but I'd rather see the syntax make it clear what the type 
of the parameter is supposed to be.

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

Re: Wireguard not building on pre-rc1 4.19 kernels (Fedora)

[Bruno Wolff III]

Jason pushed a fix for this and now I am able to use vanilla WireGuard with 
4.19 kernels.

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

Re: Wireguard not building on pre-rc1 4.19 kernels (Fedora)

[Bruno Wolff III]

On Mon, Aug 20, 2018 at 14:43:53 +,
 Aaron Jones  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This will be because Jason's RNG patch landed in mainline, but the
kernel version number won't get bumped (so compat.h can use it
properly) until 4.19 is released.


Thanks. That was enough information to tell me what to do to get it to 
work with a temporary hack. I'm using a successful build as I type this.

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

Wireguard not building on pre-rc1 4.19 kernels (Fedora)

[Bruno Wolff III]

[bruno@cerberus src]$ make 
KERNELDIR=/lib/modules/4.19.0-0.rc0.git6.1.fc30.x86_64/build clean all
 CLEAN   /home/bruno/WireGuard/src/.tmp_versions
 CLEAN   /home/bruno/WireGuard/src/tools/{wg,*.o,*.d}
 CC [M]  /home/bruno/WireGuard/src/main.o
In file included from :
/home/bruno/WireGuard/src/compat/compat.h:684:20: error: static declaration of 
‘rng_is_initialized’ follows non-static declaration
static inline bool rng_is_initialized(void)
   ^~
In file included from ./include/linux/net.h:22,
from ./include/linux/skbuff.h:29,
from ./include/linux/ip.h:20,
from /home/bruno/WireGuard/src/compat/compat.h:640,
from :
./include/linux/random.h:39:13: note: previous declaration of 
‘rng_is_initialized’ was here
extern bool rng_is_initialized(void);
^~
make[2]: *** [scripts/Makefile.build:311: /home/bruno/WireGuard/src/main.o] 
Error 1
make[1]: *** [Makefile:1514: _module_/home/bruno/WireGuard/src] Error 2
make: *** [Makefile:36: module] Error 2
[bruno@cerberus src]$ 
___

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

Re: Wireguard doesn't work with Linux 4.18-rc1

[Bruno Wolff III]

On Sat, Jun 23, 2018 at 08:23:08 -0400,
 Jordan Glover  wrote:

Hi,

I can't make wireguard work with linux 4.18-rc1 and mainline from
06.22.2018.


It has been working for me. I use Fedora rawhide nodebug kernels and 
haven't noticed any problems with WireGuard. I build WireGuard from 
source (HEAD) when I switch kernels.


So you are probably going to need to provide more details to narrow 
things down.

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

Re: WG: Need for HW-clock independent timestamps

[Bruno Wolff III]

On Mon, May 21, 2018 at 15:53:10 +0200,
 Matthias Urlichs  wrote:

On 21.05.2018 14:35, Reto Brunner wrote:

If you just want a single write cycle, then you loose the ability to graceful
handle unexpected shutdowns.

Why?

Even if you increment the counter by 10'000 when restoring it, who's to
say the device hasn't been running for several weeks before the
unexpected power cycle happened?


So increment the counter by a trillion instead. It's large enough and
you're not going to send a trillion packets before the next reboot.


If you want to go that route, you should just treat it as a two part number. 
One for a boot count, that would get incremented every boot and saved and 
a low order part that is reset to 0 at every boot. Note that this scheme 
leaks information to the peer.

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

Re: Policy-based routing

[Bruno]

Hi Jason,

Thanks for your input. I agree with you.

But I could have the peers based on table routing and marking packets, 
were all the traffic (0.0.0.0/0) would be routed based on the prior 
conditions (tables and marking).


I'm doing one interface per peer right now, but I thought it could be 
possible to achieve the same results with just one interface.


Bruno



On 04/13/2018 11:09 PM, Jason A. Donenfeld wrote:

Hi Bruno,

You can't set multiple peers to use 0.0.0.0/0 at the same time on the
same interface. How would it be able to choose which peer to send
traffic to then? Instead, if you want some kind of redundancy or
bonding, you can try using multiple interfaces, and then use whatever
traditional routing or load balancing tools that you ordinarily would.

Jason


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

Re: Using WG for transport security in a p2p network

[Bruno Wolff III]

On Thu, Apr 05, 2018 at 09:13:03 +0200,
 Matthias Urlichs  wrote:

Hi,


Another option would be to run insecure QUIC or SCTP on top of WireGuard,

You cannot run SCTP on the Internet anyway. Too many routers block
anything that's not TCP/UDP/ICMP.


The tunnelled traffic is going to be UDP. If he controls everything from 
the tunnel endpoints to the traffic endpoints he can make sure SCTP isn't 
blocked.

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

Policy-based routing

[Bruno]

Hello,

I'm trying to set up a policy-based routing on a wireguard instance. I 
didn't want to call it server, because it acts more like a proxy.


Let's say I have 6 peers plus this wireguard server.

Peer 2  Peer 3   Peer 4
 \/   \/   \/
__
| |
| Wireguard "server"  |
| |
|_|
 \/   \/   \/
Peer 5  Peer 6   Peer 7

Wireguard "server"
Address = 10.0.0.1/24

Peers 2-7
Address = 10.0.0.2-7/24, respectively.

So, what I'm trying to do is route traffic to Peer 7, for example, if it 
is coming from Peer 2. I can do it doing some `ip rule` and `ip route` 
commands. However, wireguard seems to be blocking that traffic. So, I 
want peers 5-7 act as gateways to the internet and I would choose it via 
Linux environment.


Peers 5-7 would be wireguard servers that would route all traffic to the 
internet. So, on the wireguard instance (10.0.0.1/24, "server"), I have 
to set allowed IPs to peers 5-7 as "0.0.0.0/0", correct? Does wireguard 
accept that? On my tests it would just pick one as allowed IPs as 
0.0.0.0/0 and set others to (none). Then, I couldn't reach traffic 
neither from nor to that others peers.


On the wireguard "server" I would set allowed-IPs to peers 2-4 as 
10.0.0.2/32-10.0.0.4/32 as I don't need traffic going through it, just 
coming from it.


Is it possible to achieve that with wireguard?

Thanks!

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

gcc 8 warning

[Bruno Wolff III]

While there were a few other warnings about sibling call from callable 
instruction with modified stack frame, the following looked more significant if 
it isn't a gcc bug.

 CC [M]  /home/bruno/WireGuard/src/crypto/chacha20poly1305.o
In file included from ./include/linux/bitmap.h:9,
from ./include/linux/cpumask.h:12,
from ./arch/x86/include/asm/cpumask.h:5,
from ./arch/x86/include/asm/msr.h:11,
from ./arch/x86/include/asm/processor.h:21,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:38,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:81,
from ./include/linux/spinlock.h:51,
from ./include/linux/seqlock.h:36,
from ./include/linux/time.h:6,
from ./include/linux/skbuff.h:19,
from ./include/linux/ip.h:20,
from /home/bruno/WireGuard/src/compat/compat.h:583,
from :
In function ‘memcpy’,
   inlined from ‘poly1305_update’ at 
/home/bruno/WireGuard/src/crypto/chacha20poly1305.c:549:4,
   inlined from ‘chacha20poly1305_encrypt_sg’ at 
/home/bruno/WireGuard/src/crypto/chacha20poly1305.c:673:4:
./include/linux/string.h:344:9: warning: ‘__builtin_memcpy’ forming offset 
[233, 272] is out of the bounds [0, 232] of object ‘poly1305_state’ with type 
‘struct poly1305_ctx’ [-Warray-bounds]
 return __builtin_memcpy(p, q, size);
^~~~
/home/bruno/WireGuard/src/crypto/chacha20poly1305.c: In function 
‘chacha20poly1305_encrypt_sg’:
/home/bruno/WireGuard/src/crypto/chacha20poly1305.c:652:22: note: 
‘poly1305_state’ declared here
 struct poly1305_ctx poly1305_state;
 ^~
In file included from ./include/linux/bitmap.h:9,
from ./include/linux/cpumask.h:12,
from ./arch/x86/include/asm/cpumask.h:5,
from ./arch/x86/include/asm/msr.h:11,
from ./arch/x86/include/asm/processor.h:21,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:38,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:81,
from ./include/linux/spinlock.h:51,
from ./include/linux/seqlock.h:36,
from ./include/linux/time.h:6,
from ./include/linux/skbuff.h:19,
from ./include/linux/ip.h:20,
from /home/bruno/WireGuard/src/compat/compat.h:583,
from :
In function ‘memcpy’,
   inlined from ‘poly1305_update’ at 
/home/bruno/WireGuard/src/crypto/chacha20poly1305.c:549:4,
   inlined from ‘chacha20poly1305_decrypt_sg’ at 
/home/bruno/WireGuard/src/crypto/chacha20poly1305.c:789:4:
./include/linux/string.h:344:9: warning: ‘__builtin_memcpy’ forming offset 
[233, 272] is out of the bounds [0, 232] of object ‘poly1305_state’ with type 
‘struct poly1305_ctx’ [-Warray-bounds]
 return __builtin_memcpy(p, q, size);
^~~~
/home/bruno/WireGuard/src/crypto/chacha20poly1305.c: In function 
‘chacha20poly1305_decrypt_sg’:
/home/bruno/WireGuard/src/crypto/chacha20poly1305.c:764:22: note: 
‘poly1305_state’ declared here
 struct poly1305_ctx poly1305_state;
 ^~

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

Re: Question about Wireguard server

[Bruno Wolff III]

On Thu, Jan 04, 2018 at 16:51:19 -0500,
 Stoyan Mihov  wrote:

Greetings dear wireguards!

I am running wireguard on ubuntu 16.04 server and LEDE on router. When I
have everything set up on the router - I decided to upgrade to a newer
version of LEDE. So I did, and then my router would not connect to the
server anymore (although settings have been saved) until I issue a command
on the server:
wg-quick down wg0 && wg-quick up wg0

Then the router automatically connects without an issue. Before that - the
server would not accept a connection from the router, there are no dmesg
errors, no errors whatsoever on both sides. It simply doesn't show a
handshake on the server, and the router sends packets, but receives 0
packets.

Is there an easier way to fix that issue, so a restart on the server would
not be necessary every time an upgrade on the router is made? Or am I
missing something obvious (quite possible lol) that resolves that issue?


Is there NAT involved? I saw similar behavior when a port got moved 
because of a source NAT conflict.

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

Netdev 2.2 video posted

[Bruno Wolff III]

The video from the netdev 2.2 talk has been posted on youtube: 
https://www.youtube.com/watch?v=3rAeStfIXgM


I'm downloading it now and haven't reviewed it yet.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: 34C3 - WireGuard Workshop - Dec 29th

[Bruno Wolff III]

On Thu, Dec 21, 2017 at 02:11:31 +0100,
 "Jason A. Donenfeld"  wrote:


https://events.ccc.de/congress/2017/wiki/index.php/Session:WireGuard


Is this going to get recorded?
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: WireGuard Upstreaming Roadmap (November 2017)

[Bruno Wolff III]

On Thu, Dec 07, 2017 at 11:22:04 +0100,
 Stefan Tatschner  wrote:


Assuming I am right according the crypto agility, what's the upgrade
path if any of the involved cryptographic algorithms will be declared
insecure/broken? From my point of view wireguard tries to stay as
simple as possible and in general that's a good idea. I am just a bit
worrying about the possible lack of a clear upgrade path once
wireguard is mainlined.


Having alternate crypto paths is also a weakness. There have been lots of 
downgrade attacks against systems that incorporate agility.

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

Re: Should I expect faster recovery after one side goes down

[Bruno Wolff III]

On Fri, Dec 01, 2017 at 09:43:19 +0100,
 Baptiste Jonglez  wrote:


It sounds like one of these situations where persistent keepalives would
be useful, doesn't it?


It is definitely useful as the laptop is expected to be behind NAT, but it 
doesn't help with the rebooting the router breaking historical source 
NAT (on my local network) while the other end remembers where it last got a 
packet from. The solution below dealt with that.





I found a way to make it work more automatically. The reason the port was
getting reassigned was because the original connection packet was being
tracked and was conflicting with the source nat mapping even though in
reallity the connection was the same. By putting in CT --notrack rules I was
able to block that traking and without the conflict the port doesn't get
remapped. I don't need tracking or the original connection for my firewall
rules so this should be OK. On testing it seems to work as expected. Now
when I reboot my router, my laptop reconnects and the wireguard tunnel works
without having to restart it.

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

Re: Should I expect faster recovery after one side goes down

[Bruno Wolff III]

On Tue, Nov 28, 2017 at 00:44:13 -0600,
 Bruno Wolff III  wrote:


I think the correct fix is to know if I reboot the router for testing 
something, I need to also restart wireguard to make sure it is sending 
data to the expected port. This isn't going to be an issue in normal 
operation.


I found a way to make it work more automatically. The reason the port 
was getting reassigned was because the original connection packet was 
being tracked and was conflicting with the source nat mapping even though 
in reallity the connection was the same. By putting in CT --notrack rules 
I was able to block that traking and without the conflict the port doesn't 
get remapped. I don't need tracking or the original connection for my 
firewall rules so this should be OK. On testing it seems to work as 
expected. Now when I reboot my router, my laptop reconnects and the wireguard 
tunnel works without having to restart it.

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

Re: Should I expect faster recovery after one side goes down

[Bruno Wolff III]

On Tue, Nov 28, 2017 at 00:13:06 -0600,
 Bruno Wolff III  wrote:
I do some source address rewriting and it may be that the initial 
addresses used for the encapsulating packets are different than the 
ones later.


When I'm on the local network, 192.168.6.1 gets used for the initial 
source adddress and gets rewritten to 98.103.208.26 in order to make 
the source consistent for the laptop whether or not it is on the 
local network. (That way I don't need to allow connections from 
192.168.6.1 somewhere else where it wouldn't be my router.) When this 
happens the source port seems to normally get changed. Wireguard on the 
laptop remembers the new source port and tries to keep using it after 
the router is rebooted. But during the reboot the router forgets about 
the port mapping so it ends up dropping the packets. It has no reason 
to send packets on its own to the laptop (and wouldn't know where to 
send them) so the port doesn't get corrected.


I think the correct fix is to know if I reboot the router for testing 
something, I need to also restart wireguard to make sure it is sending 
data to the expected port. This isn't going to be an issue in normal 
operation.

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

Re: Should I expect faster recovery after one side goes down

[Bruno Wolff III]

I'm pretty sure I'm being bit by firewall rules on the router. It seems to 
be rejecting all of the tunnel packets and it has no reason to try to 
connect to the laptop the handshake never occurs again. I suspect that 
normally a connection established related rule lets things through. I just 
need to figure out how the start up packet is different so that it gets 
through. The systemd iptables service eventually seems to stop. Probably 
there is a DNS request that needs to timeout.
I do some source address rewriting and it may be that the initial addresses 
used for the encapsulating packets are different than the ones later.

So most likely this is all on my end and not wireguard related.
Thanks for the tcpdump suggestion. I should have tried that sooner.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Should I expect faster recovery after one side goes down

[Bruno Wolff III]

On Mon, Nov 27, 2017 at 18:36:23 +0100,
 "Jason A. Donenfeld"  wrote:

Hello Bruno,

That's some pretty weird behavior, and it sounds like whatever the
cause is is being obscured under layers of systemd. Perhaps come on
into #wireguard on Freenode and we can debug this in real time? I've
got a few ideas.


I don't have my laptop with me at work and breaking the wireguard tunnel 
to it will break my access to it from here. I could check configuration 
from work. I can bring it with me tomorrow, otherwise I'll probably get 
home too late for you tonight and I probably won't be up late enough 
to catch you early tomorrow. 


Probably I'll be able to reproduce the issue from work.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Should I expect faster recovery after one side goes down

[Bruno Wolff III]

On Mon, Nov 27, 2017 at 07:49:14 -0600,
 Bruno Wolff III  wrote:

On Mon, Nov 27, 2017 at 12:04:06 +0100,
"Jason A. Donenfeld"  wrote:

Hi Bruno,

The first question is - how long?


This might be related to the amount or type of traffic backed up. The two 
machines where this was very noticeable in testing had all of their traffic 
routed through the tunnel other than the encapsulating packets. (DNS traffic 
gets tunnelled.) Playing with this on my work machine where only traffic 
destined for a few specific hosts was tunnelled, I am finding it hard to 
duplicate the problem.

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

Re: Should I expect faster recovery after one side goes down

[Bruno Wolff III]

On Mon, Nov 27, 2017 at 12:04:06 +0100,
 "Jason A. Donenfeld"  wrote:

Hi Bruno,

The first question is - how long?


For "systemctl iptables stop" I have waited around a minute before 
using control C. After running "systemctl stop wireguard" or 
"systemctl restart wireguard" (which will delete wg0) "systemctl stop 
iptables" will run with no noticeable delay.


For network traffic, I waited around 10 minutes and things were still not 
working. Web page loads would still time out after a minute or two. But 
I did have a few DNS lookups succeed. I'm not sure if I did something 
that allowed a value to get cached (there is a local caching resolver 
on the affected machines) or if a response eventually made it through. 
After "systemctl restart wireguard" things start working normal right 
away. So I don't know the delay for specific traffic, but it looks to 
be at least a minute for most traffic. The problem does not seem to 
resolve for at least 10 minutes, though I don't think I have ever seen it 
resolve on its own.

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

Should I expect faster recovery after one side goes down

[Bruno Wolff III]

I'm not sure what is really going on but I have seen some very long delays 
after one side of the link goes down, while the other keeps sending 
packets. The work around is to restart the local side once the remote side 
is back up.


When I do some testing and say reboot the router the a wg tunnel terminates 
at, while continuing to use the laptop at the other end, after the router 
is back up very little traffic seems to get through or there is a very 
large latency. Restarting the iptables service with systemd will also 
hang. I don't know if that is forever or just a very long time. If I restart 
wireguard on the laptop (which deletes and recreates the device) things 
will start working normally again.


Is there some information I can collect that will illuminate what is going 
on here?

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

Re: d8738d57ab9ab976a1899e73d955d38317f44486 not building with 4.15.0-0.rc0.git6.

[Bruno Wolff III]

On Sun, Nov 26, 2017 at 13:45:28 +0100,
 "Jason A. Donenfeld"  wrote:

https://git.zx2c4.com/WireGuard/commit/?id=26e3639dba77a2f78f6ca093c8a4ffa782a0883d


It builds and works with 4.15.0-0.rc0.git7.2.fc28. Thanks.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: roaming and ddns dynamic ip

[Bruno Wolff III]

On Thu, Nov 23, 2017 at 00:00:51 +0800,
 d tbsky  wrote:


when client is behind firewall via nat to internet, and server has
dynamic ip, I don't think keepalive will help. since the changed
server can not connect to client, it needs client to initial the
connection. under openvpn, keepalive can detect broken link and try to
restart itself, then client can reconnect to server automatically.


If both sides are using keep alives it could help. It won't work if both sides 
change IP addresses between keep alives. And if the client is turned off 
when the server changes IP addresses that is going to apply.

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

Re: d8738d57ab9ab976a1899e73d955d38317f44486 not building with 4.15.0-0.rc0.git6.

[Bruno Wolff III]

On Tue, Nov 21, 2017 at 20:51:49 +0100,
 "Jason A. Donenfeld"  wrote:

Hi Bruno,

I'll start working on 4.15 after rc1 hits or possibly sooner, as
there's currently quite a bit of churn at the moment. The current
errors are caused by:


OK. I switched back to 4.14 and things are fine. Linus was threatening to 
close the merge window early, so maybe we'll get rc1 tomorrow night (-0600).

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

d8738d57ab9ab976a1899e73d955d38317f44486 not building with 4.15.0-0.rc0.git6.

[Bruno Wolff III]

I tried building the latest WireGuard on the latest rawhide kernel an got 
the following error:


/home/bruno/WireGuard/src/netlink.c: In function ‘get_device_dump_real’:
/home/bruno/WireGuard/src/netlink.c:180:2: error: too many arguments to 
function ‘genl_dump_check_consistent’
 genl_dump_check_consistent(cb, hdr, &genl_family);
 ^~
In file included from /home/bruno/WireGuard/src/netlink.c:11:0:
./include/net/genetlink.h:194:20: note: declared here
static inline void genl_dump_check_consistent(struct netlink_callback *cb,
   ^~
make[2]: *** [scripts/Makefile.build:306: /home/bruno/WireGuard/src/netlink.o] 
Error 1

I also got some warnings about redefining READ_ONCE:

CC [M]  /home/bruno/WireGuard/src/netlink.o
In file included from ./include/linux/kernel.h:10:0,
from ./include/linux/skbuff.h:17,
from ./include/linux/ip.h:20,
from /home/bruno/WireGuard/src/compat/compat.h:528,
from :0:
./include/linux/compiler.h:249:0: warning: "READ_ONCE" redefined
#define READ_ONCE(x) __READ_ONCE(x, 1)

In file included from :0:0:
/home/bruno/WireGuard/src/compat/compat.h:42:0: note: this is the location of 
the previous definition
#define READ_ONCE ACCESS_ONCE

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

Re: Road Warrior config with fwmark

[Bruno Wolff III]

On Tue, Nov 14, 2017 at 10:34:53 -0600,
 Bruno Wolff III  wrote:


I have this working on my laptop, but I want to tweak my router so 
that I don't need to have special iptables rules on my home network.


I got this fixed so I'll attach /etc/sysconfig/iptables and 
/etc/systemd/system/wireguard.service that make things work.
# If our addresses are used by the local network, the wrong source
# address will be used for packets that initially (before marking)
# look like they should go out the local gateway will get the wrong
# source address. So we need to be prepared to rewrite it to make things
# work.
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING ! -s 98.103.208.29/32 -o wg0 -j SNAT --to-source 98.103.208.29
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i wg0 -p icmp -m icmp --icmp-type any -j ACCEPT
-A INPUT -s 98.103.208.26 -p icmp -m icmp --icmp-type any -j ACCEPT
-A INPUT -i wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 98.103.208.24/29 -i wg0 -p tcp -m conntrack --ctstate NEW -m tcp 
--dport 22 -j ACCEPT
-A INPUT -s 129.89.240.0/24 -i wg0 -p tcp -m conntrack --ctstate NEW -m tcp 
--dport 22 -j ACCEPT
-A INPUT -s 10.32.2.72/32 -i wg0 -p tcp -m conntrack --ctstate NEW -m tcp 
--dport 22 -j ACCEPT
-A INPUT -p udp -m udp -s 98.103.208.26 --dport 992 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o wg0 -j ACCEPT
-A OUTPUT -m mark --mark 0x1 -j ACCEPT
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT
[Unit]
Description=WireGuard Server

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/sbin/ip link del dev wg0
ExecStart=-/usr/sbin/ip rule del pref 100
ExecStart=/usr/sbin/ip link add dev wg0 type wireguard
ExecStart=/usr/bin/wg setconf wg0 /etc/wireguard/config
ExecStart=/usr/sbin/ip address add 98.103.208.29/32 dev wg0
ExecStart=/usr/sbin/ip link set up dev wg0
ExecStart=/usr/sbin/ip route add default dev wg0 src 98.103.208.29 table 100
ExecStart=/usr/sbin/ip rule add not fwmark 1 pref 100 table 100
ExecStopPost=/usr/sbin/ip link del dev wg0
ExecStopPost=/usr/sbin/ip rule del pref 100

[Install]
WantedBy=multi-user.target
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Road Warrior config with fwmark

[Bruno Wolff III]

It would be nice if fwmark was mentioned on https://www.wireguard.com/netns/ 
when covering routing all of your traffic through your tunnel for Road 
Warrior setups.


I noticed the fwmark support when looking at tools/wg-quick.bash. 
fwmark can be used to set up routing configurations that are essentially 
(they don't give bogus addresses) independent of the local network 
configuration. So no special action needs to be taken as you move from 
one wireless network to another. This makes the rules based approach much 
more competitive with the namespace technique.


I have this working on my laptop, but I want to tweak my router so that 
I don't need to have special iptables rules on my home network.


I have things set up to give my laptop the same static IP address, no matter 
where it is located.

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

Re: Roaming Mischief

[Bruno Wolff III]

On Tue, Nov 14, 2017 at 10:59:03 +0100,
 "Jason A. Donenfeld"  wrote:

(Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
servers from roaming; the client would still roam in the eyes of the
server, but the server, would no longer roam in the eyes of the
client. In other words, an option -- gasp, a nob! -- to disable
roaming on a per-by-peer one-sided basis. As you know, I don't really
like nobs. And I'd hate to add this, and then for people to use it,
and then loose some nice aspects of roaming, if it's not really even
required.


If you know your other end point is at a fixed address you can use 
iptables (or the equivalent) to enforce this. I don't think it needs 
to be in WireGuard.

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

Re: wg showconf

[Bruno Wolff III]

On Sun, Nov 05, 2017 at 01:05:18 +0100,
 Markus Woschank  wrote:


I imaging specifying an endpoint IP for a peer and than discovering
that it connected from a different IP may be surprising to some. I
generally prefer for things to break if I configure them the wrong way
and not work "sometimes" (wrong endpoint IP on one side but the other
first initiating the connection most of the time).


Perhaps, but I think you are thinking about the function incorrectly. The 
peer address shouldn't be looked at as a restriction, but rather as a hint 
of where to send traffic to reach the peer if no traffic has been received 
from it. In that light, wg's behavior makes sense. The last IP address 
the peer was seen at, is normally the best place to look for it later.

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

Re: Fixing wg-quick's DNS= directive with a hatchet

[Bruno Wolff III]

On Fri, Oct 27, 2017 at 17:02:55 +0200,
 "Jason A. Donenfeld"  wrote:


I don't even... Are they serious? Who knows, but I've gotten a lot of
these, some via IRC, some sent to t...@wireguard.com. Kind of
disheartening to receive, but at least their complaints, however rude,
are something addressable with technical fixes.


I'm a Fedora user and I find WireGuard very useful. I have found you to 
be extremely responseful. I've reported incompatibilities with new 
development kernels that I don't have the skill to resolve myself and 
had fixes from you in less than an hour. That's crazy good support.

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

Re: crypto routing with subnets?

[Bruno Wolff III]

On Fri, Oct 20, 2017 at 20:02:43 +0200,
 "Jason A. Donenfeld"  wrote:

Hi Bruno,

Fortunately the inquires of this email are things that you could
figure out simply by trying, so if you want to learn-by-doing, you can
stop reading here and finish reading afterward.


I'm doing that too. Though I can't test the full set up right now as I 
can't safely change the router firmware until I get home.




Here are the solutions:

1. A peer is its public key, which means you can't have two different
peers with the same key, since they'd be the same peer. In essence
you're asking for a==a&&a!=a, which is always false.


I mostly wanted to make sure I had a correct mental model for how this 
worked. It seemed like it had to be that way.



2. Traffic will always go to the most specific route, which means the
/32 will take precedence over the /16.


For this one, I was a bit worried that it might work sometimes, but have 
problems later as I couldn't find an explicit answer in the documentation 
(I might have missed it.) saying it worked like normal network routing. The 
examples I saw were all disjoint networks.


Thank you for the clarifications.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

crypto routing with subnets?

[Bruno Wolff III]

I want to try to route a local network over wireguard through my router 
while not breaking a direct connection from my server while I'm testing 
the new setup. And I'm wondering if I'm going to need two wg devices or 
if I can use one?


On the destination the config would be something like:
[peer]
PublicKey = I37b0D0JbbBrSyH/oHjdMvL0P3m8kZQ5RiJ0Dha3ClU=
   Endpoint = 98.103.208.27:992
   AllowedIPs = 192.168.7.1/32
   PersistentKeepalive = 25
[peer]
PublicKey = I37b0D0JbbBrSyH/oHjdMvL0P3m8kZQ5RiJ0Dha3ClU=
   Endpoint = 98.103.208.26:992
   AllowedIPs = 192.168.0.0/16
   PersistentKeepalive = 25

It seems like this should work, though the public keys would be different 
in the real setup. (The second peer doesn't exist yet, so I can't use its 
public key in the example.)


So my main question is will traffic to 192.168.7.1 go to the first peer even 
though it is covered by the network in the second peer or do I need to 
make a wg0 and wg1 and do the routing at the interface level?


If I actually left the public keys the same, would this still work? (The 
securtity domain is nearly the same as the hardware is in the same place.) 
I don't think it could work as I think this would break tracking what IP 
address was last used by each peer.


Eventually I want to do something a bit more complicated, because I will only 
want devices that connected to my router with wireguard (i.e. my devices, 
not guests on my network) to be able to send packets over that tunnel. 
But for now traffic going through the tunnel doesn't get any access where I 
would be worried about guest traffic using the tunnel. At that time the server 
and router peer networks will be disjoint.

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

Re: trouble installing on Fedora and CentOS

[Bruno Wolff III]

On Tue, Aug 08, 2017 at 12:58:58 -0700,
 adam souzis  wrote:


The bad news is I was unable to get Wireguard working on either CentOS 7,
Fedora 26 or Fedora 25 (running these on AWS), it doesn't appear to be
installing the kernel module properly.


I run it on rawhide (Fedora 27 effectivel) by building from source.

I have a local clone of the git repo and do the following:
cd WireGuard/src
make clean all
su
make install

That installs the kernel module in the running kernel. You'll need kernel-devel 
installed and maybe kernel-headers. If you are updating the module, you will 
want to stop wireguard and use rmmod wireguard to remove the existing module, 
so the new one will get loaded (or reboot the system).

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

Re: Compile time assertion failure

[Bruno Wolff III]

On Wed, Aug 02, 2017 at 14:38:59 +0200,
 "Jason A. Donenfeld"  wrote:


Thanks for the report. Looks like I was relying on optimization
behavior of a gcc newer than yours. I'll revert.


commit 107735eaea0f48c1f5bfc0a6ca82f1879a850b98 (HEAD -> master, origin/master, 
origin/HEAD)
Author: Jason A. Donenfeld 
Date:   Tue Aug 1 22:47:26 2017 +0200

   routingtable: unbloat BUG()
   
   Really isn't necessary.


fixes the problem for me. I tested building and connecting to another 
machine.


Thanks!
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Compile time assertion failure

[Bruno Wolff III]

On Wed, Aug 02, 2017 at 07:24:30 -0500,
 Bruno Wolff III  wrote:
The problem seems to have been triggered by a recent (in the last few 
commits) rather than by a change to the Fedora kernel.


It starts happening with the following commit:

commit 18fe2082601b79cb27936b5910d2ef36cc94d5d3 (HEAD -> master)
Author: Jason A. Donenfeld 
Date:   Tue Aug 1 22:47:26 2017 +0200

   routingtable: demand optimization
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Compile time assertion failure

[Bruno Wolff III]

The problem seems to have been triggered by a recent (in the last few 
commits) rather than by a change to the Fedora kernel.

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

Compile time assertion failure

[Bruno Wolff III]

I'm seeing the following:

[bruno@wolff src]$ make clean all
make -C /lib/modules/4.13.0-0.rc3.git0.1.fc27.i686+PAE/build 
M=/home/bruno/WireGuard/src clean
make[1]: Entering directory '/usr/src/kernels/4.13.0-0.rc3.git0.1.fc27.i686+PAE'
 CLEAN   /home/bruno/WireGuard/src/.tmp_versions
 CLEAN   /home/bruno/WireGuard/src/Module.symvers
make[1]: Leaving directory '/usr/src/kernels/4.13.0-0.rc3.git0.1.fc27.i686+PAE'
make -C tools clean
make[1]: Entering directory '/home/bruno/WireGuard/src/tools'
rm -f wg *.o *.d
make[1]: Leaving directory '/home/bruno/WireGuard/src/tools'
make -C /lib/modules/4.13.0-0.rc3.git0.1.fc27.i686+PAE/build 
M=/home/bruno/WireGuard/src modules
make[1]: Entering directory '/usr/src/kernels/4.13.0-0.rc3.git0.1.fc27.i686+PAE'
 CC [M]  /home/bruno/WireGuard/src/main.o
 CC [M]  /home/bruno/WireGuard/src/noise.o
 CC [M]  /home/bruno/WireGuard/src/device.o
 CC [M]  /home/bruno/WireGuard/src/peer.o
 CC [M]  /home/bruno/WireGuard/src/timers.o
 CC [M]  /home/bruno/WireGuard/src/data.o
 CC [M]  /home/bruno/WireGuard/src/send.o
 CC [M]  /home/bruno/WireGuard/src/receive.o
 CC [M]  /home/bruno/WireGuard/src/socket.o
 CC [M]  /home/bruno/WireGuard/src/config.o
 CC [M]  /home/bruno/WireGuard/src/hashtables.o
 CC [M]  /home/bruno/WireGuard/src/routingtable.o
In file included from ./include/uapi/linux/stddef.h:1:0,
from ./include/linux/stddef.h:4,
from ./include/uapi/linux/posix_types.h:4,
from ./include/uapi/linux/types.h:13,
from ./include/linux/types.h:5,
from /home/bruno/WireGuard/src/compat/compat.h:8,
from :0:
In function ‘common_bits’,
   inlined from ‘node_placement.constprop’ at 
/home/bruno/WireGuard/src/routingtable.c:170:39,
   inlined from ‘add.part.1’ at /home/bruno/WireGuard/src/routingtable.c:195:6:
./include/linux/compiler.h:542:38: error: call to ‘__compiletime_assert_129’ declared 
with attribute error: BUILD_BUG_ON failed: !__builtin_constant_p(bits) || (bits != 32 
&& bits != 128)
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
./include/linux/compiler.h:525:4: note: in definition of macro 
‘__compiletime_assert’
   prefix ## suffix();\
   ^~
./include/linux/compiler.h:542:2: note: in expansion of macro 
‘_compiletime_assert’
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
./include/linux/build_bug.h:46:37: note: in expansion of macro 
‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
./include/linux/build_bug.h:70:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
/home/bruno/WireGuard/src/routingtable.c:129:2: note: in expansion of macro 
‘BUILD_BUG_ON’
 BUILD_BUG_ON(!__builtin_constant_p(bits) || (bits != 32 && bits != 128));
 ^~~~
In function ‘common_bits’,
   inlined from ‘add.part.1’ at /home/bruno/WireGuard/src/routingtable.c:215:9:
./include/linux/compiler.h:542:38: error: call to ‘__compiletime_assert_129’ declared 
with attribute error: BUILD_BUG_ON failed: !__builtin_constant_p(bits) || (bits != 32 
&& bits != 128)
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
./include/linux/compiler.h:525:4: note: in definition of macro 
‘__compiletime_assert’
   prefix ## suffix();\
   ^~
./include/linux/compiler.h:542:2: note: in expansion of macro 
‘_compiletime_assert’
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
./include/linux/build_bug.h:46:37: note: in expansion of macro 
‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
./include/linux/build_bug.h:70:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
/home/bruno/WireGuard/src/routingtable.c:129:2: note: in expansion of macro 
‘BUILD_BUG_ON’
 BUILD_BUG_ON(!__builtin_constant_p(bits) || (bits != 32 && bits != 128));
 ^~~~
make[2]: *** [scripts/Makefile.build:303: 
/home/bruno/WireGuard/src/routingtable.o] Error 1
make[1]: *** [Makefile:1515: _module_/home/bruno/WireGuard/src] Error 2
make[1]: Leaving directory '/usr/src/kernels/4.13.0-0.rc3.git0.1.fc27.i686+PAE'
make: *** [Makefile:28: module] Error 2

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

Re: Looks like 4.13 introduces a new incompatibility

[Bruno Wolff III]

On Mon, Jul 10, 2017 at 05:03:42 +0200,
 "Jason A. Donenfeld"  wrote:


I need to annoy Ted Tso about this. It'll get merged for rc1 or rc2.


Linus merged it a couple of hours ago, so it will make rc1. I'll be able 
to use Fedora kernels again early next week. I'm going to build another 
kernel manually in the mean time. I'll let you know if there is a problem, 
otherwise we can consider this issued closed.

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

Re: Looks like 4.13 introduces a new incompatibility

[Bruno Wolff III]

On Mon, Jul 10, 2017 at 05:26:50 +0200,
 "Jason A. Donenfeld"  wrote:

These two commits:

https://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git/patch/?id=e297a783e41560b44e3c14f38e420cba518113b8
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git/patch/?id=da9ba564bd683374b8d319756f312821b8265b06


I'm trying it out, but the kernel build will be slow and most likely I won't 
be able to test it until tomorrow afternoon.


(I'm cherry picking the two commits into Linus' current master. This doesn't 
include any patches Fedira is carrying.)

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

Re: Looks like 4.13 introduces a new incompatibility

[Bruno Wolff III]

On Mon, Jul 10, 2017 at 05:03:42 +0200,
 "Jason A. Donenfeld"  wrote:


I need to annoy Ted Tso about this. It'll get merged for rc1 or rc2.


OK. I'll confirm when it builds again. I might try it out early if Tso 
has it in a public develoment tree before it gets to Linus' tree. This 
might show up other issues in things that build after cookie.o and so might 
be worthwhile even if building kernels from source is otherwise not usually 
worth the effort for me.

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

Re: Looks like 4.13 introduces a new incompatibility

[Bruno Wolff III]

On Mon, Jul 10, 2017 at 04:01:04 +0200,
 "Jason A. Donenfeld"  wrote:

Hey Bruno,

Thanks for the heads up. Does this fix it?

https://git.zx2c4.com/WireGuard/commit/?id=dd007ad550b3def8a858e57aa718af9b00047a28


It looks like it fixed the problem. (At least device.o gets built.) But it 
seems there is another problem.


[bruno@wolff src]$ make clean all
make -C /lib/modules/4.13.0-0.rc0.git3.1.fc27.i686+PAE/build 
M=/home/bruno/WireGuard/src clean
make[1]: Entering directory '/usr/src/kernels/4.13.0-0.rc0.git3.1.fc27.i686+PAE'
 CLEAN   /home/bruno/WireGuard/src/.tmp_versions
make[1]: Leaving directory '/usr/src/kernels/4.13.0-0.rc0.git3.1.fc27.i686+PAE'
make -C tools clean
make[1]: Entering directory '/home/bruno/WireGuard/src/tools'
rm -f wg *.o *.d
make[1]: Leaving directory '/home/bruno/WireGuard/src/tools'
make -C /lib/modules/4.13.0-0.rc0.git3.1.fc27.i686+PAE/build 
M=/home/bruno/WireGuard/src modules
make[1]: Entering directory '/usr/src/kernels/4.13.0-0.rc0.git3.1.fc27.i686+PAE'
 CC [M]  /home/bruno/WireGuard/src/main.o
 CC [M]  /home/bruno/WireGuard/src/noise.o
 CC [M]  /home/bruno/WireGuard/src/device.o
 CC [M]  /home/bruno/WireGuard/src/peer.o
 CC [M]  /home/bruno/WireGuard/src/timers.o
 CC [M]  /home/bruno/WireGuard/src/data.o
 CC [M]  /home/bruno/WireGuard/src/send.o
 CC [M]  /home/bruno/WireGuard/src/receive.o
 CC [M]  /home/bruno/WireGuard/src/socket.o
 CC [M]  /home/bruno/WireGuard/src/config.o
 CC [M]  /home/bruno/WireGuard/src/hashtables.o
 CC [M]  /home/bruno/WireGuard/src/routingtable.o
 CC [M]  /home/bruno/WireGuard/src/ratelimiter.o
 CC [M]  /home/bruno/WireGuard/src/cookie.o
/home/bruno/WireGuard/src/cookie.c: In function ‘cookie_message_create’:
/home/bruno/WireGuard/src/cookie.c:156:2: error: implicit declaration of 
function ‘get_random_bytes_wait’; did you mean ‘get_random_bytes_arch’? 
[-Werror=implicit-function-declaration]
 get_random_bytes_wait(dst->nonce, COOKIE_NONCE_LEN);
 ^
 get_random_bytes_arch
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:303: /home/bruno/WireGuard/src/cookie.o] 
Error 1
make[1]: *** [Makefile:1512: _module_/home/bruno/WireGuard/src] Error 2
make[1]: Leaving directory '/usr/src/kernels/4.13.0-0.rc0.git3.1.fc27.i686+PAE'
make: *** [Makefile:28: module] Error 2

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

Looks like 4.13 introduces a new incompatibility

[Bruno Wolff III]

With Fedora's 4.13.0-0.rc0.git3.1.fc27 kernel, master no longer compiles. 
It is still a week before rc1 and I can use 4.12 on the relevant machines, 
but I thought I'd give a heads up.


[bruno@wolff src]$ make clean all
make -C /lib/modules/4.13.0-0.rc0.git3.1.fc27.i686+PAE/build 
M=/home/bruno/WireGuard/src clean
make[1]: Entering directory '/usr/src/kernels/4.13.0-0.rc0.git3.1.fc27.i686+PAE'
 CLEAN   /home/bruno/WireGuard/src/.tmp_versions
make[1]: Leaving directory '/usr/src/kernels/4.13.0-0.rc0.git3.1.fc27.i686+PAE'
make -C tools clean
make[1]: Entering directory '/home/bruno/WireGuard/src/tools'
rm -f wg *.o *.d
make[1]: Leaving directory '/home/bruno/WireGuard/src/tools'
make -C /lib/modules/4.13.0-0.rc0.git3.1.fc27.i686+PAE/build 
M=/home/bruno/WireGuard/src modules
make[1]: Entering directory '/usr/src/kernels/4.13.0-0.rc0.git3.1.fc27.i686+PAE'
 CC [M]  /home/bruno/WireGuard/src/main.o
 CC [M]  /home/bruno/WireGuard/src/noise.o
 CC [M]  /home/bruno/WireGuard/src/device.o
/home/bruno/WireGuard/src/device.c:372:14: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 .newlink  = newlink,
 ^~~
/home/bruno/WireGuard/src/device.c:372:14: note: (near initialization for 
‘link_ops.newlink’)
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:303: /home/bruno/WireGuard/src/device.o] 
Error 1
make[1]: *** [Makefile:1512: _module_/home/bruno/WireGuard/src] Error 2
make[1]: Leaving directory '/usr/src/kernels/4.13.0-0.rc0.git3.1.fc27.i686+PAE'
make: *** [Makefile:28: module] Error 2
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: I will mail you WireGuard stickers

[Bruno Wolff III]

On Thu, May 18, 2017 at 15:17:35 +0200,
 "Jason A. Donenfeld"  wrote:


Today an order of WireGuard stickers arrived. If you've come to any
conferences where there's been a WireGuard talk, then you've
undoubtedly gotten some stickers. If not, however, you might be
missing out. Want me to send you some? Or a decent amount of them for
a local hacker space?


I don't want to have you mail me stuff from Paris, but if the artwork 
were available I might make a copy locally. I'm guessing you use the 
Serpent from the web page in some manner?

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

Re: Compatibiliyt issues between 0.0.20170115 and 0.0.20170517

[Bruno Wolff III]

On Thu, May 18, 2017 at 15:39:48 -0400,
 Daniel Kahn Gillmor  wrote:

On Thu 2017-05-18 20:43:11 +0200, Jason A. Donenfeld wrote:


Only use 0.0.20170517.


i think this was the first incompatible revision that has been released.
is that correct?


No. There have been a few incompatible upgrades. I usually upgrade both 
ends at the same time, but I want to start using the LEDE version and 
once I do, I'll need to be more careful.

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

Re: Wireguard is not building on Fedora with 4.12 rc1 kernels

[Bruno Wolff III]

On Wed, May 17, 2017 at 10:25:46 -0500,
 Bruno Wolff III  wrote:

On Wed, May 17, 2017 at 17:16:20 +0200,
"Jason A. Donenfeld"  wrote:

Hi again,

I think I might have fixed this.

git fetch && git reset --hard origin/master

And then see if it builds now?


It builds now. In about 15 minutes I'll have it tested.


It took a lot longer than I thought because the remote machine is pretty 
slow and I needed to reinstall the kernel-PAE-devel package.


The two machines do not seem to be connecting. The remote machine 
is using 4.12.0-0.rc0.git2.1.fc27.i686+PAE. So this could potentially 
be a kernel problem. I can reboot the remote machine tonight when I 
get home and see if things work when the kernels match.

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

Re: Wireguard is not building on Fedora with 4.12 rc1 kernels

[Bruno Wolff III]

On Wed, May 17, 2017 at 17:16:20 +0200,
 "Jason A. Donenfeld"  wrote:

Hi again,

I think I might have fixed this.

git fetch && git reset --hard origin/master

And then see if it builds now?


It builds now. In about 15 minutes I'll have it tested.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Wireguard is not building on Fedora with 4.12 rc1 kernels

[Bruno Wolff III]

It looks like the test for memneq is broken and both the kernel and compat 
versions get used at the same time.


[bruno@cerberus src]$ make
make -C /lib/modules/4.12.0-0.rc1.git0.1.fc27.x86_64/build 
M=/home/bruno/WireGuard/src modules
make[1]: Entering directory '/usr/src/kernels/4.12.0-0.rc1.git0.1.fc27.x86_64'
 CC [M]  /home/bruno/WireGuard/src/main.o
 CC [M]  /home/bruno/WireGuard/src/noise.o
In file included from /home/bruno/WireGuard/src/noise.c:15:0:
./include/crypto/algapi.h:389:19: error: redefinition of ‘crypto_memneq’
static inline int crypto_memneq(const void *a, const void *b, size_t size)
  ^
In file included from :0:0:
/home/bruno/WireGuard/src/compat/memneq/include.h:2:19: note: previous 
definition of ‘crypto_memneq’ was here
static inline int crypto_memneq(const void *a, const void *b, size_t size)
  ^
make[2]: *** [scripts/Makefile.build:303: /home/bruno/WireGuard/src/noise.o] 
Error 1
make[1]: *** [Makefile:1516: _module_/home/bruno/WireGuard/src] Error 2
make[1]: Leaving directory '/usr/src/kernels/4.12.0-0.rc1.git0.1.fc27.x86_64'
make: *** [Makefile:28: module] Error 2

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

Re: Kernel commit d35a00b8e33dab7385f724e713ae71c8be0a49f4 breaks wireguard

[Bruno Wolff III]

On Mon, Feb 27, 2017 at 15:03:45 -0800,
 "Jason A. Donenfeld"  wrote:

Fixed


Thanks!

I rebuilt the latest version on both 4.11 and 4.10 Fedora kernels and it 
seems to be working as expected.

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

Re: Kernel commit d35a00b8e33dab7385f724e713ae71c8be0a49f4 breaks wireguard

[Bruno Wolff III]

On Mon, Feb 27, 2017 at 16:14:44 -0600,
 Bruno Wolff III  wrote:

On Mon, Feb 27, 2017 at 14:10:18 -0800,
"Jason A. Donenfeld"  wrote:

Thanks! I wasn't compiling with the options to hit this, so I didn't
see it before. Should be fixed now.


Thank you.

It now builds cleanly and it at least appears to be working correctly 
in simple testing.


I am now having a problem building it on a 4.10 kernel. (I already have 
a build from the weekend, so I don't need this to make anything work 
right now.)


This is from another Fedora machine that I haven't switched to a 4.11 
kernel yet. The base system for this one is F25, the one that it work 
on was f26/rawhide and has a gcc 7 version. This one has gcc-6.3.1-1.fc25.i686.


make -C /lib/modules/4.10.0-1.fc26.i686+PAE/build M=/home/bruno/WireGuard/src 
modules
make[1]: Entering directory '/usr/src/kernels/4.10.0-1.fc26.i686+PAE'
 CC [M]  /home/bruno/WireGuard/src/main.o
In file included from :0:0:
/home/bruno/WireGuard/src/compat/compat.h:165:40: warning: ‘struct sk_buff’ 
declared inside parameter list will not be visible outside of this definition 
or declaration
static inline void skb_reset_tc(struct sk_buff *skb)
   ^~~
/home/bruno/WireGuard/src/compat/compat.h: In function ‘skb_reset_tc’:
/home/bruno/WireGuard/src/compat/compat.h:168:5: error: dereferencing pointer 
to incomplete type ‘struct sk_buff’
 skb->tc_verd = 0;
^~

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