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
Strange. I've been running WG on an RPI 3 with Raspbian (Stretch) with no
problems. The Pi is reached via a squid proxy which tunnels out to a server in
the US.
On Wed, Apr 25, 2018, at 7:51 AM, Jason A. Donenfeld wrote:
> Hi Riccardo,
>
> We really should debug this in real time. Perhaps pop
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 different
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
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?
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
Oh, one thing that looks suspect is the bad UDP checksum. It appears
to be 0x92e3 every time, instead of the correct value (or 0).
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Hi Riccardo,
Hmm, I'm really not quite sure from looking at that tcpdump. Are you
able to do one in parallel from the raspi? (Make sure both clocks are
correct with ntpd, so we can synchronize the timestamps.)
Alternatively, maybe just log onto IRC next week and we can debug this
in real time?
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
Hi Riccardo,
That's a confusing result. The tcpdump also shows two sequences of
completed handshakes happening, about 7 seconds apart. It might be
best in the end to hop onto IRC next week, and we can debug this in
real time. But based on the erratic behavior, my only guess remaining
is that
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 when it has to do too many DNS
resolutions and
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
When you type "wg", does it show you a "latest handshake"? If not,
perhaps they're not even communicating at all. For this, you could
look for udp packets on port 21 and see what's up.
Also, you might simplify things a bit by:
- Removing all mentions of Endpoint on the server, since the server
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
Hi Riccardo,
Welcome! Not off-topic at all.
Your config looks fine to my eyes; I don't think you _need_ different ports per
endpoint, but I might be wrong.
With your tcpdump, if you can see incoming ICMP requests you should see
outgoing ones too -- make sure they're not coming in on wg0 and
14 matches
Mail list logo
