Talk:Network configuration

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)

The above update was recently tackled. This included updating above mentioned Network configuration#Revert to traditional interface names section with Special:diff/773246, Special:diff/773251. Thanks, closing. --Indigo (talk) 22:44, 23 March 2023 (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)

+1, added with Special:diff/774270. Closing. --Indigo (talk) 08:51, 31 March 2023 (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)

The suggestion was superceded with Special:diff/585874. There are more RTL8111 subsections, starting with Network configuration/Ethernet#Realtek no link / WOL problem. You're of course welcome to see if it makes sense to condense the issues further, it's kinda tricky with this award winning chipset :) closing. --Indigo (talk) 10:24, 31 March 2023 (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
Software	Archiso [1]	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-ui^AUR
ConnMan	No	Yes	No	Yes (uses ofono^AUR)	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_gui^AUR
iwd	Yes	Yes	No	No	No	Yes	?	Yes	Yes	Yes (uses systemd-resolved or resolvconf)	iwctl(1)	No	No

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

myhostname → yourhostname

To address the style template in Network configuration#Set the hostname, I propose replacing myhostname with yourhostname. Unlike "myhostname", it shouldn't cause any confusion with nss-myhostname(8). -- nl6720 (talk) 09:13, 19 October 2022 (UTC)

+1. --Fengchao (talk) 03:54, 17 December 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)