Talk:Network configuration

From ArchWiki

Device names

I've updated the section to also introduce users to systemd.link(5). Should we switch the whole section to prefer the systemd mechanism over udev? I'd vote in favor of systemd, since I believe systemd.links will instruct udev and not the other way round. I also find the link files easier to read and understand. We could keep the udev rules as a side note, but I'd rather remove them -1 (talk) 21:38, 8 March 2017 (UTC)

At least a note that udev processes the result of the link files should be kept. I'd also keep udev in Network_configuration#Reverting_to_traditional_device_names because 99-default.link contains more than just the way interface names are set up. Maybe 99-default.link it is not the best idea, it should be possible to override just the NamePolicy. -- Lahwaacz (talk) 21:51, 8 March 2017 (UTC)
Thank you. I'll just quickly read up on how the mechanism works exactly. I shall retain some information on udev as an alternative and remove overlaps. -1 (talk) 22:05, 8 March 2017 (UTC)
I'm sorry to say, but the rabbit hole got too deep and I sadly don't have the time to research this properly. I reverted the changes to the device name section since I don't want to leave the section in this unpolished state. I'd be happy if anyone wants to pick it up again: have a look at this diff. -1 (talk) 13:14, 10 March 2017 (UTC)

dhcpcd static profile expansion

In reference to the flag for expansion mentioning that the dhcpcd static profile is gone - it is now linked with the other network managers in the table. Static IP addresses can be assigned with all of the listed network managers, so I don't think we should list dhcpcd here as a special case. -- Rdeckard (talk) 15:39, 14 April 2017 (UTC)

Indeed, I missed that the table contains something else from the Network manager list. On second thought, maybe dhcpcd should be added there as well. -- Lahwaacz (talk) 20:53, 14 April 2017 (UTC)

Realtek RTL8111/8168B

The chipset version affected are shown as:

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

Upon installation, the network would work sporadically and was not the result of misconfigured DNS. The issue is a hardware issue. The 8169 driver will work, but requires setting the kernel parameter iommu=soft on various AMD FX cpus.

David C. Rankin, J.D.,P.E. -- Rankin Law Firm, PLLC (talk) 22:40, 22 January 2018 (UTC)

See Network_configuration#Gigabyte_Motherboard_with_Realtek_8111.2F8168.2F8411. -- Lahwaacz (talk) 22:50, 22 January 2018 (UTC)
Shall we cleanup these 2 sections and merge them into one? Isn't it observed only on AMD systems, I have this exact revision 06 with an intel based MB and I have not noticed issues. -- Kewl (talk) 12:12, 17 March 2018 (UTC)

Merge DHCP clients, network managers and wireless utilities tables

I propose merging Network configuration#DHCP, Network configuration#Network managers and Wireless network configuration#Utilities in one table. A lot of them depend or use one another and some can not be cleanly categorizes in only one category, e.g. dhcpcd is more than a simple DHCP client and iwd has built-in network configuration. I think that by placing them in one table it would be more easier to evaluate them and express their relationship.

I'll create a draft table in a while.

-- nl6720 (talk) 12:42, 7 October 2019 (UTC)

That table is a lot to take in, more so when half the entries have a large merged cell for wpa_supplicant. -- Alad (talk) 15:13, 7 October 2019 (UTC)
Two out of five also mention iwd :D But, I think, it does illustrate the relationship between the software in a better way than the separate tables.
This table has been on my mind for a while now, but now that I actually created it, it turned out more horrible than I though it would. I have no plans to merge it until the draft is in a usable state.
-- nl6720 (talk) 15:23, 7 October 2019 (UTC)
I'd definitely remove the "Systemd units" column, it is not necessary for users to make a choice - it's just an implementation detail which is described on the relevant wiki page (which users should definitely see before attempting to use it).
Also the "Wired" columns are misleading for wpa_supplicant, because it has a wired driver. Maybe just leave out "Wired" entirely, because green "Ethernet" is just an implication of green "Static" OR "DHCP", and most people don't care about "PPPoE" anyway.
-- Lahwaacz (talk) 16:38, 7 October 2019 (UTC)
Oh, right, it's that IEEE 802.1X thing.
I'm not certain about removing PPPoE, but I'd definitely like to remove WEXT and nl80211.
-- nl6720 (talk) 07:19, 8 October 2019 (UTC)
Yes, I think that WEXT and nl80211 can be removed... -- Lahwaacz (talk) 19:51, 8 October 2019 (UTC)
After following Network management from the Installation guide again, I'll change my mind on this table. Having a single table (similar to the one in Boot loader looks like a quicker path to the respective wiki articles. -- Alad (talk) 18:33, 16 November 2021 (UTC)
I think the table can be simplified a little by removing the second column with package names. It is mostly similar to the first column, and one would go read the relevant article first before blindly installing a package, and that would contain installation instructions. --Cvlc (talk) 13:04, 17 November 2021 (UTC)
I think the column with package names is helpful. You can quickly see if the package is in the official repos vs. AUR, and sometimes there might be other criteria you want to check about a package before installing it like the package size, set of dependencies or license. Especially for such a critical system component like networking, some users might want to include these criteria in their evaluation. Mearon (talk) 13:46, 17 November 2021 (UTC)
I like the idea of removing the "Package" column. The "Software" column can link to the appropriate wiki article, if there is any, or to the package, if there isn't a wiki article for it. Since the packages are listed in the wiki pages of these software, nothing would be lost. -- nl6720 (talk) 07:08, 19 November 2021 (UTC)

Looking at the table now, I'm wondering if there is enough content on the wiki to create the Network configuration/PPPoE and/or Network configuration/PPP subpages... -- Lahwaacz (talk) 07:08, 14 October 2019 (UTC)

Draft

Software Archiso [1] Connection type Wireless authentication IP address, route and DNS management Interface
Ethernet PPPoE Mobile broadband WEP WPA/WPA2 WPA3 Static IP DHCP Domain name resolution CLI TUI GUI
dhclient Yes Yes ? No No Yes Yes Yes (writes /etc/resolv.conf) No No No
dhcpcd Yes Yes ? No launches wpa_supplicant Yes Yes Yes (uses resolvconf or writes /etc/resolv.conf) No No dhcpcd-uiAUR
ConnMan No Yes No Yes (uses ofonoAUR) Yes (uses wpa_supplicant or iwd) Yes Yes Yes (runs a builtin resolver and writes /etc/resolv.conf) connmanctl(1) Yes Yes
netctl No Yes Yes (uses ppp) Yes (uses ppp) Yes (uses wpa_supplicant) No Yes Yes (uses dhcpcd or dhclient) Yes (uses resolvconf) netctl(1) wifi-menu(1) No
NetworkManager No (FS#54934) Yes Yes (uses rp-pppoe) Yes (uses modemmanager) Yes (uses wpa_supplicant or iwd) Yes Yes (uses internal, dhclient or dhcpcd) Yes (uses systemd-resolved, resolvconf or writes /etc/resolv.conf) nmcli(1) nmtui(1) Yes
systemd-networkd Yes Yes No No No Yes Yes Yes (uses systemd-resolved) networkctl(1) No No
wireless_tools Yes No Yes No No No No No
iw Yes No Yes No No iw(8) No No
wpa_supplicant Yes Yes No No No Yes SAE and OWE. FS#65314 No wpa_cli(8) No wpa_supplicant_guiAUR
iwd Yes Yes No No No Yes ? Yes Yes Yes (uses systemd-resolved or resolvconf) iwctl(1) No No

Local hostname resolution as troubleshooting

Network_configuration#Local_hostname_resolution mentions "Some software may however still read /etc/hosts directly (...) To prevent them from potentially breaking, hanging or otherwise delaying operation (...)" which reads as a troubleshooting item. It is however not indicated as such, and may thus be more difficult to find for users, especially when the steps are no longer part of the Installation guide. Related discussion: Talk:Installation guide#Remove /etc/hosts example. -- Alad (talk) 08:40, 23 October 2021 (UTC)

I agree, but I think we should first wait for FS#56684 to be fixed. -- nl6720 (talk) 12:11, 27 October 2021 (UTC)

/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)