From: Stephan von Krawczynski <skraw.ml@ithnet.com>
To: "Daniel Gröber" <dxld@darkboxed.org>
Cc: Nico Schottelius <nico.schottelius@ungleich.ch>,
WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Wireguard uses incorrect interface - routing issue
Date: Fri, 21 Jun 2024 15:54:39 +0200 [thread overview]
Message-ID: <20240621155439.6cb5abb9@ithnet.com> (raw)
In-Reply-To: <20240621122926.2xzt7ulno5oczqcv@House.clients.dxld.at>
On Fri, 21 Jun 2024 14:29:26 +0200
Daniel Gröber <dxld@darkboxed.org> wrote:
> On Fri, Jun 21, 2024 at 01:24:47PM +0200, Nico Schottelius wrote:
> >
> > p.s.: the route lookup looks correct on the machine, when selecting the
> > source IP:
> >
> > [11:15] server141.place10:~# ip r get 194.187.90.23
> > 194.187.90.23 via inet6 fe80::3eec:efff:fecb:d81a dev eth0 src
> > 192.168.1.149 uid 0 cache
> > [11:16] server141.place10:~# ip r get 194.187.90.23 from 192.168.1.149
> > 194.187.90.23 from 192.168.1.149 via 192.168.1.254 dev eth1 table 42 uid 0
> > cache
> >
> > wireguard still uses the wrong interface:
> >
> > 11:20:13.115154 eth0 Out IP 192.168.1.149.60031 > 194.187.90.23.4000:
> > UDP, length 148
>
> I haven't looked at the details yet but this smells like the same route
> caching issue I found a while ago:
> https://lists.zx2c4.com/pipermail/wireguard/2023-July/008111.html
>
> Does up/down'ing the interface make the problem go away? IIRC that will
> re-initialize the udp socket and thus clear the route chache.
>
> FYI Nico: It may be time to escalate these bugs to the network subsystem
> maintainers on netdev@vger.kernel.org since Jason is not reading this list
> anymore AFAICT.
>
> get_maintainer.pl spits out this list of emails to send To:
>
> Jason A. Donenfeld" <Jason@zx2c4.com>,
> "David S. Miller" <davem@davemloft.net>,
> Eric Dumazet <edumazet@google.com>,
> Jakub Kicinski <kuba@kernel.org>,
> Paolo Abeni <pabeni@redhat.com>,
> wireguard@lists.zx2c4.com,
> netdev@vger.kernel.org,
> linux-kernel@vger.kernel.org
>
> Do add me to CC as well. Before sending I'd recommend working out an
> ip-netns based reproducer script -- makes it harder to ignore the report as
> "ugh, too much work" ;)
>
> Let me know if you need help with that,
> --Daniel
... and in case you do find someone interested at all there is still the
problem of no signaling to anyone when a client connects.
I hardly can remember the decade when all this was implemented in cipe.
--
Regards,
Stephan
next prev parent reply other threads:[~2024-11-18 14:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 11:13 Wireguard uses incorrect interface - routing issue Nico Schottelius
2024-06-21 11:24 ` Nico Schottelius
2024-06-21 12:29 ` Daniel Gröber
2024-06-21 13:54 ` Stephan von Krawczynski [this message]
2024-06-22 9:22 ` Nico Schottelius
2024-06-21 14:42 ` Diyaa Alkanakre
2024-06-21 15:18 ` Daniel Gröber
2024-06-21 15:38 ` Nico Schottelius
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240621155439.6cb5abb9@ithnet.com \
--to=skraw.ml@ithnet.com \
--cc=dxld@darkboxed.org \
--cc=nico.schottelius@ungleich.ch \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox