From ArchWiki
Revision as of 16:16, 25 July 2013 by Lahwaacz (Talk | contribs) (Netctl does not start when the system at the other end of the connection is down: re, closing)

Jump to: navigation, search

Wrong headings

I believe that "Just one profile" is in fact about static profiles and "Multiple profiles" is in fact about profiles managed dynamically with respect to whether NIC's are connected or not. This is misleading, and should be corrected. What do you think? Doru001 (talk) 09:16, 13 July 2013 (UTC)

I've updated the section, let me know if there are more things to clarify. -- Lahwaacz (talk) 16:15, 25 July 2013 (UTC)

Netctl does not start when the system at the other end of the connection is down

This note:

Note: The connection to a dhcp-server is only established if the interface is connected and up at boot time (or when the service starts). In order to have an automatic connection established on cable connect, proceed to #Multiple Profiles.

is misleading, because the connection is only established if the interface is connected at activation time, period. Can I delete "to a dhcp-server" from there? Doru001 (talk) 10:49, 11 July 2013 (UTC)

No longer necessary, I found SkipNoCarrier=yes in man netctl.profile. Doru001 (talk) 09:08, 13 July 2013 (UTC)
I've added a note into that section, closing. -- Lahwaacz (talk) 16:16, 25 July 2013 (UTC)

Passphrase in section 3.3

Passphrase in 3.3, what is it about? What is it protecting and how do I set it?
-- Doru001 (talk) 10:29, 27 May 2013 (UTC)

That section is talking about obfuscating the passphrase to connect to a wireless network. By default, netctl stores the passphrase to connect to a wireless network in plaintext. If a nefarious user is able to read the passphrase stored on your system, then they can connect to your wireless network. Obfuscating the passphrase just makes this more difficult to do. Section 3.3 explains how to obfuscate the passphrase.
-- Jstjohn (talk) 15:29, 27 May 2013 (UTC)
Thank you, now it is clear. Doru001 (talk) 06:30, 29 May 2013 (UTC)

netctl does not start at boot

I carefully followed the instructions on this page and on the Beginner's Guide to migrate from netcfg to netctl and, as I said here, netctl does not start at boot. Please tell me what is wrong and, if necessary, complete the instructions.--Doru001 (talk) 14:01, 30 May 2013 (UTC)

As a result of the above mentioned thread I added the entry about sudo systemctl disable network to the netcfg to netctl migration list. Please check and post here if that is wrong.--Doru001 (talk) 07:10, 31 May 2013 (UTC)
I removed your entry to the wiki, your problem is not related to transition from netcfg. network.service is user-created.
-- Lahwaacz (talk) 10:41, 31 May 2013 (UTC)
network.service is user created according to the Beginner's Guide and I believe that this simple instruction would serve many while not hurting anybody. Doru001 (talk) 08:32, 1 June 2013 (UTC)
Maybe we should add a line saying that other network caring services like network.service and others should be disabled. How about this? Doru001 (talk) 13:56, 1 June 2013 (UTC)

Altering a currently enabled profile

Concerning this note:

  • If there is ever a need to alter a currently enabled profile, execute netctl reenable <profile> to apply the changes.
  • interface is hardware minus, e.g netctl-auto@wlan0.service or netctl-auto@enp2s0.service

I find the second line in this note confusing, and the first line may be unnecessary. I found myself having to reboot my system to get any wireless profile changes to take effect. Through trial and error, I finally figured out the command systemctl restart netctl-auto@<interface>.service allows the changes to take effect without requiring a reboot. Further, it appears that the command netctl reenable <profile> is not necessary to achieve these results; although, some profile modifications did require that I issue the systemctl restart netctl-auto@<interface>.service command twice before my wireless Internet connection would come back up. Has anyone else observed this? Mc33 (talk) 04:59, 17 July 2013 (UTC)

From netctl(1):
reenable [PROFILE]
    Reenable the systemd unit for the profile specified. This is effectively a combination of ‘disable’ and ‘enable’.
So I'd say the first line of the note is absolutely incorrect. I think your command systemctl restart netctl-auto@<interface>.service should be listed instead, and we should probably add simple netctl restart <profile> too in case people don't use netctl-auto@.service. -- Lahwaacz (talk) 07:45, 17 July 2013 (UTC)
On the contrary, the reenable command is correct. But it applies to specific profiles, not to netctl-auto. Halosghost (talk) 12:32, 17 July 2013 (UTC)
Right, it does not apply to netctl-auto, my mistake... But my point is, that it does not manipulate currently running processes, it only deletes & re-creates some symlink. To actually apply changes to some profile, you need to netctl restart <profile>. -- Lahwaacz (talk) 13:05, 17 July 2013 (UTC)
Regarding the second line, I have absolutely no idea of what does interface is hardware minus mean... -- Lahwaacz (talk) 07:45, 17 July 2013 (UTC)