On Mon, Dec 16, 2024 at 09:32:56AM -0500, Nikolaos Chatzikonstantinou wrote:
> Hello list,
>
> In src/lib/libc/net/inet_net_pton.c:inet_net_pton_ipv4 on branch
> master, there appears to be an issue of underwriting the buffer. Let
> me explain.
>
> The IPv4 format allows for addresses such as 10/
>Synopsis: Touchpad detected as mouse on Dell Latitude E6440
>Category: compatibility
>Environment:
System : OpenBSD 7.6
Details : OpenBSD 7.6 (GENERIC.MP) #338: Mon Sep 30 08:55:35
MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architec
Hi Stuart, thanks for your prompt response.
> There isn't a notion of "server" and "client" in the protocol, just
> different endpoints.
Agree. I may have used the wrong nomenclature. Wireguard does make a
distinction between the "initiator" and "responder". In this case, I
have used the term cli
On 2024/12/17 20:17, Lloyd wrote:
> I've been running the Wireguard logging patch I submitted to -tech
> for a few days
> with little other issue. Recently I did some testing with a device
> over cellular
> (dynamic client behind CG-NAT). The testing was completed and the
>Synopsis: Inactive Wireguard connections never time out
>Category: Networking
>Environment:
System : OpenBSD 7.6
Details : OpenBSD 7.6-current (CUSTOM) #4: Sat Dec 14 01:13:27 GMT
2024
lloyd@bsdtst01:/sys/arch/amd64/compile/CUSTOM
> If this is the case, I believe this to be a flaw in the Wireguard protocol
> design that
> can lead to a lot of nuisance traffic. The spec makes statements such as the
> following:
>
> | the outer external source IP of an encrypted WireGuard packet is used to
> identify
> | the remote endpoint
> Yes - there are flows attempting to reach the initiator-side network routed
> via wg(4) on the responder. My *expectation* was after the initiator dropped
> off
> the mobile network and became unresponsive, a timer of REKEY_ATTEMPT_TIME
> expired
> after which wg(4) would stop and return an ICM
