Hi,

I have a question regarding netctl-auto.

I started netctl-auto on my wireless interface.

netctl-auto start wlp8s0

After this I confirmed that I was connected to one of the wireless networks defined in my profiles by using iwconfig.

However

netctl list

did not show a * next to the connected profile, as I would have expected.
Would this be the correct usage?

I have enabled two profiles:

bers@bers-server ~ $ cat /etc/netctl/lan
Description='bers-home network'
Interface=eth0
Connection=ethernet
IP=static
Address=('192.168.168.193/28')

bers@bers-server ~ $ cat /etc/netctl/wan
Description='RTK PPPoE internet'
Interface=eth0
Connection=pppoe
User='#user#'
Password='#pass#'
ConnectionMode='persist'

So, when first one started, the second one can't load with message:

The interface of network profile 'wan(lan)' is already up

and vice versa.

I solved that problem by adding ForceConnect=yes to both configs. It starts fine on boot but another problem has appeared.
When I sometimes issue netctl stop(restart) wan it stops lan profile as well. As you may assume this is very annoying when being connected via SSH through lan network.
As I can understand it happens because of last line in lib/network/connections/pppoe which is:

pppoe_down() {

    #some code here

    bring_interface_down "$Interface"
}

So, how to get it working together without mess or is it actually a bug?

It would be really great to be able to somehow specify that a profile (say a mobile_ppp 3G connection) should be automatically disconnected if a "better" profile (say a WiFi connection) becomes available. The Priority field in the configuration might be able to provide this functionality already (does it work cross-interface?), but its documentation is fairly limited.

netcfg automatically inserted "scan_ssid=1" into the wpa_supplicant config file. Converting a profile to netctl, I found I have to add this manually to the WPAConfigSection.

This is probably a bug, but if not then the documentation should be adjusted.

once a profile is selected, another profile cannot start correctly.

reproduce:

1. select one profile with wifi-menu
2. select anther wifi with wifi-menu

In the file src/lib/connections/mobile_ppp a chat script is created to talk with a modem.
In this file the ATDT command is used:

'OK' 'ATDT*99#'

where *99# is the number to call.

I have found out that the number *99# is not always true. While I have configured the connection to my provider I found a list of login data for the different provider in Germany.

As you can see in the list, the number to call might be one of these:

• *99#
• 99**1#
• *98#

For me it was *99#, so I had no problem with my configuration, but I think the number to call should be configurable in netctl.profile (5).

Something like:

PhoneNumber = '*99#'

Description='A wireless connection using a custom network block configuration and encrypting the password for security using wpa_passphrase'
Interface=wlan0
Connection=wireless
Security=wpa-configsection
IP=dhcp
WPAConfigSection=(
'ssid="ssid"'
'key_mgmt=WPA-PSK'
'psk=PSK'
)

In addition to the netctl-ifplugd discussion on the pull request, enabling netctl-auto@wlan0 with a wlan0-using profile in /etc/network.d -- which starts and works correctly only if I manually "systemctl start netctl@wlan0-WRTG", but not if I netctl enable/systemctl disable as suggested in man netctl.special -- does nothing. The journal doesn't indicate that it's trying and failing or anything of the sort, just that it's supposedly scanning for matching wireless networks/profiles -- which it doesn't do. Even tried using ifplugd on wlan0 too, so it could bring it 'up' for scannage, but no dice.

Hi!

It seems that the latest release broke bridges without interfaces (to be used for, ex., virtualisation). I found that this commit fixes the problem: feb669f

Maybe it's time to release a new version? :)

(Sorry for the long message. Please do not consider it as smth offensive, just I'm trying to figure out if it is possible to make netctl even more convenient in everyday active usage)

Please consider the following scenarios and related usability questions.

1. We need to connect to an open network. Each time we do this we need to create a profile. This is quite inconvenient if we have dozens of open networks (like in airports, railway station) and we do not know which one is really open and which one tries to suck money from the credit card at a high rate (say 5euro/hour). Besides that, there is no much sense to create so many profiles that differ only by one parameter -- ESSID. I think the connection to open networks could be simplified.

2. If a profile fails there is no indication of the problem. So each time I have to look at journalctl -f . Why not just print the information to the terminal?

3. It fails often and it doesn't try to reconnect. If I use netctl-auto@wlan0 I often have to do "systemctl restart netctl-auto@wlan0". I think we need auto-reconnection in such cases.

4. Why it checks if the interface is up before doing a connection? Usually I need to see the list of networks before creating a profile. So each time I have to do "ifconfig wlan0 up; iwlist scna| less". Then I make a profile, attempts to connect... It fails, I go to system logs and... oh, right, the interface is up so it doesn't want to connect. Then I have to put interface down and repeat the connection attempt. If netctl is the only connection management software there is no point of that extra checks. As a user I would like to see connections "just working" without asking extra questions and extra configuration.

If I have the netctl-auto service enabled.
Trying to issue netctl switch-to, or use wifi-menu immediately fails:

The interface of network profile 'NETWORK' is already up

This seems really unintuitive to me. The fact that you have netctl-auto enabled means you are probably connecting to multiple networks, and it is highly likely you are connecting to new networks at least some of the time.

What makes it worse is that I can find no documentation of this in the man pages or on the Arch wiki. I spent a few days wondering why the only way I could get a new profile to work was to create it manually or with wifi-menu (which failed instantly) then rebooting.

Ideally, I would say netctl switch-to would take precedence over netctl-auto, if only by stopping the service.

Another alternative would be for wifi-menu to be able to detect netctl-auto running. In the case that it is, "connecting" to a network would just create the profile then restart netctl-auto which would then connect. (The problem with this is if two networks are available, netctl-auto would select one of them of it's own accord, I believe.)

Barring all that, at least put something in the man page about it?

I don't want to seem gripey. I think netctl is great! But I think more people than me are going to be bitten by this.

Right now, my wifi connection for me Arch machine is intermittent. The wifi AP is shutdown overnight. Come the morning when the AP is switched back on, netctl doesn't seem to make an effort to detect / rejoin the network.

Any ideas how I can resolve / debug this?

systemctl | grep netctl 
[email protected]                                                          loaded active exited    Automatically generated profile by wifi-menu
system-netctl.slice                                                                 loaded active active    system-netctl.slice

This might be related to #34

I uncommented out the IP6=dhcp which should be uncommented out by default IMHO in a fresh netctl 1.1-1.1 install in any case:
http://sprunge.us/OQDf

Yet still systemctl status [email protected]
http://sprunge.us/jSAR
shows dhcpcd -4qL -t 10 eth0.

The section about SPECIAL QUOTING RULES
need some clarification.

First of all the entire section has the risk of causing confusion by using the word quoted too many times.

Here is a list of questions that popped up when reading that section:
I hope they have answers which could be included in the document.

• Why "quoting" at all, what is the problem solved using the described technique?
• When should quoted be used and when should non-quoted be used?
• When talking about a variable being quoted or not is that about the actual ESSID/Key value or only how it is written in the config file?
• In the two examples, what is the value of X? Is it string in both cases or string and "string
• The extreme examples of "quoted double quote" is not explained, what is that exact value.
• Is this section about escaping?
• It says non-quoted should be used for hexadecimal strings, is there any other reason to use non-quoted?

In the end what I'm trying to find out is what should I write in the config file given a key value.
Examples: word, many words, spacebefore, word', 'word, "word, word"word, word", =word

With the default ethernet-dhcp from the examples directory, setting up a DHCP network on an IPv4-only network fails:

May 16 12:11:48 ar dhcpcd[2711]: eth0: sending IPv6 Router Solicitation
May 16 12:11:48 ar dhcpcd[2711]: eth0: broadcasting for a lease
May 16 12:11:52 ar dhcpcd[2711]: eth0: sending IPv6 Router Solicitation
May 16 12:11:54 ar dhcpcd[2711]: eth0: offered 192.168.2.17 from 192.168.2.1
May 16 12:11:54 ar dhcpcd[2711]: eth0: acknowledged 192.168.2.17 from 192.168.2.1
May 16 12:11:54 ar dhcpcd[2711]: eth0: checking for 192.168.2.17
May 16 12:11:56 ar dhcpcd[2711]: eth0: sending IPv6 Router Solicitation
May 16 12:11:58 ar dhcpcd[2711]: timed out

dhcpcd shouldn't be trying to get an IPv6 address, the following configuration "fixes" that:

DhcpcdOptions=-4

Other solutions that I have seen is using dhclient instead of dhcpcd.

Ok, I see there is $action variable in netctl-auto, but it would be nic to have $action variable also in hooks called via

netctl start $profile

I want to enable chrony after connect and disable after disconnet for all profiles, so POST* hook is not very practical for me.

When creating a bridge without specifying any interfaces to bind, we seem to be in a situation that netctl doesn't handle yet.

First, the question is what should denote that there aren't any interfaces to bind: An empty array or a BindsToInterfaces set to an empty string? I.e. what is correct:
1:
BindsToInterfaces=()
or
2:
BindsToInterfaces=

If 1 is the way to go, then this will fail in /src/netctl.in:114 because of the following defined behaviour of bash (from bash(1)): "Referencing an array variable without a subscript is equivalent to referencing the array with a subscript of 0". The test
[[ -v BindsToInterfaces ]] || BindsToInterfaces=$Interface
evaluates to true (because BindsToInterfaces[0] is indeed unset), thus BindsToInterfaces will get reset to $Interface. This will create entries in the unit file that will make the interface dependent on its own existence - leading to a blocking condition for bridges.
Short test:
bash -c 'BindsToInterfaces=(); [[ -v BindsToInterfaces ]] || echo Bummer.'

If 2 is the way to go, then it will fail in /src/netctl.in:115 instead.
This is because ${#BindsToInterfaces[@]} evaluates to "1" for non-arrays set to an empty string:
bash -c 'BindsToInterfaces=; echo ${#BindsToInterfaces[@]}'
Thus the code in the "if" section does get run when it shouldn't (creating a dependency on the "" interface...).

I will send a PR shortly that proposes a solution based on the idea that an empty array is the correct way.

PS: issue #86 might be related, though the problem there is that "BindsToInterfaces" isn't set at all and so /src/netctl.in:114 will set it to "$Interface", thus creating a dependency on itself. I didn't analyse that problem further, though.

this happens a lot for me. netctl simply exits, and i dont think this behavior is right.

Hi,

I had two separate timeout issues with netctl:

1. dhcpcd timeout which is set to 10 seconds compared to the tool's default 30 seconds
2. Carrier timeout when trying to bring up my ethernet device.

The problem is not that these timeouts occur but rather how netctl communicates them. There is no mention of a timeout in the second case. Additionally, it is not straight forward on how to avoid timeouts globally instead of on a per connection basis. I would suggest to give a more specific error message and also to expand the documentation and examples to include hook files for user setting of timeout and other variables.

Furthermore we could discuss if the current timeout values are sensible or whether we should select more conservative one's.

My network card requires some tweaking after a connection is made. It would be nice to put this in the interface configuration and not in each profile.

When one defines IP6=no on a netctl profile, the configured interface will have no static IP but it will still have a link local IPv6 address.

In the absence of a better solution, it seems adequate that netctl should execute the appropriate call (e.g. net.ipv6.conf.enp7s0.disable_ipv6) in order to fully disable IPv6 on that interface.

I tried to create a tunnel-interface with mode ip6ip6.

Man of netctl says:

OPTIONS FOR `tunnel' CONNECTIONS

Mode=

The tunnel type (e.g. `sit'). See ip(8) for available modes.

Man of ip tunnel says:

mode MODE
set the tunnel mode. Available modes depend on the encapsulating address family.
Modes for IPv6 encapsulation available: ip6ip6, ipip6, ip6gre, and any.

So ip6ip6 is available on my system.

This is my ip6ip6 tunnel profile:

Description='IPv6-Tunnel to Berlin'
Interface='ip6-tun'
Connection=tunnel
Mode=ip6ip6
Remote='2001:bf0:c003:40::139'
Local='2a03:4000:2:453::2'

IP6=static
Address6='2001:bf7:100:ff::1/64'
Gateway6='2001:bf7:100:ff::2'

Starting it fail with more than one error happening:

:59 # network[20276]: sysctl: cannot stat /proc/sys/net/ipv6/conf/ip6-tun/accept_ra: Datei oder Verzeichnis nicht gefunden
:53 # network[20276]: Starting network profile 'ip6-tun'...
:53 # network[20276]: Unknown tunnel mode "ip6ip6"
:54 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:54 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:54 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:54 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:54 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:55 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:55 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:55 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:55 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:55 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:56 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:56 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:56 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:56 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:56 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:57 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:57 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:57 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:57 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:57 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:58 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:58 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:58 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:58 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:58 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:59 # network[20276]: /usr/lib/network/network: Zeile 37: /sys/class/net/ip6-tun/flags: Datei oder Verzeichnis nicht gefunden
:59 # network[20276]: sysctl: cannot stat /proc/sys/net/ipv6/conf/ip6-tun/accept_ra: Datei oder Verzeichnis nicht gefunden
:59 # network[20276]: Cannot find device "ip6-tun"
:59 # network[20276]: Could not add address '2001:bf7:100:ff::1/64' to interface 'ip6-tun'
:59 # network[20276]: Device "ip6-tun" does not exist.
:59 # network[20276]: Cannot find device "ip6-tun"
:59 # network[20276]: Could not set gateway '2001:bf7:100:ff::2' on interface 'ip6-tun'
:59 # network[20276]: Failed to bring the network up for profile 'ip6-tun'
:59 # systemd[1]: netctl@ip6\x2dtun.service: main process exited, code=exited, status=1/FAILURE
:59 # systemd[1]: Failed to start Networking for netctl profile ip6-tun.
:59 # systemd[1]: Unit netctl@ip6\x2dtun.service entered failed state.

netcfg had PreUp and PostDown which netctl seems to be missing (in the man pages, I only found mention of ExecStartPost and ExecDownPre). Would it be possible to implement these? It seems it would be very easy to do so by adding ExecStartPre and ExecStopPost options in the corresponding systemd service file for a profile.

My concrete use case for this in netcfg was a Bluetooth tethering profile. I used the PreUp to set up a Bluetooth bnep interface through pand and the PostDown to tear the Bluetooth connection down after the profile was brought down. Can this perhaps be implemented in netctl in another way?

What am I doing wrong here?

http://ix.io/aXP

If I am using /etc/wpa_supplicant.conf as with the example https://github.com/joukewitteveen/netctl/blob/master/docs/examples/wireless-wpa-config do I need sudo systemctl enable [email protected]? Bit confused.

http://ix.io/aXQ

I'd like to propose a new feature to allow extensions to auto.action

This would allow user-defined actions to be executed after CONNECT/DISCONNECT/FAILED/etc wpa_actiond events.

I'll suggest these user scripts live under /etc/netctl/actions/ and are given the same parameters as wpa_actiond gives its scripts:

1. interface
2. ssid
3. profile
4. action

These scripts would be called after the default action handling used my netctl today. The scripts would be executed in directory-listing order, so use of 01-script.sh, 50-script.sh, etc. can be used.

This should allow some more convenience and flexibility as to when user-defined actions take place around network handling :)

See also: #50 Adding wpa_actiond handling of hooks

Hi,

I`ve made a tiny patch to netctl/src/lib/connections/bond, which allows user to configure bonding mode:

if is_interface "$Interface"; then
report_error "Interface '$Interface' already exists"
return 1
else
interface_add bond "$Interface"
fi

+if [[ ! -z "$Mode" ]]; then
+echo $Mode > /sys/class/net/${Interface}/bonding/mode
+fi

bring_interface_up "$Interface"

Mode can be set according to kernel documentation:
https://www.kernel.org/doc/Documentation/networking/bonding.txt

With our Cisco switches it takes up to 8 seconds to get a working link after setting the device to state "up". In that time, netctl has already failed. It would be nice, if this timeout could be variably set.

After issuing wifi-menu and setting the correct details it returns with an exit code of 2, failing to connect to the network. However issuing a restart of the services:
sudo systemctl restart [email protected]
allows for netctl to do its wpa_supplicant magic and connect..

03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e)
┌─[β-97%]0[edward][dexter][][]
└──╼ pacman -Q netctl
netctl 1.0-1
┌─[β-97%]0[edward][dexter][][]
└──╼ uname -a
Linux dexter 3.9.4-1-ARCH #1 SMP PREEMPT Sat May 25 16:14:55 CEST 2013 x86_64 GNU/Linux

If there is anything else let me know. yes yes I have done netctl-auto start wlan0 I read man pages of course ;)

Currently all WPA-Enterprise ssids fail right away because wifi-menu cannot enter id and password.

When running netctl stop on a non-existent profile, there's no message or error status.

# netctl stop doesntexist
# echo $?
0

Hi,
I want to know, If it is possible to create profiles like this:

bridge_interface

   Connection=bridge
   Interface=br0
   BindsToInterface=()
# As the device is running dhcp-server
   SkipForwardingDelay=yes

ethernet interface has two profiles
lan_bridge_member

   Connection=ethernet
   Interface=eth0
   ExecUpPost="brctl add br0 eth0"    # Consider this as a working command, I haven't looked it up
   ExecDownPre="brctl  remove br0 eth0"  # Consider this as a working command, I haven't looked it up
   IP=no
   IP6=no

lan_dhcp

   Connection=ethernet
   Interface=eth0
   IP=dhcp

I want to have a more flexible configuration of PirateBox on the RaspberryPi, so I want to let all the PirateBox-Services run against br0.
During the startup of PirateBox I'll add the hostapd-driven Hotspot interface wlan0 to the bridge br0.

The owner can easily decide, if he want to have a separate dhcp driven interface on the ethernet-port or should it be attached on the PirateBox-driven bridge with running the related netctl/systemd startup command

to make ethernet as a separate dhcp interface

netctl disable  lan_bridge_member
netctl enable lan_dhcp

to make ethernet as a part of PirateBox

netctl disable lan_dhcp
netctl enable  lan_bridge_member

(I would create a script for that, that uses is-enabled and so on)

Makes that sense?
Is there an easier way then using ExecDown.. ExecUp... ?

Thanks for your feedback in advance

Matthias

I have had not set the TimeoutDAD, but assigned also a static IPv4 adress. The system is still not reachable from the outside, because the interface is not up after booting. Looks like the TimeoutDAD was reached.

Full log: http://sprunge.us/OSfj

Nov 13 12:00:40 pihsg network[869]: Profile 'wlan0x2dKGBFREE' does not exist or is not readable
Nov 13 12:00:40 pihsg systemd[1]: [email protected]: main process exited, code=exited, status=1/FAILURE

Using the following netctl profile

Description="Bridge"
Interface=br0
Connection=bridge

IP=static
Address=('192.168.5.240/24')

the following error shows up on starting the profile:
Mar 31 10:45:59 dewy systemd-udevd[2203]: Could not apply link config to br0
IMHO this is a bug since this IP address is correctly assigned to the bridge.
p.s. Using IPCustom shows the same issue :)

Jouke,

Xen / KVM users frequently use Linux bridges (or OpenVSwitches) to support guest only network segments.

Current netctl configuration directives requires at least one interface added to "BindsToInterfaces". This creates a quite annoying situation where one mus either start its bridges manually (imho defeating the purpose of netctl) or to hack around the constraints by doing stuff like adding loopback or dummy interfaces into the BindsToInterfaces, etc.

It would be great if that could be simplified.

I think that it would be beneficial to allow connecting to hidden networks using wifi-menu (since wifi-menu is the first tool recommended according to Beginners guide on ArchWiki).
IMHO it would take adding one more dialog for asking for ESSID (when the selected is empty), setting correct Hidden parameter to profile and also indexing list of networks by AP MAC (+ESSID) instead of current ESSID.
Any plans or would be such PR welcomed?

This patch addresses point 2 in #45.
It automatically runs journalctl if the systemctl call fails. It should detect if running in a user terminal or not and skip appropriately. I've done some testing on my system (Arch linux) and it seems to work but more testing is probably good given that netctl is widely used. Diff is against 1.4.-2.

--- /usr/bin/netctl 2014-02-24 11:12:42.021776261 +0100
+++ netctl  2014-02-24 11:12:34.088473909 +0100
@@ -40,6 +40,10 @@
     shift
     set -- $(sd_escape "$@")
     systemctl $command $(printf 'netctl@%s.service\n' "$@")
+    if [ $? -ne 0 ] && [ -t 1 ]; then
+      echo Command failed, last 1 min of log:
+      journalctl -n -o cat -u $(printf 'netctl@%s.service\n' "$@") --since=-1m
+    fi
 }

 list() {

Found that when installing netctl without wpa_actiond installed, netctl-auto fails having inability to call wpa_actiond. But using dhcpcd directly to re-enable a connection followed by simply installing wpa-actiond (pulling wpa_supplicant with it) and retrying netctl-auto . It works fine.

Looking at src/netctl-auto there is no check to see if the device being used is wired/wireless since it isn't need. wpa_supplicant can be used in either case. I agree with this.

Stating that optdepends wpa_actiond is for automatically connecting for wireless connection. I don't agree with this. (not trying to be a jerk btw).

But, looking back at the PKGBUILD. I'm trying to get an understand as to your thought process behind it. The only hard dependencies that are listed are iproute2, coreutils, openresolv. It seems like if this is going to replace netcfg then it should work simply out the box wired/wireless with as little configuration as possible. I've prepaired a new pkgbuild that would allow this but I wanted to get your thoughts on it before submitting it.

I'm a big fan of this project. Thank you for listening.

Testing on the following following up to date builds:

• i686 wired & wireless
• x64 wired & wireless

Netctl creates incorrect service files for dummy interfaces.

Example profile:

Description="dummy0"
Interface=dummy0
BindsToInterfaces=()
Connection=dummy
IP=static

After enabling profile, it creates the following system service (/etc/systemd/system/[email protected]):

.include /usr/lib/systemd/system/[email protected]                                 

[Unit]                                                                           
Description=virt0                                                                
BindsTo=sys-subsystem-net-devices-dummy0.device                                   
After=sys-subsystem-net-devices-dummy0.device

With this configuration netctl start dummy0 will always fail due to waiting for dummy0 device to come up:

systemd[1]: Timed out waiting for device sys-subsystem-net-devices-dummy0.device.
systemd[1]: Dependency failed for virt0.

It works if I change /etc/systemd/system/[email protected] file to just this:

.include /usr/lib/systemd/system/[email protected]                                 

[Unit]                                                                           
Description=virt0

The title says it all. But imagine, for just one second, if the good-ole' tar command was as verbose as netctl et alia:

tar extract --verbose --gunzip --target-dir Downloads --file package.tar.gz

as compared to

tar -xzvC Downloads -f package.tar.gz

Would you really prefer the first option? Even if you personally do, would you deny users the convenience of the second option?

If there is a space in ESSID, wifi-menu creates a netctl profile that has a space in it's name.
wifi-menu can't use netctl profiles that have space in their name.
for example if the ESSID is "ESSID SPACE":
when you try to connect to it with wifi-menu using the auto generated profile:

Job for netctl@wlan0-ESSID\x20SPACE.service failed. See 'systemctl status netctl@wlan0-ESSID\x20SPACE.service' and 'journalctl -xn' for details.

Could you please consider exposing “maxfail” option to use in pppoe profiles? My rationale is:

a) setting it to 1 makes sense in my case, since my connection either starts right up on the first try or doesn't start at all,
b) settings it to 0 also makes sense, because it'll make pppd try to make connection over and over again, until the connection is made (when connection breaks in my case, it breaks for at least a couple of hours—being able to force pppd to stubbornly retry attempt to connect is most convenient),
c) doing so is trivial (implementation-wise at least) requiring merely changing
echo "maxfail 5" >> "${cfg}"
to
[[ -n ${Maxfail} ]] && echo "maxfail ${Maxfail}" >> "${cfg}"

BTW, I want to touch another potential problem. Even if pppd fails to connect and exits (after some retries), netctl still hapily shows appropriate profile as active and its status as “active (exited)”. I don't think this was the intention, so I'm pointing that out.

Of course I'll be happy to provide some more info, if required!

https://github.com/joukewitteveen/netctl/blob/master/docs/netctl.profile.5.txt

Says "802.11x authentication" instead of "802.1x authentication".

the "wifi-menu" command does not let me connect to WEP . I do have a hex key but I have no idea how to configure the profile, bottom line please support hex.

Hello to all.

I'm using Archlinux and I had a strange problem with the profile file that contained comments lines, the tool failed to start properly, after removing the comment lines from the profile files all worked perfect.

The topic for the problem is here: discussion topic

My system information: Linux arch-pc 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013 x86_64 GNU/Linux

Thank you for your effort. Hope that this will help somehow.

I recently, had a problem with eduroam not being able to get an IP, while searching for
a solution I found that increasing the TimeoutDHCP=20 solves it.

If there are no drawbacks, it would be great if that was the default.

      Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled)
      Active: failed (Result: exit-code) since Fri 2013-01-25 04:43:49 PST; 3min 27s ago
        Docs: man:netctl.profile(5)
     Process: 188 ExecStart=/usr/lib/network/network start %i (code=exited, status=1/FAILURE)

Jan 25 04:43:49 localhost network[188]: Starting network profile 'wlan0-UCLA_WEB.wifi-menu'...
Jan 25 04:43:49 localhost network[188]: Interface 'wlan0' does not exist
Jan 25 04:43:49 localhost network[188]: Failed to bring the network up for profile 'wlan0-UCLA_WEB.wifi-menu'
Jan 25 04:43:49 localhost systemd[1]: netctl@wlan0-UCLA_WEB.wifi-menu.service: main process exited, code=exited, status=1/FAILURE
Jan 25 04:43:49 localhost systemd[1]: Failed to start Networking for netctl profile wlan0-UCLA_WEB.wifi-menu.
Jan 25 04:43:49 localhost systemd[1]: Unit netctl@wlan0-UCLA_WEB.wifi-menu.service entered failed state

problem: wlan0 does not exist.

Having IP6 set to stateless, that is accepting router advertisements for routing information, doesn't mean that adding manually configured addresses is unwanted. Especially since router advertisements can tell clients to not generate a public address automatically (AdvAutonomous off).

Currently I workaround this by doing:

IP6=stateless
IPCustom=('addr add ....')

But it feels wrong to me. If it is the desired way of doing this kind of configuration, I'd appreciate a note in the docs.

After upgrading to netctl 1.4, I get an error saying that the passphrase length for wpa_supplicant is invalid. I used wifi-menu -o option to generate the psk. When I deleted the profile generated by wifi-menu -o, I regenerated the profile without the -o option. As you know, this results in the password appearing in plain text in the profile. Wifi now works in this case, but doesn't work when I encrypt the password using wifi-menu -o.

https://bugs.archlinux.org/task/35810

I originally filed the bug with archlinux, because I thought it was a problem there. However, it appears that there's a deadlock with the design of the tuntap connection type.

The tuntap connection type is supposed to create the interface by running ip tuntap add dev $Interface mode $Mode (with other options too.) Unfortunately, the systemd service script sets it up to bind to the interface, so it won't execute until the interface exists.

That's great for all the other connection types, except this one, because it needs to create the very interface it's binding on...