Announcing netctl

jouke · 2013-02-07 21:39:32

The trusted networking CLI of Arch Linux, netcfg, has undergone a major facelift in order to be a better partner for systemd. Meet: netctl.

Here is what you need to know to upgrade to the future of command-line based network management.

The netctl package (now in [testing]) supplies three man pages:
- netctl
- netctl.profile
- netctl.special
Especially the second one deserves your careful reading.
The directory for your profiles is /etc/netctl/ (no longer /etc/network.d/)

In order to migrate from netcfg, at least the following is needed:

Move your profile files to the new directory.
Rename your variables according to netctl.profile(5) (most have only become CamelCase).
Unquote your interface variable and other variables that don't strictly need quoting (this is mainly a style thing).
Run netctl enable <profile> for every profile in the old NETWORKS array. 'last' doesn't work this way, see netcfg.special(7).
Use netctl list / netctl start <profile> instead of netcfg-menu. wifi-menu remains available.

the sad clown · 2013-02-08 03:17:50

Thanks for the new network manager. I started using it a couple of days ago and have had no problems with it.

firecat53 · 2013-02-08 03:55:45

So will this automatically connect to an enabled network if I suspend in one network and then resume in another? I always thought netcfg-auto-wireless was supposed to do this, but I couldn't ever get it to work.

Thanks!
Scott

fijit · 2013-02-08 11:29:27

Hi,
Works nicely for me, but I had a couple of questions after a quick test:
1) Is there a quick way to see which profile netctl-auto is connected to? I expected it to be highlighted in "netctl list" but it is not.
2) With netcfg it was possible to list PostUp/PreDown commands in the interface/<interface> file, to e.g. start services when connecting to the network. It seems that netctl does not execute these commands. Is there a way to get the same behaviour without including PostUp/PreDown in every profile file?

Leonid.I · 2013-02-08 15:16:43

Thanks for your work.

jouke wrote:

[*]The directory for your profiles is /etc/netctl/ (no longer /etc/network.d/)[/*]

This has been a long-standing point of confusion for me. /etc is for _configs_ only -- can we consider profiles as such? For instance, suppose one has read-only / and wants to write a simple profile for a hotel wifi, only for 2 days. This requires remounting / rw... A dirty workaround which I have is a (broken) symlink link

$ ll /etc/network.d/roaming-wifi 
lrwxrwxrwx 1 root root 19 Feb 21  2012 /etc/network.d/roaming-wifi -> /var/tmp/hotel-wifi

Once we go about moving dirs, is it possible to relocate profiles completely to /var/lib/netctl? This is what wicd is doing, it agrees with FHS (IMHO), and allows a completely stateless /etc. Is this against design goals (as in would you accept patches)?

graysky · 2013-02-08 23:18:17

https://wiki.archlinux.org/index.php/Netctl

Plz contribute. Remember to write the article in the third person.

BTW: I have netctl on many boxes and working flawlessly (all static config).

Last edited by graysky (2013-02-08 23:18:43)

xcabal · 2013-02-11 06:13:13

just saw this and decide to give it a try. i got everything to work with my home network. i just have question regarding one of the options. in man page for netctl.special, the option netctl-auto@<interface>.service, I'm not sure i understand this option completely, I understand this is aimed for wireless.
to give a real world example, in my case i have network A at home and network B at school and network C at work each has their own profile and they all use wireless. if i set this to my wireless interface, go to work and turn on my laptop and it finds C when I'm at work will it know to go to straight to C's profile or will it run through A,B profiles before achieving a connection with C?

Thanks

Awebb · 2013-02-11 07:53:42

Oh, this makes me check again, why I use wifi-select instead of wifi-menu. I hope the maintainer catches up fast enough.

cinelli · 2013-02-19 12:58:07

After reading the documentation three times and seeing how netctl takes control of handling wpa_supplicant and dhcpcd and then having a look at the example configuration and removing netcfg for netctl. There was a few things I noticed with the PKGBUILD ... optdepends of wpa_actiond should be moved to depends it is listed for being used only for automatic wireless connection.

╰─╼ wpa_actiond --help
When wpa_actiond is passed 4 parameters:
    1) The interface name 
    2) The SSID of the network
    3) The id_str parameter of the wpa_supplicant network section
    4) One of the strings CONNECT, LOST, REESTABLISHED and DISCONNECT

Seeing how all of these are to be defined in the /etc/netctl/<profile> , netctl should build a mock wpa_supplicant.conf [and since it defaults /etc/wpa_supplicant.conf it doesn't have to be defined in the profile] to run against the profile the user has configured. Without wpa_supplicant.conf existing and running netctl-auto <interface> or netctl start <profile> wpa_actiond is called upon but isn't found (since it wasn't installed due to opt depends listing it only for auto wireless profiles) and you're left without an interenet connection (obviously you could manually dhcpcd your wired connection or run wpa_supplicant if it's installed and configured but that's not the point).

Also running netctl start <profile> as a normal user errors come up that /etc/wpa_supplicant.conf could not be found, and also that netctl could not write the configuration file for wpa_supplicant (confirming that it writes to wpa_supplicant.conf, I believe this is explained in the documentation as well).. Among other errors like obvious permission problems.

Moving right along, I'm going to assume now that when wpa_actiond sees that the connection is wired it will continue according to the parameters it's passed from netcfg via the selected profile. Finally having netctl perform

dhcpcd -qL -t 10 <interface>

and then stopping the service unit after a successful connection (as described in the man page.)

I tested this on my desktop x86_64 build both wired and wireless and then again on my i686 laptop wired & wireless.

The only thing that has to be made sure of is that the device being called upon is "up" at the time netctl is trying to connect to the specified network. This is done simply by enabling the profile and disabling the service unit as documented in the manual.

╰─╼ man 7 netctl.special
      .....
           netctl enable <profile>
           systemctl disable netctl@<profile>
      .....

With wpa_actiond is moved to the depends then wpa_supplicant can be removed from the optdepends array as well since it will be pulled in by wpa_actiond.

Last edited by cinelli (2013-02-19 12:59:24)

labp · 2013-03-02 03:27:35

Some impressions:

With netcfg connecting the first time with wlan0 got an error, netctl works perfectly

Connecting after suspend also didn't work with netcfg and works with netctl.

When using netctl-auto<interface>, netctl list does not display * for the profile connected at boot.

cinelli · 2013-03-02 04:52:19

labp wrote:

When using netctl-auto<interface>, netctl list does not display * for the profile connected at boot.

After the system has booted and a user is using netctl-auto@<interface>.service to connect. They could check the following to see which profile was used to connect.

$ cat /run/network/wpa_supplicant_<interface>.conf (as root)
# cat /run/network/wpa_actiond_wpa_actiond_<interface>.profile (as user)

wpa_actiond_<interface>.profile will return the profile name currently being used.
wpa_supplicant_<interface>.conf will return the wpa_supplicant configuration of the current profile in use.

labp · 2013-03-02 23:21:20

Thank you!

cinelli wrote:

labp wrote:
When using netctl-auto<interface>, netctl list does not display * for the profile connected at boot.
After the system has booted and a user is using netctl-auto@<interface>.service to connect. They could check the following to see which profile was used to connect.
$ cat /run/network/wpa_supplicant_<interface>.conf (as root)
# cat /run/network/wpa_actiond_wpa_actiond_<interface>.profile (as user)
wpa_actiond_<interface>.profile will return the profile name currently being used.
wpa_supplicant_<interface>.conf will return the wpa_supplicant configuration of the current profile in use.

srf21c · 2013-03-12 05:02:25

Is IPv6 via dhcp supported yet? I'm having difficulty getting a netctl configured interface to pull an IPv6 address. Here is the profile for the interface.

/etc/network.d/lan0-profile:

CONNECTION='ethernet'
DESCRIPTION='Private Interface'
INTERFACE=enp3s6
IP6=dhcp
IP=dhcp

The following error is showing up in journalctl

Mar 11 21:54:47 arch dhcpcd[308]: enp3s6: sending IPv6 Router Solicitation
Mar 11 21:54:47 arch dhcpcd[308]: enp3s6: sendmsg: Cannot assign requested address

All other IPv6 clients on the lan are being assigned IPv6 addresses from the same DHCPv6 server without incident.

Last edited by srf21c (2013-03-12 08:44:48)

cinelli · 2013-03-12 05:43:00

srf21c wrote:

Is IPv6 via dhcp supported yet? I'm having difficulty getting a netctl configured interface to pull an IPv6 address. Here is the profile for the interface.
/etc/network.d/lan0-profile:
CONNECTION='ethernet'
DESCRIPTION='Private Interface'
INTERFACE=enp3s6
IP6=dhcp
IP=dhcp
The following error is showing up in journalctl
Mar 11 21:54:47 arch dhcpcd[308]: enp3s6: sending IPv6 Router Solicitation
Mar 11 21:54:47 arch dhcpcd[308]: enp3s6: sendmsg: Cannot assign requested address
All other IPv6 clients on the lan are being assigned IPv6 addresse from the same DHCPv6 server without incident.

What happens if you disable the IPv4 dhcp and run it?

srf21c · 2013-03-12 06:04:23

Don't know, I'm reluctant to risk disabling IPv4 because if I lose connectivity I have to pull the server down from the rack again and connect it to a console = PITA.

Undesirable, but doable. Any other troubleshooting suggestions to try first?

ngoonee · 2013-03-12 06:50:24

Sporadically (worst kind of 'bug', I know) stopping a network won't clear the routing information. Resulting in the next network connection I establish being unusable until I manually delete the default from the earlier network.

Sorry, not knowing much about networking beyond the 7 layers I don't really know where to start with this.

Malstrond · 2013-03-13 15:58:59

srf21c wrote:

Mar 11 21:54:47 arch dhcpcd[308]: enp3s6: sending IPv6 Router Solicitation

dhcpcd only started supporting DHCPv6 with version 5.99.2 [1].
But that version is still marked as experimental, Arch is currently using 5.6.7, and the new version isn't in testing either.
So unless you built it manually, you are running a version which does not support DHCPv6.

dhcpcd 5.6.7 only supports stateless address autoconfiguration (SLAAC). "IPv6 Router Solicitation" means it is querying for routers that advertise a prefix so autoconfiguration is triggered. It has nothing to do with DHCPv6 and no DHCPv6 requests are made at all.

The only DHCPv6 client that is currently in any official Arch repo and supported by netcfg and netctl is dhclient.
You should check if it is running and if it outputs something.

Last edited by Malstrond (2013-03-13 21:14:42)

progandy · 2013-03-13 16:41:41

dhcpcd has begun implementing IPv6 support since version 5.6.1. The most recent v.5.6.7 should have full support.
http://roy.marples.name/projects/dhcpcd/log/
5.99 is some sort of alpha build for IPv6 between 5.5 and 5.6 I think.
Edit: Sorry. I mixed up IPv6 and DHCPv6. IPv6 is being integrated in dhcpcd, but DHCPv6 is only in the older testbuild and not yet ported to the main source.

Last edited by progandy (2013-03-13 16:52:58)

srf21c · 2013-03-13 21:33:21

Malstrond wrote:

The only DHCPv6 client that is currently in any official Arch repo and supported by netcfg and netctl is dhclient.
You should check if it is running and if it outputs something.

Thanks, I installed dhclient. As per the netctl.profile man page, I added a DHCPClient=dhclient line after the IP6=dhcp entry in /etc/network.d/lan0-profile.

CONNECTION='ethernet'
DESCRIPTION='Private Interface'
INTERFACE=enp3s6
IP=dhcp
IP6=dhcp
DHCPClient=dhclient

Rebooted, but the lan interface failed to grab an IPv6 dhcp lease. It appears that dhcpcd is still being called by netctl, there is no mention of dhclient in systemd journal.

Mar 13 14:33:24 arch dhcpcd[287]: version 5.6.7 starting
Mar 13 14:33:24 arch dhcpcd[287]: enp3s8: sending IPv6 Router Solicitation
Mar 13 14:33:24 arch dhcpcd[287]: enp3s8: sendmsg: Cannot assign requested address
Mar 13 14:33:24 arch dhcpcd[287]: enp3s8: broadcasting for a lease
Mar 13 14:33:24 arch dhcpcd[287]: enp3s8: offered xxx.xxx.xxx.80 from xxx.xxx.xxx.1
Mar 13 14:33:24 arch dhcpcd[287]: enp3s8: acknowledged xxx.xxx.xxx.80 from xxx.xxx.xxx.1
Mar 13 14:33:25 arch dhcpcd[357]: version 5.6.7 starting
Mar 13 14:33:25 arch dhcpcd[287]: enp3s8: checking for xxx.xxx.xxx.80
Mar 13 14:33:25 arch dhcpcd[357]: enp3s6: sending IPv6 Router Solicitation
Mar 13 14:33:25 arch dhcpcd[357]: enp3s6: sendmsg: Cannot assign requested address
Mar 13 14:33:25 arch dhcpcd[357]: enp3s6: broadcasting for a lease
Mar 13 14:33:25 arch dhcpcd[357]: enp3s6: offered 192.168.1.2 from 192.168.1.254
Mar 13 14:33:25 arch dhcpcd[357]: enp3s6: acknowledged 192.168.1.2 from 192.168.1.254
Mar 13 14:33:25 arch dhcpcd[357]: enp3s6: checking for 192.168.1.2
Mar 13 14:33:26 arch dhcpcd[287]: RA for unexpected interface from fe80::20d:b9ff:fe13:1b4
Mar 13 14:33:26 arch dhcpcd[357]: enp3s6: Router Advertisement from fe80::20d:b9ff:fe13:1b4
Mar 13 14:33:26 arch dhcpcd[357]: forked to background, child pid 449
Mar 13 14:33:26 arch dhcpcd[449]: enp3s6: no support for DHCPv6 management
Mar 13 14:33:26 arch network[223]: Started network profile 'lan0-profile'
Mar 13 14:33:26 arch systemd[1]: Started A basic dhcp ethernet connection.
Mar 13 14:33:28 arch dhcpcd[287]: enp3s8: sending IPv6 Router Solicitation
Mar 13 14:33:29 arch dhcpcd[449]: enp3s6: leased 192.168.1.2 for 7200 seconds
Mar 13 14:33:30 arch dhcpcd[287]: enp3s8: leased xxx.xxx.xxx.80 for 3600 seconds
Mar 13 14:33:30 arch dhcpcd[287]: forked to background, child pid 519
Mar 13 14:33:30 arch network[224]: Started network profile 'wan0-profile'
Mar 13 14:33:30 arch systemd[1]: Started A basic dhcp ethernet connection.
Mar 13 14:33:30 arch systemd[1]: Starting Network.

Last edited by srf21c (2013-03-13 21:57:01)

moscar · 2013-03-22 15:37:57

I'm using netctl-git from aur and I can't get the autocompletion to work with zsh (it should be the same zsh completion as netctl in testing).

The file is correctly installed to

/usr/share/zsh/site-functions/_netctl

However it doesn't work for me. Has anyone experienced this, or could it be my zsh config causing problems?

Bash completion works great.

cdx8664 · 2013-03-23 07:46:36

I couldn't find anything about netctl with upstream systemd, such as at freedesktop.org. Is it specific to Arch?

Will netcfg be removed from [core] in favor of netctl? Or is it just an additional option, like wicd?

elkoraco · 2013-03-23 09:11:34

cdx8664 wrote:

I couldn't find anything about netctl with upstream systemd, such as at freedesktop.org. Is it specific to Arch?

Arch specific, yes. I suppose in time it will move to the main repo, then we will have a dual life for a while, then at some point in the future the developers will stop maintaining netcfg, then a bunch of users will come to the forum saying "Man, I thought Arch was supposed to be KISS, what's this netctl", then everybody will forget about netcfg.

Awebb · 2013-03-23 23:58:50

As I understand the situation, netctl is netcfg, renamed to indicate a better systemd compatibility, as systemd is now the Arch standard.

WonderWoofy · 2013-03-24 01:46:06

Awebb wrote:

As I understand the situation, netctl is netcfg, renamed to indicate a better systemd compatibility, as systemd is now the Arch standard.

This is not really true. Netctl is a near complete rewrite. I guess it started as a fork, but most of it had to be changed. It certainly integrates better with systemd and systemctl. For instance, doing "netctl enable <SSID>" is actually the equivalent of calling "systemctl enable netctl@<SSID>".

So I guess what it achieves is nearly the same thing, but the way it implements it is pretty different. Though you still have wifi-menu and whatnot, net-auto-wireless has been replaced with netctl-auto@.service and net-auto-wireless has been replaced with netctl-ifplugd@.service. It is much much more than a simple renaming.

ewaller · 2013-03-25 03:10:29

Ever since I moved to Arch from Gentoo, I have used wicd as my primary means of managing my networks. I briefly used NetworkManger.

Now, I've decided to embrace netctl having never used netcfg. Right out of the gate, I've a working system, but.......

I have read the netctl wiki. I understand it is a work in process.
I have read the man pages for netctl and netctl.profile.
I have reviewed the wiki for netcfg

So far, I have created and enabled profiles for my home wireless wpa2 network, for my Android wireless tether, and for my wired NIC.

Given that, I would expect that the system would connect to whichever wireless network happened to be available. If I were to connect an Ethernet cable to my system, I would assume that my system would connect via that interface.

Then, I boot my system sitting in my living room. My phone is not in tether mode, and I do not have an Ethernet cable attached to my laptop.
All three profiles fail according to systemctl. The Android link fails because the network cannot be found (as expected). The profile for my home network unexpectantly fails because wpa_suppliicant is already running. The Wired network fails, as expected; but, at this point, if I attached a network cable, I would expect ifplugd to notice and bring the link up; but the service already failed, so that does not happen.

At this point, I can bring the wireless network for my home up with some manual intervention. If I put my system to sleep, and wake it up, the wireless reconnects. If I hit the wifi button on my laptop (causes a softblock) and then reenable it by pressing it again, the wireless link does not reestablish unless I use netctl to restart the profile.

So -- Is this all expected, am I missing something, or should I be filing bug reports?

Arch Linux

#1 2013-02-07 21:39:32

Announcing netctl

#2 2013-02-08 03:17:50

Re: Announcing netctl

#3 2013-02-08 03:55:45

Re: Announcing netctl

#4 2013-02-08 11:29:27

Re: Announcing netctl

#5 2013-02-08 15:16:43

Re: Announcing netctl

#6 2013-02-08 23:18:17

Re: Announcing netctl

#7 2013-02-11 06:13:13

Re: Announcing netctl

#8 2013-02-11 07:53:42

Re: Announcing netctl

#9 2013-02-19 12:58:07

Re: Announcing netctl

#10 2013-03-02 03:27:35

Re: Announcing netctl

#11 2013-03-02 04:52:19

Re: Announcing netctl

#12 2013-03-02 23:21:20

Re: Announcing netctl

#13 2013-03-12 05:02:25

Re: Announcing netctl

#14 2013-03-12 05:43:00

Re: Announcing netctl

#15 2013-03-12 06:04:23

Re: Announcing netctl

#16 2013-03-12 06:50:24

Re: Announcing netctl

#17 2013-03-13 15:58:59

Re: Announcing netctl

#18 2013-03-13 16:41:41

Re: Announcing netctl

#19 2013-03-13 21:33:21

Re: Announcing netctl

#20 2013-03-22 15:37:57

Re: Announcing netctl

#21 2013-03-23 07:46:36

Re: Announcing netctl

#22 2013-03-23 09:11:34

Re: Announcing netctl

#23 2013-03-23 23:58:50

Re: Announcing netctl

#24 2013-03-24 01:46:06

Re: Announcing netctl

#25 2013-03-25 03:10:29

Re: Announcing netctl

Board footer