User talk:nl6720

"RouteTable=1000" is not ideal.

Let me explain why "RouteTable=1000" is not ideal. Firstly, "RouteTable=1000" doesn't align with the WireGuard documentation (see https://www.wireguard.com/netns/). The WireGuard documentation tells us that we should add the default route on the alternative routing table (table 1000). "RouteTable=1000" does something different. "RouteTable=1000" will add every entry in AllowedIPs as a static route to table 1000. If AllowedIPs is a long list, then routing table 1000 will be a long list too. This is totally unnecessary because the wg0 interface already handles the AllowedIPs by itself, and it doesn't need systemd-networkd to add all these static routes. The only purpose of table 1000 is to hand every package over to the wg0 interface.

In my edit I removed "RouteTable=1000", so systemd-networkd will never clutter table 1000 with all those unnecessary entries. I added a [Route] section to actually add the default route to table 1000. In this case, table 1000 will always only contain the default route, as it should. Barrelrider (talk) 13:51, 24 August 2025 (UTC)

WireGuard#systemd-networkd: routing all traffic over WireGuard uses RouteTable=1000 in the [WireGuardPeer] section of a peer that has only AllowedIPs=0.0.0.0/0. No other routes will be created in this case. The advantage of RouteTable= is that you don't have to hardcode any routes in .network files. -- nl6720 (talk) 05:55, 25 August 2025 (UTC)

The only route you have to hardcode in the .network file is the default route. While the example only specifies AllowedIPs=0.0.0.0/0, individuals may desire a configuration that varies from the one presented. As a result, they will modify the AllowedIPs, leading to additional routes in table 1000. This also signifies that the behavior will not be the same. If RouteTable is set to 1000, any package not included in the AllowedIPs list will be directed to the main routing table. As a result, the package is transmitted outside the VPN tunnel. In my setup using [Route], the package will be dropped if it isn't included in AllowedIPs. Barrelrider (talk) 23:46, 25 August 2025 (UTC)

The section is called "routing all traffic over WireGuard", so it makes no sense to omit 0.0.0.0/0 from AllowedIPs within the [WireGuardPeer] section of the peer you want to direct all traffic to. -- nl6720 (talk) 10:03, 26 August 2025 (UTC)

Edit reversion on Downgrading packages

Hi there,

You reverted my edit here ( https://wiki.archlinux.org/index.php?title=Downgrading_packages&diff=882958&oldid=882954 ) because you said the file:// scheme handler works just fine. But I cannot make it work on my case.

With pacman -U it was giving file not found error (even though it exists), and it worked fine without it. I also tested the same pattern with cat and it also gives me errors.

In my case, I tested using Bash and Konsole from KDE.

I also found this, which may be relevant: https://invent.kde.org/utilities/konsole/-/commit/9bc892eff0dd3a19346182650b8b6d5ef0436aee

Can you please tell me how you got file:// to work in a terminal? I am unable to make it work.

Thanks. TheSleuth (talk) 00:56, 13 August 2026 (UTC)

It works for me™ in zsh in yakuake.

# pacman -U file:///var/cache/pacman/pkg/base-3-3-any.pkg.tar.zst

# cd /var/cache/pacman/pkg && pacman -U file://base-3-3-any.pkg.tar.zst

Try single-quoting the whole URI.

-- nl6720 (talk) 09:14, 13 August 2026 (UTC)

It still does not work for me™. See https://paste.coalserver.de/?e6418a1b17554448#63SqXupquauuaA7jzNporANc45FP9bc2VmMBCmGdYusN . I think it's better to revert your reversion™, since I think it is safe to assume Bash is the most used one[1]. (Not sure if this happens on gnome-terminal, xfce-terminal etc. but I would guess it does since what matters is the shell). TheSleuth (talk) 09:37, 13 August 2026 (UTC)

It works for me™ in Bash in gnome-terminal — andreymal (talk) 09:41, 13 August 2026 (UTC)

It obviously won't work with cat. file:// is supported by pacman (or, IIRC, libcurl specifically) not the shell.

Those failures are from files in ~/Downloads. Could it be because the alpm user used by pacman does not have access there?

-- nl6720 (talk) 09:43, 13 August 2026 (UTC)

Weird, it was not working again, but now started to work (?). Also, pacman needs root to execute, so is the alpm user even relevant considering sudo would have all access? It started working after I executed a single command with --disable-sandbox-filesystem, then it worked for everything else after it, even in commands without such flag (/etc/pacman.conf was not touched, though). Well, I guess we can leave it as-is, but I don't see a need to specify file:// either way. TheSleuth (talk) 09:56, 13 August 2026 (UTC)

The reason to prefer it is because, unless I'm mistaken, pacman -U file://... verifies the package signature, while pacman -U ... doesn't. -- nl6720 (talk) 10:01, 13 August 2026 (UTC)