Talk:Network configuration

/etc/hosts: dual ip4/ip6 localhost prevents ip4 from working

Moved from Talk:Installation guide. -- Alad (talk) 09:19, 31 October 2021 (UTC)

I recently set up a new system with /etc/hosts copied from the guide:

127.0.0.1	localhost
::1		localhost
127.0.1.1	myhostname.localdomain	myhostname

I found localhost did not resolve to 127.0.0.1 which caused some docker comms to fail etc.

Removing or renaming the ip6 binding allowed ip4 localhost to work again, so perhaps the following should be used in the guide instead:

127.0.0.1	localhost
::1		ip6-localhost
127.0.1.1	myhostname.localdomain	myhostname

—This unsigned comment is by Alexheretic (talk) 09:18, 19 February 2021‎. Please sign your posts with ~~~~!

How did you check what localhost resolves or doesn't resolve to? Did you just `ping` it?

Glibc's getaddrinfo() as well as the old gethostbyname() have supported multiple hosts entries for the sane hostname for as long as I remember (certainly as far back as 2011) – if you ask it for AF_UNSPEC you get both addresses, if you ask it for AF_INET you get just the IPv4 address, and so on. Indeed programs kind of *have to* expect this, as hostnames with multiple addresses occur daily in DNS, which is accessed through the same APIs.

Perhaps the problem is that Docker only binds to the IPv4 "localhost", but you only attempt to connect to the IPv6 "localhost". In that case it's slightly more of a fault with the client app, as it certainly should try connecting to all found addresses. (Well, it's a problem with both, but usually the client side is easier to make dual-stack than the server side.)

(Sometimes that problem shows up because of the magic "::" behavior – when programs bind to the IPv6 "any" address, on Linux this creates a magic socket that accepts both IPv6 *and* IPv4 connections on the same socket. Sometimes this leads to developers being slightly lazy and structuring the server to only use one listener socket at a time... but they forget this only works with "::", whereas binding to any *specific* address – even localhost – would need two sockets again, one for AF_INET and one for AF_INET6. That's how you end up with services that are "IPv4-only" in 2021.)

But again, I would start with testing the "localhost did not resolve to..." claim. If you see that it resolves to ::1, this doesn't immediately imply it does not resolve to 127.0.0.1 – it can in fact resolve to both, and with your /etc/hosts it *should* resolve to both. Test with getent ahosts localhost or something like python's socket.getaddrinfo().

grawity (talk) 11:07, 8 November 2021 (UTC)

I think that the correct format is:

::1    localhost ip6-localhost ip6-loopback

see: https://manpages.debian.org/bullseye/manpages/hosts.5.en.html

brainfucksec (talk) 08:35, 8 November 2021 (UTC)

This doesn't actually change anything related to OP's situation, does it? You still have the "::1 localhost" entry that OP says is causing the problem. —This unsigned comment is by Grawity (talk) 11:07, 8 November 2021 (UTC). Please sign your posts with ~~~~!

Name resolution info seems to be missing

Currently to get DNS lookups to work after installing Archlinux, I just start the systemd-resolved systemd service. This, however, doesn't seem to be fully compatible with using CUPS for printing, see CUPS and Avahi.

Network configuration does link to Domain name resolution, but then the latter page is just as unhelpful.

The Web isn't very usable without being able to do DNS resolution, so the Wiki should document a way to set this up. It should be clear what packages one needs to install, enable and configure for Internet name resolution to work. In particular, there should be a path defined for users of CUPS (because CUPS seems to be *the* Archlinux printing solution).

I'd help, but I still haven't figured this out. Neven (talk) 15:04, 5 June 2022 (UTC)

MTU setting for wired NICs

The current example in device MTU and queue length is for wireless devices.

While that is relatively clear, it is not so obvious how to write the settings for wired NICs.

More specifically, I tested that this rule triggers before the device is renamed according to the predicable naming conventions. Thus, KERNEL=="en*" does not work. In contrast, KERNEL=="eth*" does.

I made a minor update to give a hint for people looking to configure MTU on wired cards.

Ezacaria (talk) 09:35, 5 February 2023 (UTC)

I've changed the recommend way to modify link properties to systemd.link, which allows you to simply use Type=ether :) YHNdnzj (talk) 04:32, 4 May 2023 (UTC)