# Generated by resolvconf
How this can happend? Maybe a time issue?
Ok i get the problem solved
There was a config error with wrong dev names and netctl start fails, but the fun part is netctl-auto works also with the bad config only resolv was not set.
]]>Does anyone know how to specify per-profile DHCP client options in netctl nowadays? DhcpcdOptions was removed.
They are still supported, but no longer documented in netctl.profile(5). This is part of the move to a plugin based DHCP client system. If you wish you can propose a text for netctl.dhcp(5).
It would be nice to extend client support. Nowadays dhcpcd supports IPv6 too, so that could be added. Other clients, such as udhcp could also be added. In the near future, it might be possible to add support for the built-in client in systemd/networkd.
]]>Does anyone know how to specify per-profile DHCP client options in netctl nowadays? DhcpcdOptions was removed.
For dhcpcd DhcpcdOptions should still work I think. If you use dhclient, the variable is DhclientOptions. At least those variables are used in the scripts and I don't see why they would not be accepted.
]]>IFPLUGD_CURRENT=up
OLDPWD=/
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
IFPLUGD_PREVIOUS=down
ForceConnect=yes
PWD=/
LANG=en_US.UTF-8
SHLVL=2
_=/usr/sbin/env
So it seems to have a state IFPLUGD_CURRENT and IFPLUGD_PREVIOUS. Also, ForceConnect seems to be in there. But nothing whatsoever about what interface is being started/stopped. In my existing ifup/ifdown hooks, I get ACTION (ifup/ifdown), DEVICE, INTERFACE/IFACE.
Also, it converts any settings for the interface into environment variables, prefixed with IF_.
]]>I had assumed as much already and set the execute bit for the user privileges only ( using `chmod u+x ...` )
The reason I'd asked before was I just wondered if there are any file extensions that are always considered executable?
Or if netctl expects a particular file extension / suffix for the 'interface' config files? -- maybe one which it can auto-execute for itself?
I know that the man page said not to use certain suffixes for the main profile files but it wasn't clear if this applied to the files under './interfaces' and './hooks' as well...
Profile names must not contain newlines and should not end in '.action', '.conf', or '.service'.
Anyway I've connected okay using `systemctl start netctl@wlan0.service` now!
I did try the auto-connect service first, but this didn't work! -- I'll have to look in to the "why" of this more, later
Thanks so much!!
]]>I wasn't using `netcfg` previously however it was installed
-- actually I just ran `wpa_supplicant` and then `dhcpcd` directly as root, lol
Anyway, I need some clarification please.
In the netctl.profile man page is states:
Whenever a profile is read, all executable scripts in
'/etc/netctl/hooks/' and any executable script in
'/etc/netctl/interfaces/' with the name of the interface for the profile
are sourced.
I was just wondering what constituted as an "executable" script please?
Does it matter what the file name is? (i.e. does it need a '.conf' suffix or something?)
~ or ~
Does it mean that I have to explicitly set the executable bit with `chmod`?
Thanks
]]>case $ACTION in
LOST)
ACTION=DISCONNECT
;;
REESTABLISHED)
ACTION=CONNECT
;;
esac
NOTE: this will only work in netctl 1.3 and newer. For earlier versions, change ACTION to action.
]]> # Testing the restart of dhcpcd when losing connection
LOST)
dhcpcd -k "$interface"
exit $?
;;
REESTABLISHED)
if [[ -x "$PROFILE_DIR/interfaces/$interface" ]]; then
source "$PROFILE_DIR/interfaces/$interface"
fi
dhcpcd -qL -t "${TimeoutDHCP:-10}" $DhcpcdOptions -K "$interface"
exit $?
# Not handled.
# exit 0
;;
And it works well. But after reestablishing a connection, for some reason, dhcpcd also tries to acquire a IPv6 address. Doesn't happen on connection, even though both dhcpcd calls are identical.
]]>Whenever the interface is disabled by the fancy button on my notebook, by rfkill or by "ip link set wlp3s0 down", the dhcpcd process of netctl-auto seems to have problems and should possibly restart.
The two possibilities I've tested were:
1. Killing the current dhcpcd process to start a new one. Actually, that works pretty well, Interesting fact is, while the original dhcpcd process started by netctl is getting problems after reconnecting, my manually started dhcpcd process (with just "dhcpcd wlp3s0") has no problems with the reconnection. Changing networks is no problem, too, the manually started dhcpcd process gets terminated by the new one.
2. systemctl restart netctl-auto@wlp3s0. Works, but I don't like restarting the whole thing.
So, what is the difference between my dhcpcd and netctl's dhcpcd?
Edit: Okay, I discovered there are some other "problems" dhcpcd, too... For example, when netctl-auto connects to a wireless network and DHCP fails, dhcpcd is terminated and netctl-auto will do nothing at all. That's the point where I have to terminate all netctl* services and manually start a netctl profile...
]]>sysctl -q -w net.ipv6.conf.<interface>.accept_ra=0
which is in line with the documentation that it blocks router advertisements. The problem is that it does this really late in the process - after the interface is up and after ipv4 DHCP (if this is requested). This gives plenty of time for router advertisements to be accepted before they are blocked. As a result, on my home network (which is IPv4/6 dual stack), "IP6=no" results in a fully configured IPv6 address just as with "IP6=stateless".
This is concerning as there is a real risk of malicious router advertisments on public IPv4-only wireless hotspots, and "IP6=no" does not prevent this at present. As a side point, I wonder whether it might be better to make a (correctly functioning) "IP6=no" be the default for the same reason.
Thanks very much for your work on netctl - it seems like a great tool.
]]>What happens if you choose to use something else for eth0 (like maybe net0) instead? Do they both work then?
]]>SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wifi0"
# ls /sys/class/net
eth0 lo wlan0
Which may account for why wireless isn't working for some people.
Yes, I have /etc/udev/rules.d/80-net-name-slot.rules linked to /dev/null.
]]>