pacman failure "404", duid (dhcpcd)

There's a mix of ipv4, 6, and duid stuff in here. On a home network -- our home LAN -- why would we ever need NSA level DUID (DHCP Unique IDentifier) fingerprinting of our system? If it's configured, but there's some conflict, our dhcpcd will time out, or make a connection but fail to browse (no DNS), and so on. This is just another level of possible failure on a home system; why would we ever want duid in a million years? DUID settings are further down, but they seem to be set no matter what a person does to remove.

pacman

One time, I began receiving 404 failures during # pacman -Syu. I quickly dug deeper using # pacman -Syu --debug 2>&1 |tee debugfile.txt and found that either curl itself (used by pacman to retrieve packages), or the way in which pacman was using curl, was the source. This is not always a bed of roses to determine and repair since they are often random glitches in what's become a decades-long, intermittent, annoying ipv6/ipv4 transition mess. This can involve tens of kernel and application settings and confusing conf files that often interact badly. For example, no longer can one edit /etc/resolv.conf directly, since it will be overwritten by resolvconf during dhcpcd initialization. One must now edit /etc/resolvconf.conf to indirectly get at /etc/resolv.conf, and resolvconf.conf has its own syntax, different from resolv.conf, so that both file syntaxes must be verified following any change. And so on.

which ipv is working?

The most obvious start is to verify both ipv4 and ipv6 curl function. Then, one can disable or activate the failed half or, possibly... force pacman to use the ip version that *is* working, (although I'm not sure if ipv type can be specified during a pacman operation).

First, the curl ipv functionality. Take a URL from one's mirror list and ping it to see that DNS is working. Then...

# curl aprs.ele.etsmtl.ca
Bienvenue | Welcome [curl works]
# curl --ipv4 aprs.ele.etsmtl.ca
Bienvenue | Welcome
[curl, and therefor pacman, is working ipv4]
# curl --ipv6 aprs.ele.etsmtl.ca
curl: (6) Could not resolve host: aprs.ele.etsmtl.ca
[curl, and therefore pacman, is failing ipv6]

In this case, it appears pacman is requesting both an ipv6 (AAAA) and ipv4 (A) handshake via curl, but, at various points in its development, pacman could only accomplish ipv4. Strace shows futher that IPV6 is not even able to open a socket.

Another way to check the kernel network stuff is to do a # sysctl -A, which will reveal all the kernel settings, but then grep it for, "net", "ipv4", or "ipv6" settings.

Users could also run # ip addr list and look to see there's an ipv6, and ipv4, or both.

~/.curlrc

As part of the curl man page, we can see some settings for the configuration file.

In the case above, I was getting proper ipv6 configuration, but still getting a curl fail on ipv6. It turns out that I was only able to find a single post on this, here. The post indicates that it's really a glibc issue, that could only be resolved by slowing down DNS resolution via manipulations inside /etc/resolvconf.conf to manipulate /etc/resolv.conf. We want /etc/resolv.conf to say "options single-request"
and so, to achieve this, we write...

# nano /etc/resolvconf.conf
# Solve ipv4/v6 fails
resolv_conf_options="single-request"

For a list of all resolvconf.conf options, see this man page.
Disabling IPV6 in Arch is no bed of roses -- one has either to put a boot line into their GRUB, or to create an effective /etc/sysctl.d/40-ipv6.conf (see bottom). Further, we may instead need to enable ipv6 more thoroughly across all applications, not further cripple it. It's a typical ipv4/ipv6 trial and error mess due to opaque reliance upon multiple programs (eg. curl)

old fix

This one used to work, but nowadays with built-in ipv6, doesn't always work. Add a couple lines in your blacklist file, eg...

# nano /etc/modprobe.d/blacklist
# stop pacman failure when encounter ipv6 sites
blacklist nf_conntrack_ipv6
blacklist nf_defrag_ipv6

grub

Use nano or whatever to add

/etc/sysctl.d/40-ipv6.conf

Here's one example, not guaranteed to work.

# Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.wlan0.disable_ipv6 = 1

duid

I've removed all duid references but I still get some duid when I connect with dhcpcd. Be sure too to delete all old "leases" in /var/lib/dhcpcd. Note also that they put a duplicate version of dhcpcd.conf inside /var/lib/dhdpcd/etc/, and that this is the one used by the system. You could probably even delete /etc/dhcpcd.So "duid" needs to be commented out at that location.

# rm /etc/dhcpcd.duid
# rm /etc/dhdpcd.secret
# rm /var/lib/dhdpcd/duid
# nano /etc/dhdpcd.conf [comment duid and clientid lines]

So then, here's a truncated version of etc/dhcpcd.conf. But even with al duid disabled, the router is apparently coaxed into collecting one.

# nano /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Inform the DHCP server of our hostname for DDNS.
hostname

# duid

# Persist interface configuration when dhcpcd exits.
persistent

option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search
option classless_static_routes

# Get the hostname
option host_name

# Most distributions have NTP support.
option ntp_servers

# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Prevent timeouts for ipv6 failures
noipv6
noipv6rs