Package Details: wide-dhcpv6 20080615-13

Git Clone URL: https://aur.archlinux.org/wide-dhcpv6.git (read-only)
Package Base: wide-dhcpv6
Description: An open source implementation of DHCPv6 developed by KAME project (with Debian patches)
Upstream URL: http://wide-dhcpv6.sourceforge.net/
Licenses: custom
Submitter: Foucault
Maintainer: Foucault
Last Packager: Foucault
Votes: 5
Popularity: 0.000018
First Submitted: 2013-07-27 23:47
Last Updated: 2015-06-13 11:58

Dependencies (0)

Required by (0)

Sources (9)

Latest Comments

2bluesc commented on 2015-10-21 20:34

I think you're right. Looks like network-online.target would also replace NetworkManager.service and simplify things even more.

Foucault commented on 2015-10-21 19:47

Yes indeed network-online seems a more viable option. netctl@%i is too specific. However that NetworkManager service is strange. Do you use both netctl and NetworkManager?

2bluesc commented on 2015-10-21 19:42

Maybe network-online.target is ideal, initial testing on my machine looks good:

[Unit]
Description=WIDE-DHCPv6 Client on interface %I
+After=network-online.target
-After=network.target
-Requires=network.target
Before=dnsmasq.service
Before=NetworkManager.service
Documentation=man:dhcp6c(8) man:dhcp6c.conf(5)

2bluesc commented on 2015-10-21 19:11

Hey guys,

Found a bug with the .service file provided:

Oct 21 11:33:32 core.hq systemd[1]: network.target: Found ordering cycle on network.target/start
Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on NetworkManager-wait-online.service/start
Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on NetworkManager.service/verify-active
Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on dhcp6c@wan0.service/start
Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on network.target/start
Oct 21 11:33:32 core.hq systemd[1]: network.target: Breaking ordering cycle by deleting job NetworkManager-wait-online.service/start
Oct 21 11:33:32 core.hq systemd[1]: NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start deleted to break ordering cycle starting with network.target
Oct 21 11:33:32 core.hq systemd[1]: network.target: Found ordering cycle on network.target/start
Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on NetworkManager.service/verify-active
Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on dhcp6c@wan0.service/start
Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on network.target/start
Oct 21 11:33:32 core.hq systemd[1]: network.target: Breaking ordering cycle by deleting job NetworkManager.service/verify-active
Oct 21 11:33:32 core.hq systemd[1]: NetworkManager.service: Job NetworkManager.service/verify-active deleted to break ordering cycle starting with network.target/start

It seems impossible to require network.target and complete before other services like dnsmasq which also require network.target.

I use netctl for network, so I depend on my wide area interface coming up, patch for dhcp6c@.service:

[Unit]
Description=WIDE-DHCPv6 Client on interface %I
-After=netctl@%i.service
+After=network.target
+Requires=network.target
Before=dnsmasq.service
Before=NetworkManager.service
Documentation=man:dhcp6c(8) man:dhcp6c.conf(5)

This will be different for other network managers, not sure if there is a generic wide area network target, but that'd be better.

Foucault commented on 2015-04-09 10:12

Fixed, thank you!

thx1138 commented on 2015-04-09 06:12

The latest version of pacman has different "conflicting file" logic and complains with:

error: failed to commit transaction (conflicting files)
wide-dhcpv6: /usr/sbin exists in filesystem
Errors occurred, no packages were upgraded.

This can be resolved by changes to the PKGBUILD. In the build() function, adding:
...
--sysconfdir=/etc/wide-dhcpv6 \
--sbindir=/usr/bin

and in the package() function, changing:
mkdir -p "${pkgdir}/usr/sbin"
to:
mkdir -p "${pkgdir}/usr/bin"

thx1138 commented on 2015-01-15 04:11

I've noticed that systemd-networkd can interfere with dhcp6c, the WIDE DHCPv6 client daemon.

Currently, 2015 January, in systemd-networkd, the DHCPv6 client seems to not be working itself, despite what is implied by man 5 systemd.network, but still, if a "network" file is configured with:

[Network]
DHCP=both

or

[Network]
DHCP=v6

systemd-networkd will bind the DHCPv6 UDP port, number 546. If then dhcpv6c is started, to fetch just a Non-temporary Address, it will fail to bind to the interface. Maybe this is obvious, in retrospect. But remember to set:

[Network]
DHCP=v4

in any network files, if you are using systemd-networkd and dhcpv6c together.

Also, I noticed that the wpa_supplicant systemd service file uses:

[Unit]
After=sys-subsystem-net-devices-%i.device

and it seems like a useful thing to add to the dhcp6c systemd service file as well, especially for when the device is a wireless device. Of course, make an appropriate substitution for "%i", if necessary, depending upon whether the service file is a "template" file, or instead, references an Environment File.

2bluesc commented on 2014-07-08 21:22

I don't know how common it is to have multiple (full disclosure: I don't need it) dhcpv6 interfaces, but I see no reason to limit AUR users wit this. I'm following the spirit of netctl and friends that use instances per interface.

The dual systemd service file will work, but seems distracting. This AUR package doesn't need to cater to me, but I think my requests are more generic and is why I brought them up -- to hopefully improve the usefulness for everyone.

@Foucault the revised conf files make sense as well, but we need to be careful of all the systems that will break when it changes. That's how my original frustration came about. :)

Foucault commented on 2014-07-04 16:03

Well that's an (unexpectedly) heated discussion!

What could be done is to provide both a dhcp6c@.service and dhcp6c.service file (that's what the dhcpcd package does for example). Then everyone is happy although at the moment the only advantage that %I provides is the ability to spawn multiple instances of the program for many interfaces. Is it *that* common though (honest question)?

I would not like to change the environment variable names though, since in my opinion more descriptive variables are better (within reasonable limits, of course), as in "self-documenting". The conf file name choice was a bit poor indeed and it would be better to change it to something more sane (/etc/conf.d/dhcp6c.conf or something). Same thing goes with the sysconfdir, which is named after the program. It is reasonable to use "wide-dhcpv6" as the dir name since this is how the program is named and it would help to avoid confusion with other dhcp programs (ISC, dhcpcd, whatever). "dhcpv6" is a bit vague and I am not willing to change that (FYIW, debian also uses wide-dhcpv6).

Foucault commented on 2014-07-04 16:02

What could be done is to provide both a dhcp6c@.service and dhcp6c.service file (that's what the dhcpcd package does for example). Then everyone is happy although at the moment the only advantage that %I provides is the ability to spawn multiple instances of the program for many interfaces. Is it *that* common though (honest question)?

I would not like to change the environment variable names though, since in my opinion more descriptive variables are better (within reasonable limits, of course), as in "self-documenting". The conf file name choice was a bit poor indeed and it would be better to change it to something more sane (/etc/conf.d/dhcp6c.conf or something). Same thing goes with the sysconfdir, which is named after the program. It is reasonable to use "wide-dhcpv6" as the dir name since this is how the program is named and it would help to avoid confusion with other dhcp programs (ISC, dhcpcd, whatever). "dhcpv6" is a bit vague and I am not willing to change that (FYIW, debian also uses wide-dhcpv6).

All comments