Vouching for this, sounds quite useful.
On 4/30/20 3:55 PM, Martin Hauke wrote:
> Add file wireguard.target, which allows you to stop or restart all
> instances.
> ---
> src/systemd/wg-quick@.service | 1 +
> src/systemd/wireguard.target | 2 ++
> 2 files changed, 3 insertions(+)
> create mode
On 2018-06-07 10:21, Roman Mamedov wrote:
On Thu, 07 Jun 2018 09:40:08 +0200
Riccardo Berto wrote:
Just want to report that I can't add a wg interface of type wireguard
with linux 4.17.0 on aarch64 (Raspberry Pi 3).
Error message: `RTNETLINK answers: Operation not supported`.
I&#x
Just want to report that I can't add a wg interface of type wireguard
with linux 4.17.0 on aarch64 (Raspberry Pi 3).
Error message: `RTNETLINK answers: Operation not supported`.
I'm using ArchLinuxARM. Downgrading to 4.16.x makes the issue dissapear.
This is not high-priority so please Jason,
The current concept of WG has indeed certain pros over other VPN
solutions, but like most everything else in life, it has its cons too
and it will be determined by the user what suits best. Time will tell
the adoption/penetration level of WG is achieving. For me unfortunately
the cons (not just wh
On 2018-04-25 13:51, Jason A. Donenfeld wrote:
Hi Riccardo,
We really should debug this in real time. Perhaps pop into #wireguard
on Freenode?
Jason
I investigated the issue I was having with the 2 rpi3s and I finally got
it working somehow (aka without knowing exactly what I did wrong).
I
It's really great to hear that RPi3 can run WireGuard. That excludes the
architectural difference from the issues I'm having.
I tried to reach you on freenode in 2 occasions last week, I also
mentioned you but the channel wasn't active. I'm travelling atm and I'll
be afk until monday, so next
On 2018-04-20 22:31, Riccardo Berto wrote:
On 2018-04-20 21:51, Jason A. Donenfeld wrote:
Could you let me know which kernel the non-working rapsis are running?
Also, have you tried this over different internet connections and
experienced the same thing?
I haven't tried this under diff
On 2018-04-20 21:51, Jason A. Donenfeld wrote:
Could you let me know which kernel the non-working rapsis are running?
Also, have you tried this over different internet connections and
experienced the same thing?
I haven't tried this under different internet connection but one thing I
must add
Sorry for the late answer, I've been busy with exams this week.
I updated WireGuard to the latest snapshot 20180420 on both server and
peers.
I use unique key pairs for every host and I'm using the right
privkey/pubkey combo, I just checked manually via the `wg pubkey`
command.
I also tried
On 2018-04-14 03:26, Jason A. Donenfeld wrote:
Hi Riccardo,
Based on those tcpdump timestamps, it looks like the handshake
response happens nearly immediately after the handshake initiation.
Yet from your description, it appears only after many moments. In my
experience, tcpdump blocks like this
I didn't think about using tcpdump by checking the default interface,
thanks for the suggestion!
I updated to the April 2018 snapshot on every peer.
I removed the server endpoints and since I was there, switched the
server port to 51820, the protocol "default" one. It still works for the
lapt
I wasn't clear in the previous email, I'm only seeing ICMP requests and
not answers so no traffic through the tunnel.
Also, I have not setup forwarding to another interface, maybe that's the
next step for a road-warrior OpenVPN-like setup, but at the moment I'm
keeping things simple and I'm just
WireGuard doesn't always work with my devices.
I ran out of options for troubleshooting it so I'm writing here, hoping
for a stable solution. I see it's not a strict devel-only mailing list
but if I'm off-topic I apologize in advance and I'll fade-out in the
background, waiting for better times
13 matches
Mail list logo
