paths
through the allowed-ip loop.
FreeBSD-Coverity: 1500405
Signed-off-by: Kyle Evans
---
src/ipc-freebsd.h | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/src/ipc-freebsd.h b/src/ipc-freebsd.h
index b5be15b..78064e9 100644
--- a/src/ipc-freebsd.h
From: Kyle Evans
The `err` path in kernel_set_device() will attempt to free() allocated
nvl_peers, but these two cases meant we could end up attempting a use
after free or a double free, as we rely on nvlist_destroy(NULL) being
a NOP as well as free(NULL).
FreeBSD-Coverity: 1500421
Signed
https://git.zx2c4.com/wireguard-tools/commit/?id=7b2ae7aa2f52fbac65874a641cbfbb0182d0ba46
Applied, thanks!
(Very excited about all this...)
Jason
From: Kyle Evans
When we re-added if_wg to the tree, we changed directories in dev to
strip the if_ (we don't use this prefix for other interfaces'
directories). Adjust it here as a convenience, so that when we import
wireguard-tools to FreeBSD the path will just work as-is with our usual
build
> > > Tonight after updating kernel freebsd current I got coredump with
> > > > wireguard enabled kernel module.
> > > > ...
> > > Thanks. Is there a __FreeBSD_version__ change that corresponds?
> >
> > It is not an exact match, but was bumped to
Hi Ed,
On Wed, Aug 31, 2022 at 8:18 PM Ed Maste wrote:
>
> On Mon, 29 Aug 2022 at 12:18, Jason A. Donenfeld wrote:
> > On Tue, Aug 23, 2022 at 12:26:21PM +0300, Michael Pro wrote:
> > > Tonight after updating kernel freebsd current I got coredump with
> > > w
On Mon, 29 Aug 2022 at 12:18, Jason A. Donenfeld wrote:
> On Tue, Aug 23, 2022 at 12:26:21PM +0300, Michael Pro wrote:
> > Tonight after updating kernel freebsd current I got coredump with
> > wireguard enabled kernel module.
> > ...
> Thanks. Is there a __
FreeBSD Current (14.0)
http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/
sources from iso or github - no matther
Changes to src are made by commit e7d02be19d40063783d6b8f1ff2bc4c7170fd434
Author Gleb Smirnoff Wed, 17 Aug 2022 21:50:32
+0300 (11:50 -0700)
ср, 31 авг. 2022 г. в 21:18
On Tue, Aug 23, 2022 at 12:26:21PM +0300, Michael Pro wrote:
> Tonight after updating kernel freebsd current I got coredump with
> wireguard enabled kernel module.
>
> As is
> https://reviews.freebsd.org/D36232
> D36232 protosw: refactor protosw and domain static decl
Tonight after updating kernel freebsd current I got coredump with
wireguard enabled kernel module.
As is
https://reviews.freebsd.org/D36232
D36232 protosw: refactor protosw and domain static declaration and
load (freebsd.org)
in wireguard-freebsd/src/support.h
...
error = (*so->so_pr
Hi,
I tested this snapshot on my setup for 10 days now and it works
perfectly without any problems.
My setup is fairly simple: central VPN server (FreeBSD 13.1), two
servers on branch sites (each behind NAT) and a mobile Android client.
VPN's are used for management type activities, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20220615, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20220614, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20220610, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
Other than the obvious benefits, this prevents "ifconfig: WARNING: setting
interface
address without mask is deprecated, default mask may not be correct." from
appearing
on the next start after save.
Signed-off-by: Dan Ponte
---
src/wg-quick/freebsd.bash | 12 +++-
1 file changed, 7
On Tue, Apr 5, 2022 at 5:49 PM John Baldwin wrote:
>
> I have a series of patches against the FreeBSD driver available on
> the jb-wip branch which I believe is (mostly) a candidate for merging
> to master. The changes in the branch include:
>
> - 9d1881a Only include co
I have a series of patches against the FreeBSD driver available on
the jb-wip branch which I believe is (mostly) a candidate for merging
to master. The changes in the branch include:
- 9d1881a Only include compat.h for if_wg.c and fix build with an obj directory.
This patch permits building
I've done some preliminary tests with the new if_wg kernel module on amd64 with
freebsd 13-p4 and 14.
It works fine AFAICT. My previous issue's with wireguard-freebsd are also
resolved.
Good work!
Thanks
Peter
On Tue, Nov 9, 2021 at 11:19 AM Ryan Roosa wrote:
>
> On Wed, Oct 27, 2021 at 7:45 PM Ryan Roosa wrote:
> >
> > On Tue, Oct 26, 2021 at 5:29 AM Jason A. Donenfeld wrote:
> > >
> > > Hi Ryan,
> > >
> > > Thanks for the report. Kyle saw your reddit post earlier and tracked
> > > this down, I
Just wanted to provide some feedback that pfSense development
snapshots of 2.6.0 running WireGuard package v0.1.5_2 include the fix
and there I have validated that removing WAN connectivity at various
intervals up to 10 minutes no longer impacts subsequent handshaking
once the connection is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20211105, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
Hi Kyle,
1) Is it possible on FreeBSD to enable some kind of logging? I did made
a small configuration error with my first client and it was hard to find
the error, because there does not seem to be any logging at all. Some
logging information would be appreciated and probably wold have
On Wed, Nov 3, 2021 at 5:55 AM Frank Volf wrote:
>
>
> Hi,
>
> This weekend I installed Wireguard on FreeBSD 13.0 and until now
> everything seems to work fine (I use the kernel module).
> Installation and configuration was easy and connecting with the Android
>
Hi,
This weekend I installed Wireguard on FreeBSD 13.0 and until now
everything seems to work fine (I use the kernel module).
Installation and configuration was easy and connecting with the Android
app works great as well.
I do have a few questions.
1) Is it possible on FreeBSD to enable
Hi Ryan,
Thanks for the report. Kyle saw your reddit post earlier and tracked
this down, I think/hope, to a bug in the state machine cranking. I
committed the fix here -- https://w-g.pw/l/yQTw -- which will be part
of the next snapshot. Hopefully that will fix the issue, but if it
doesn't, please
Hello,
First off, I want to say thank you for the FreeBSD kernel module work
as it is greatly appreciated by myself and many others running *sense
firewalls :)
Generally wireguard-freebsd (wireguard-kmod 0.0.20210606_1) is running
quite well in my experience however, there is one issue which I
On Tue, Jun 8, 2021 at 1:00 PM ben edmunds wrote:
> By not showing this to the user to avoid confusion we actually would
> create confusion in this scenario as the kernel module is performing the
> clamping but the user would have no knowledge of this and leads to
> issues being opened that are a
The issue here for pfSense is that the private key will be viewable just
like it is within native wireguard clients in the peer config options
and needs to be viewable here for admin and debug purposes.
With regards to clamping and hiding this from users its tricky as it
leads to red heroin
On 6/7/21, Christian McDonald wrote:
> One byproduct of this exercise was some code that I whipped
> up that can at least detect a clamped vs unclamped key. This might
> prove useful for informing a user of what is going on and thus
> eliminating this class of erroneous bug report entirely.
I'd
Ah that makes sense. I spent some quality time playing with the bit
arithmetic and I see what you mean now. Thanks for that snippet and
direction. One byproduct of this exercise was some code that I whipped
up that can at least detect a clamped vs unclamped key. This might
prove useful for
On 6/6/21, Christian McDonald wrote:
> Would it not be better for wg to just fail outright instead of
> transforming a poorly generated key entered by a user, regardless of
> where the key came from? Especially if that problematic key passes the
> regex validation that was provided in another
Would it not be better for wg to just fail outright instead of
transforming a poorly generated key entered by a user, regardless of
where the key came from? Especially if that problematic key passes the
regex validation that was provided in another thread in this email
list? If not, what would be
It looks like whatever is generating those private keys is not
clamping them. Specifically, all private keys should undergo this
transformation:
key[0] &= 248;
key[31] = (key[31] & 127) | 64;
In your case, your `Lm` prefix (first byte: 0x2c) is being anded with
248, and thus
Hi Jason,
I've got an interesting case here. I've got what appears to be a few
private keys provided by Mullvad that are being mangled by wg(8) on
FreeBSD12.2 (pfSense 2.5.1+).
Private key ```Lm0BA4UyPilHH5qnXCfr6Lw8ynecOPor88tljLy3ALk=``` ...
becomes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210606, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210503, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210502, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210428, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
Fixed here a few days ago:
https://git.zx2c4.com/wireguard-freebsd/commit/?id=cb7cd32a7c47151c161603cdc8a1c21f48550a65
I'll have a new snapshot out likely tomorrow.
Jason
Greetings,
Here are my versions:
wireguard-kmod 0.0.20210424_1
wireguard-tools 1.0.20210424
I'm running the latest snapshot code (see above) on FreeBSD 12.2. I am
seeing kernel panics when tearing down tunnels using `wg-quick down`
and even `ifconfig wg0 destroy` when the interface has IPv6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210424, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
hance you could test this patch to Bird (*instead of* the
>> > > previous one that removes the check from the Babel code)?
>> >
>> > The patch is working on FreeBSD 13.0.
>>
>> Just FYI, the previous patch was added to ports, so I wanted to double
>> che
d of* the
> > > previous one that removes the check from the Babel code)?
> >
> > The patch is working on FreeBSD 13.0.
>
> Just FYI, the previous patch was added to ports, so I wanted to double
> check that you removed that previous patch before adding this one...
Y
gt; The patch is working on FreeBSD 13.0.
Just FYI, the previous patch was added to ports, so I wanted to double
check that you removed that previous patch before adding this one...
On Mon, Apr 19, 2021 at 08:25:46PM +0200, Toke Høiland-Jørgensen wrote:
> Stefan, any chance you could test this patch to Bird (*instead of* the
> previous one that removes the check from the Babel code)?
The patch is working on FreeBSD 13.0.
Kind regards,
Stefan
Basically, ff00::/8 addresses are treated
>>> differently, and they're blocked unless the interface sets
>>> IFF_MULTICAST. So I've committed
>>> https://git.zx2c4.com/wireguard-freebsd/commit/?id=a7a84a17faf784857f076e37aa4818f6b6c12a95
>>> to do this.
>>
>>
Hi Frank,
On Sat, Apr 17, 2021 at 9:23 AM Frank Behrens wrote:
>
>
> Am 17.04.2021 um 17:00 schrieb Jason A. Donenfeld:
> > Does this actually fix or change anything? Don't new sockets have
> > fib==0 right out of the gate already?
>
> New sockets inherit the fib from the current process. If you
Am 17.04.2021 um 17:00 schrieb Jason A. Donenfeld:
Does this actually fix or change anything? Don't new sockets have
fib==0 right out of the gate already?
New sockets inherit the fib from the current process. If you create
the wg interface from a process with different fib, that fib will
Hi Frank,
On 4/17/21, Frank Behrens wrote:
> Hi Jason!
>
> Am 13.04.2021 um 04:57 schrieb Jason A. Donenfeld:
>> Can you let me know if this fixes the issue?
>>
>> https://git.zx2c4.com/wireguard-freebsd/commit/?id=cdb18ebf44a5babb57cddccd6b33e9f19cfdf365
>
>
Hi Jason!
Am 13.04.2021 um 04:57 schrieb Jason A. Donenfeld:
Can you let me know if this fixes the issue?
https://git.zx2c4.com/wireguard-freebsd/commit/?id=cdb18ebf44a5babb57cddccd6b33e9f19cfdf365
It looks better, but a little too much optimized. ;-)
The fix is in https://git.zx2c4.com
On Fri, Apr 16, 2021 at 9:17 AM Jason A. Donenfeld wrote:
> > I set up a lab and will do some testing with version before and after
> > the change, maybe for FRR it's enough to set NBMA or similar.
>
> Could you send a minimal bird config that's broken so that I can
> reproduce the problem and
Hi Michael,
On 4/16/21, Muenz, Michael wrote:
> Am 16.04.2021 um 10:57 schrieb Stefan Haller:
>> After applying Toke's patch for bird and your Wireguard patch in
>> a7a84a17faf784 everything is working as before (with minor config
>> changes).
>>
>> Just for the record, my previous configuration
Am 16.04.2021 um 10:57 schrieb Stefan Haller:
After applying Toke's patch for bird and your Wireguard patch in
a7a84a17faf784 everything is working as before (with minor config
changes).
Just for the record, my previous configuration looked like this (using
POINTTOPOINT interfaces, I use
and they're blocked unless the interface sets
>> IFF_MULTICAST. So I've committed
>> https://git.zx2c4.com/wireguard-freebsd/commit/?id=a7a84a17faf784857f076e37aa4818f6b6c12a95
>> to do this.
>
> That is also what I observed. Without IFF_MULTICAST I see the following
> err
ULTICAST. So I've committed
> https://git.zx2c4.com/wireguard-freebsd/commit/?id=a7a84a17faf784857f076e37aa4818f6b6c12a95
> to do this.
That is also what I observed. Without IFF_MULTICAST I see the following
error in bird's log:
bird[8045]: babel1: Socket error: IPV6_MULTICAST_IF: Can't assign
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210415, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
Hey Stefan, Toke,
I spent the day playing around with bird and babel and sorted out
FreeBSD's v6 situation. Basically, ff00::/8 addresses are treated
differently, and they're blocked unless the interface sets
IFF_MULTICAST. So I've committed
https://git.zx2c4.com/wireguard-freebsd/commit/?id
"Jason A. Donenfeld" writes:
> Hi Stefan,
>
> Sounds like Toke has come up with the optimal solution, so I think
> I'll drop the "link1" patch/hack.
>
> One thing I was wondering though, mostly for my own curiosity, is what
> config you're using that shows the problem, and how does the problem
>
Hi Stefan,
Sounds like Toke has come up with the optimal solution, so I think
I'll drop the "link1" patch/hack.
One thing I was wondering though, mostly for my own curiosity, is what
config you're using that shows the problem, and how does the problem
manifest?
I just put this in bird.conf:
Stefan Haller writes:
> Hi Toke,
>
> On Thu, Apr 15, 2021 at 12:14:04AM +0200, Toke Høiland-Jørgensen wrote:
>> That's because the babel protocol code is checking for Bird's internal
>> MULTICAST flag, which is set like:
>>
>> else if (fl & IFF_POINTOPOINT)/* PtP */
>> f.flags |=
Hi Toke,
On Thu, Apr 15, 2021 at 12:14:04AM +0200, Toke Høiland-Jørgensen wrote:
> That's because the babel protocol code is checking for Bird's internal
> MULTICAST flag, which is set like:
>
> else if (fl & IFF_POINTOPOINT)/* PtP */
> f.flags |= IF_MULTICAST;
> else if (fl &
"Jason A. Donenfeld" writes:
> Hey Toke,
>
> Regarding POINTTOPOINT flag in Linux vs FreeBSD -- apparently FreeBSD
> routes everything differently simply by virtue of the interface having
> that flag, whereas on Linux, PTP routing mode is only switched on if
>
Hey Toke,
Regarding POINTTOPOINT flag in Linux vs FreeBSD -- apparently FreeBSD
routes everything differently simply by virtue of the interface having
that flag, whereas on Linux, PTP routing mode is only switched on if
you actually add an address with a dest peer. So for FreeBSD, the
different
000
I will have a closer look why it doesn't work on FreeBSD but the same thing
works on Linux. I am probably missing something important.
Kind regards,
Stefan
[1]:
https://gitlab.nic.cz/labs/bird/-/blob/9c41e1ca3e93d4498eaa085139caf1545e08c1d8/proto/babel/babel.c#L1662
Hello everyone!
Today I tried switching to the if_wg kernel module. I observed that the
behaviour of the tunnel interface was changed to drop the POINTTOPOINT
and MULTICAST flags (8801509656e9).
For some reason the bird2 routing daemon is not picking up my interface
if there is only a /32
the interface is
> still used by bird:
>
> # ip l show dev wg1
> 4: wg1: mtu 1400 qdisc noqueue state UNKNOWN
> mode DEFAULT group default qlen 1000
>
> I will have a closer look why it doesn't work on FreeBSD but the same thing
> works on Linux. I am probably missing something
Hi Stefan,
WireGuard does not do multicast, so we probably won't set that flag.
You'll want to use babble over unicast anyway.
As far as the `ifconfig wg0 link1` trick I added yesterday goes... I'm
not totally convinced I'll keep that yet for the next snapshot. Does
bird completely ignore
Hi Osku,
We'll switch to using FreeBSD's opencrypto at some point, at which
point the performance will improve. Right now we're using boring
unoptimized reference implementations.
See https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057076.html
for more info. So far nobody has
Dear all,
has anyone else noticed the CPU consumption on FreeBSD kernel Wireguard?
For my test link, there is a net speed of 200 Mbit/s.
On esxi based host, transferring inside Wireguard tunnel, full speed
takes about 90% of xeon d-1541 host.
Doing this on CentOS 7, takes less than 20
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210412, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
Hi Frank,
Can you let me know if this fixes the issue?
https://git.zx2c4.com/wireguard-freebsd/commit/?id=cdb18ebf44a5babb57cddccd6b33e9f19cfdf365
Jason
Hello Jason!
Am 31.03.2021 um 21:11 schrieb Jason A. Donenfeld:
Thanks for the patch. Does the line `so4->so_fibnum = so6->so_fibnum =
sc->sc_socket.so_fibnum;` also need to be changed too in initiation,
or is that one fine?
Thanks for the pointer. That part has to be changed as well. I
Hello Jason!
Am 31.03.2021 um 21:11 schrieb Jason A. Donenfeld:
Hi Frank,
Thanks for the patch. Does the line `so4->so_fibnum = so6->so_fibnum =
sc->sc_socket.so_fibnum;` also need to be changed too in initiation,
or is that one fine?
Good catch! I'll check this in the next few days (and
Hi Frank,
Thanks for the patch. Does the line `so4->so_fibnum = so6->so_fibnum =
sc->sc_socket.so_fibnum;` also need to be changed too in initiation,
or is that one fine?
Jason
Hello!
Am 23.03.2021 um 06:51 schrieb Frank Behrens:
Am 22.03.2021 um 19:14 schrieb Jason A. Donenfeld:
Applied to git with some small modifications:
https://git.zx2c4.com/wireguard-freebsd/commit/?id=0a5c6abdfaa1f4f09269a222c1720e2ff3b8aa02
Thanky you! That looks very good.
I'm sorry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210323, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
Hi Jason!
Am 22.03.2021 um 19:14 schrieb Jason A. Donenfeld:
Applied to git with some small modifications:
https://git.zx2c4.com/wireguard-freebsd/commit/?id=0a5c6abdfaa1f4f09269a222c1720e2ff3b8aa02
Thanky you! That looks very good.
--
Frank Behrens
Osterwieck, Germany
encrypted packets.
> -> That is addressed by my patch and controlled by
> "ifconfig wg0 tunnelfib 1". Maybe wg(8) should receive also
> an option for that purpose, if other OS use equivalent functions.
>
> 3. The setting of special marks, useable in packet filter/firewall
Hi Frank,
> On 20. Mar 2021, at 6:05 PM, Frank Behrens wrote:
>
> 3. The setting of special marks, useable in packet filter/firewall
> processing. I guess, that is the meaning for "wg.. fwmark". I'm not
> sure, how best to implement that for FreeBSD. For ipfw(4) ther
e equivalent functions.
3. The setting of special marks, useable in packet filter/firewall
processing. I guess, that is the meaning for "wg.. fwmark". I'm not
sure, how best to implement that for FreeBSD. For ipfw(4) there is some
functionality using socket cookies, as already
On 2021-03-19 22:18, Jason A. Donenfeld wrote:
Hi Ashish,
Fixed:
https://git.zx2c4.com/wireguard-freebsd/commit/?id=bb59a61785322a086dfc437c51e7cbcd918a5241
Thanks for the report.
Jason
Seems to work as expected now, thank you.
--
Ashish
“There was truth and there was untruth, and if you
Good news! This is now in ports as net/wireguard-kmod. That means it
should eventually be built into a package too:
# pkg install wireguard-kmod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210319, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain secur
Hey Frank,
Thanks for the patch. That looks terrific. One question, though:
Right now we have the `wg set wg0 fwmark ...` mapped to
SO_USER_COOKIE, as I'm sure you saw there. But maybe FIB would be a
better thing to use for that? We could adjust wireguard-go to do the
same with the tuntap ioctl.
Hi again,
As well, you can now do:
git push g...@git.zx2c4.com:wireguard-freebsd master:fb/whatever-you-want
In other words, you have push access to all branches beginning with fb/ .
Poke me on IRC (I'm zx2c4) there if you want to chat about dev.
Jason
Thanks for the patch. I addressed this slightly differently here:
https://git.zx2c4.com/wireguard-freebsd/commit/?id=519e70d5fe88f1ae3c6d2318b22ecf927953fd02
I also trimmed those structs down a bit, as the latter members differ
between 13 and 14.
Hello Jason, hello community,
although I regret the recent removal of FreeBSD kernel driver I can live
with the present development model.
With the current sources in the external repository I could create a
working VPN for the first time with my Android phone. It works well,
thanks to all
Hi Ashish,
Fixed:
https://git.zx2c4.com/wireguard-freebsd/commit/?id=bb59a61785322a086dfc437c51e7cbcd918a5241
Thanks for the report.
Jason
Hi Ashish,
On Fri, Mar 19, 2021 at 8:06 AM Ashish wrote:
> I'm running if_wg kernel module (git revision: 5ef4d3efa691e71) on
> FreeBSD 13.0-RC2.
>
> With 172.18.10.1 being my local host's wireguard interface's IP address,
> I can receive SYN packets, but it does not s
wrote:
>
>
> [apologies, in case you receive duplicate messages]
>
> Hi,
>
> I'm running if_wg kernel module (git revision: 5ef4d3efa691e71) on
> FreeBSD 13.0-RC2.
>
> With 172.18.10.1 being my local host's wireguard interface's IP address,
> I can receive SYN pack
[apologies, in case you receive duplicate messages]
Hi,
I'm running if_wg kernel module (git revision: 5ef4d3efa691e71) on
FreeBSD 13.0-RC2.
With 172.18.10.1 being my local host's wireguard interface's IP address,
I can receive SYN packets, but it does not seem to send any
corresponding SYN
Hi,
I'm running if_wg kernel module (git revision: 5ef4d3efa691e71) on
FreeBSD 13.0-RC2.
With 172.18.10.1 being my local host's wireguard interface's IP address,
I can receive SYN packets, but it does not seem to send any
corresponding SYN/ACK.
=
01:26:26.327484 IP
ly yes, but from main?
>
> This is still -CURRENT and -CURRENT should be central place
> for development,
> even if we have phabricator for review.
It looks like Kyle has gone ahead with the revert anyway, so
development is now happening at:
https://git.zx2c4.com/wireguard-freebsd/
\o Hello,
noticed that after if_wg removal from stable/13 following patch is
needed for compiling the module.
I'm currently lacking a 14/CURRENT machine to assert that the
module compiles with these changes, but from checking the branch,
it looks like these definitions are there already, I
Kyle, you (and others) have been put in a position you never should have been
put in. You have earned respect from someone who could not be any more outside
the community of core FreeBSD developers for behaving like an adult and
publicly sharing your introspection. I’m sorry if this is seen
On Fri, Mar 19, 2021 at 8:03 AM Kyle Evans wrote:
>
> On Mon, Mar 15, 2021 at 9:47 AM Jason A. Donenfeld wrote:
> >
> > Hi everybody,
> >
> > [... snip ...]
> >
> > The first step was assessing the current state of the code the previous
> > developer had dumped into the tree. It was not pretty.
On Mon, Mar 15, 2021 at 9:47 AM Jason A. Donenfeld wrote:
>
> Hi everybody,
>
> [... snip ...]
>
> The first step was assessing the current state of the code the previous
> developer had dumped into the tree. It was not pretty. I imagined
> strange Internet voices jeering, “this is what gives C a
> > This is still -CURRENT and -CURRENT should be central place for development,
> > even if we have phabricator for review.
>
> It looks like Kyle has gone ahead with the revert anyway, so
> development is now happening at:
>
> https://git.zx2c4.com/wireguard-fre
kes sense and is understandable. It's been pretty miserable for all of us.
It looks like we'll eventually find somebody on the FreeBSD side of
things to take over where you left off, but hopefully for now in the
coming weeks things can just level out to some tranquility, so we can
get back to distraction-free coding wi
ement that I'm
stepping back from the wireguard-freebsd efforts.
You'll likely hear some things about me in the coming days. I'm sure
I've said more things in the past week and a half in anger that I
regret, and I'll have to live with that. I'd like to set the record
straight. Netgate person
1 - 100 of 148 matches
Mail list logo
