PfSense does not get an IPv6 address on WAN
-
Hi all!
I am totally lost on IPv6 in combination with pfSense. Right now, I am using pfSense 2.3.2-p1 on an APU1D4 board using 3 Realtek 8111E type ethernet controllers at home, but I have had these issues since at leaset Version 2.1.
First of all, IPv4 is working as expected; I get a public IPv4 address from the modem / the provider.- But as it uses carrier grade NAT, I cannot use IPv4 for connecting to my home network.
I am using the German provider "Deutsche Glasfaser", who should provide a native, public IPv6 address and a /56 prefix. The pfSense is connected with one of the ethernet controllers to the fibre modem (or router) provided by "Deutsche Glasfaser".
If I use a FritzBox instead of the pfSense, the public IPv6 address is provided via DHCPv6 to the FritzBox router, so the modem seems to do what it is supposed to do.
But when I replace the FritzBox with the pfSense and set my WAN interface to use SLAAC or DHCP (no matter which combination of options I activate), the pfSense just does not get an address (except the link-local addresses).
I unchecked the "Bogon Networks", checked the "All IPv6 traffic will be blocked by the firewall unless this box is checked" option, tried to alter some sysctl variables (like accept_rtadvd), searched the internet for months and I guess I must have tried virtually any combination of options, tried resetting to factory defaults, tried re-installed the box to get rid of possible messed-up configurations i tried earlier, but no matter what I do, the pfSense just does not get a public IPv6 address. There are no logs whatsoever that tell me what's going on, there is no firewall rule blocking anything (checked with "tcpdump -n -e -ttt -i pflog0", because the GUI log does not show implicit rules), there is no NAT rule messing with my packets.
At "Status" -> "System logs" -> "DHCP" in the web-GUI there is not a single entry regarding DHCPv6, it is all v4 related.
What can I do to chase down this issue? What am I missing? What's going on here?
I appreciate any hints, tips, whatever that might help me in getting a public IPv6 address finally…
Thanks in advance!
<update>Being sure to already have tried that, I tried to run the command "dhcp6c -c /var/etc/dhcp6c_wan.conf -d re0" again (re0 is my WAN interface). Indeed, it gave me a public IP address immediately on re0, but a few seconds later, my IPv4 stack on re1 went down and approx. 30 seconds later up again. As re1 does not have anything IPv6-related configured, again, I have no idea what's going on... The main question that arises is: Why is "dhcp6c" not started on activating DHCPv6 on my WAN via the web interface? Even after a restart, no dhcp6c process is in "ps aux" output. Is this a bug, that dhcp6 client is just configured, but never started?</update>
-
It may be that your ISP doesn't provide a prefix until a DHCP solicit is received from the router, but pfsense doesn't send a DHCP solicit until it receives an RA in response to the RS. There is a fix for this issue in the 2.4 development snapshot. (There may be a patch available for 2.3, but I'm not sure.)
If you want to try 2.4, the way you enable this feature is to enable the setting in the WAN called "do not wait for RA".
-
Hi!
This might be the case - but this does not explain that I do not get an IPv6 address at all. So my first humble wish is to get an IP address everytime I boot the box or I toggle WAN interface.
When this is fixed, I will try to get a prefix and pass addresses to my LAN network :)The problem here seems to be that dhcp6c does not start automatically, neither on boot time nor at WAN activation. If I did not start dhcp6c manually (which gives me an IPv6 address immediately on WAN), I would never get an IPv6 address.
So the basic question is: why does dhcp6c not start e.g. at boot time? Are there logs that I could take a look at to debug this?
-
So I have exactly the same problem.
pfSense doesn't get an IP and the support of "Deutsche Glasfaser" is too dumb to give me details on the IPv6 configuration.
-
After 3 Nights testing, "Deutsche Glasfaser" work for me, now for one day
Only one Problem left. After Reboot, I have to wait for get a ipv4 then login in by ssh
killall -9 dhcp6c
dhcp6c -c /var/etc/dhcp6c_wan.conf -d igb0
After done i have a ipv6 , with tracking interface on Lan I am able to advice ipv6 to clients by dhcpv6.
Wan Prefix is set to /56 and lan to /64, get prefix over ipv4 is off.Pfsense 2.3.2 p1
-
After 3 Nights testing, "Deutsche Glasfaser" work for me, now for one day
do you use DHCP6 on WAN interface or SLAAC? any other advanced settings?
-
DHCPv6 Assistend
::1000 to ::2000 in IPadress pool.
Both work linux with SLAAC and mac with DHCPV6 .
Leases with DHCPV6 are displayed.
But I can´t assign a fix adress to a device. Any Idea.
-
Today I got a brouchure from "Deutsche Glasfaser", which says DHCP (for IPv4), IPv6rd and IPv4/IPv6 has to be supported by the router.
Does that mean I should try the 6rd Tunnel or 4to6 Tunnel on WAN?
EDIT: Tried that and shit's not working.
I don't have the configuration details for 6rd…Here are a few informations:
https://www.deutsche-glasfaser.de/fileadmin/Content/Pdf/Downloads/Anleitungen/Genexis_Live__mit_eigenem_Router_anschliessen.pdf
https://www.flink-glasfaser.de/fileadmin/pdfs_flk/20160831_DG_Schnittstellenspezifikation_final_online.pdf
https://www.new.de/fileadmin/user_upload/new.de/Dokumente/Glasfaser/NEW_Glasfaser_Leistungsbeschreibung.pdf
http://glasfaser-haltern.de/images/DGhome_Leistungsbeschreibung.pdf
-
Does that mean I should try the 6rd Tunnel or 4to6 Tunnel on WAN?
I would suspect that brochure is a bit out of date. If they are providing native IPv6, as reported by Maps, there is no need of a tunnel, which is what 6rd and 6to4 are. My own ISP also provided tunnels, but have had native IPv6 since about April.
-
My Setup:
WAN:
DHCP
DHCP6
Emtpy MAC/MTU/MSS
No Options DHCP Client
DHCPv6 Client
Only 56 Prefix and prefix HintBoth Block off.
LAN:
Static ipv4
Track Interface
No MTU ..Track IPV6:
WAN
ID 1
No BlocksDHCP V6 RA
Sever
Range.
::1000 ::2000
64 PrefixRA:
Assisted
High
Rest empty.State now : IPv6 is running.
-
Hi all!
@mkapalla: The brochures state that there is an IPv4/IPv6 dual stack and IPv6rd, so the tunnel probably is not the preferred way to use IPv6 with Deutsche Glasfaser (So I agree with JKnott). They definitively provide native IPv6 addresses.
@Maps: Thanks for sharing your configuration with us, highly appreciated.This thread was about the fact that dhcp6c does not start correctly or not at all at system start or interface activation, so I would like to keep the topic here and would suggest that you start a thread with a headline describing your issue. I guess chances will be better to get your issues solved if the headline of the thread matches the content.
So does anybody have any hints?
-
As I said above, a possible cause for dhcp6c not starting is because pfsense is waiting for the edge router to respond with RA. pfsense will wait forever for the RA and will not start dhcp6c. ipv6 will not work at all. If you're not sure whether your isp edge router requires a dhcp6 solicit before it will respond to an RS, download the 2.4 development snapshot and configure the wan with "do not wait for RA". If that doesn't solve your problem, maybe someone else has another idea.
-
Where did I found a nano version from 2.4 ? Or does the memstick version works too with the SD card in my Alex app ?
-
I saw NanoBSD is not supported on 2.4.
What did the RA don´t wait done ? Is it only web path and i am able to do it in a config file by hand or a dhcp6c path ?Offtopic @ other "Deutsche Glasfaser" user. What is your plan to apply the Telefon functions ? sipproxy, asterisk on pfsense ?
-
What did the RA don´t wait done ? Is it only web path and i am able to do it in a config file by hand or a dhcp6c path ?
Normally when pfsense starts, it sends an RS, waiting for an RA, then when the RA is received, it starts dhcp6c. Some ISPs have configured their edge routers to not respond to an RS until after a dhcp solicit is received. In that case, there is a deadlock causing dhcp6c to never start. If you can get a prefix by manually starting dhcp6c, it's an indication that this may be happening. The feature is enabled using the webgui in the wan settings, but it's only available in 2.4. (There were some patches to 2.3, but not sure if they are compatible with 2.3.2_1.)
-
Just install the 2.3 development version, it's working fine. All the additions for Don't wait for RA have been included.
-
I can confirm, with don´t wait RA, in the 2.3 Dev Release I got the IPV6 network IP on WAN.
-
I can confirm, with don´t wait RA, in the 2.3 Dev Release I got the IPV6 network IP on WAN.
Good news.
I stopped updating the patches months ago when it was included in the 2.3 dev versions and I never got around to writing them for earlier releases.
-
I think there is a small issue in the fix.
When I had change the settings in the lan interface, the system will save and apply the setting,then the ipv6 will not come back.
When I release the Wan IP and renew it with the gui the IPV6 Net will come back.It is possible , in this case the RA settings will not be used ?
-
I think there is a small issue in the fix.
When I had change the settings in the lan interface, the system will save and apply the setting,then the ipv6 will not come back.
When I release the Wan IP and renew it with the gui the IPV6 Net will come back.It is possible , in this case the RA settings will not be used ?
No there is no issue with the fix. When you take down the LAN interface you clear it, the IPv6 address and PD is created by the script that runs when the WAN interface goes online. You just need to be aware of the way that prefix delegation works. If you left it long enough then I suspect that the dhcp6 time would expire and then refresh, giving you an address and prefix again; of course how long you would need to wait depends on your ISP and the lease renewal interval, mine is 30 minutes but others could be a day or two or even longer.
-
There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.
-
There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.
I've not been looking at this thread or the 5993 issue for months, I've been a bit busy with real work. :)
Couple of questions, does dhcp6c shutdown on WAN release and does dpinger shut down also?
I think I know why this isn't high on the list of things to fix, you are unlikely to run pfSense without the WAN interface online, it serves no purpose and I tend to make any changes required, which are few and rare and then reboot.
-
There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.
Can you send me a couple of images showing the interface and what you mean, you have my pm.
-
@marjohn56:
There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.
Can you send me a couple of images showing the interface and what you mean, you have my pm.
Email sent.
-
@marjohn56:
There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.
I've not been looking at this thread or the 5993 issue for months, I've been a bit busy with real work. :)
Couple of questions, does dhcp6c shutdown on WAN release and does dpinger shut down also?
I think I know why this isn't high on the list of things to fix, you are unlikely to run pfSense without the WAN interface online, it serves no purpose and I tend to make any changes required, which are few and rare and then reboot.
Here are the dhc* processes with everything running normally:
root 29136 0.0 0.1 8204 2188 - Is 18:33 0:00.01 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d localdomain -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts dhcpd 42701 0.0 0.7 22808 13868 - Ss 18:33 0:00.00 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid hn0 dhcpd 44541 0.0 0.6 20760 11644 - Ss 18:33 0:00.00 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid hn0 root 45032 0.0 0.1 6152 1920 - Is 18:33 0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php|/bin/sh -l /var/dhcpd/var/db/dhcpd6.leases root 49261 0.0 0.1 10496 2384 - Is 14:00 0:00.00 dhclient: hn1 [priv] (dhclient) _dhcp 53588 0.0 0.1 10496 2488 - Is 14:00 0:00.04 dhclient: hn1 (dhclient) root 54290 0.0 0.1 8340 2216 - Is 14:00 0:00.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_hn1.pid hn1 root 90460 0.0 0.1 10448 2516 - Ss 13:08 0:08.12 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.confHere are the dpinger processes:
root 33207 0.0 0.1 10952 2408 - Is 14:01 0:02.91 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 50.98.86.223 -p /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.pid -u /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 50.98.84.1 root 33564 0.0 0.1 10952 2436 - Is 14:01 0:03.38 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP6 -B fe80::215:5dff:fe5c:e21e%hn1 -p /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.pid -u /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 fe80::ea4:2ff:fe29:5001%hn1Here are the dhc* processes with the interface released:
dhcpd 36277 0.7 0.6 20760 11644 - Ss 18:37 0:00.00 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid hn0 root 36560 0.6 0.1 6152 1920 - Ss 18:37 0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php|/bin/sh -l /var/dhcpd/var/db/dhcpd6.leases root 29136 0.0 0.1 8204 2188 - Is 18:33 0:00.01 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d localdomain -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts dhcpd 42701 0.0 0.7 22808 13868 - Ss 18:33 0:00.02 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid hn0 root 90460 0.0 0.1 10448 2516 - Ss 13:08 0:08.13 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.confHere are the dpinger processes:
root 33207 0.0 0.1 15048 2492 - Is 14:01 0:02.96 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 50.98.86.223 -p /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.pid -u /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 50.98.84.1 root 33564 0.0 0.1 10952 2436 - Is 14:01 0:03.44 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP6 -B fe80::215:5dff:fe5c:e21e%hn1 -p /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.pid -u /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 fe80::ea4:2ff:fe29:5001%hn1Here are the dhc* processes after renew:
dhcpd 46926 0.0 0.7 22808 13868 - Ss 18:38 0:00.00 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid hn0 root 72135 0.0 0.1 10496 2384 - Is 18:38 0:00.00 dhclient: hn1 [priv] (dhclient) _dhcp 76998 0.0 0.1 10496 2488 - Ss 18:38 0:00.00 dhclient: hn1 (dhclient) root 77847 0.0 0.1 8340 2216 - Ss 18:38 0:00.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_hn1.pid hn1 dhcpd 90268 0.0 0.6 20760 11644 - Ss 18:39 0:00.00 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid hn0 root 90460 0.0 0.1 10448 2516 - Ss 13:08 0:08.16 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf root 90592 0.0 0.1 6152 1920 - Ss 18:39 0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php|/bin/sh -l /var/dhcpd/var/db/dhcpd6.leases root 99184 0.0 0.1 8204 2188 - Ss 18:38 0:00.01 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d localdomain -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hostsHere are the dpinger processes:
root 94836 0.0 0.1 10952 2408 - Is 18:39 0:00.15 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 50.98.86.223 -p /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.pid -u /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 50.98.84.1 root 94938 0.0 0.1 10952 2436 - Is 18:39 0:00.02 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP6 -B fe80::215:5dff:fe5c:e21e%hn1 -p /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.pid -u /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 fe80::ea4:2ff:fe29:5001%hn1unbound and radvd do not automatically restart on their own after renewing the interface. They have to be manually restarted.
I have set the DHCP Reservation and Static DHCP options in the resolver settings.
Let me know if you need any more info.
I agree this isn't a show-stopper, but if the ISP service is interrupted, pfsense may not come back without manual intervention.
-
Just to confirm to others reading this thread, I checked this earlier and my pfSense behaves; however we are running different versions, I am running the latest 2.3 snapshot where BimmerDriver is running 2.4. I will run up a test version of 2.4 and try and confirm this issue and take if from there, providing real work does not get in the way again!
-
@marjohn56:
Just to confirm to others reading this thread, I checked this earlier and my pfSense behaves; however we are running different versions, I am running the latest 2.3 snapshot where BimmerDriver is running 2.4. I will run up a test version of 2.4 and try and confirm this issue and take if from there, providing real work does not get in the way again!
I just downloaded the latest 2.3 and 2.4 snapshots and I will perform a clean installation using both versions to see if there is any difference in the behaviour I described above.
-
@marjohn56:
Just to confirm to others reading this thread, I checked this earlier and my pfSense behaves; however we are running different versions, I am running the latest 2.3 snapshot where BimmerDriver is running 2.4. I will run up a test version of 2.4 and try and confirm this issue and take if from there, providing real work does not get in the way again!
I just downloaded the latest 2.3 and 2.4 snapshots and I will perform a clean installation using both versions to see if there is any difference in the behaviour I described above.
I just checked both 2.3 and 2.4 clean installations. Setup is identical. Virtually everything default except wait for RA and prefix only (/56). Also set unbound to register leases and static addresses. The dpinger issue is exactly the same. I did notice that the restart of radvd is not consistent. Sometimes it does restart on its own. I will post logs or whatever other info anyone would like to see.
-
It's certainly strange, I cannot make it do anything wrong in this respect.
What's your hardware and are you using a RAM for temp?
-
@marjohn56:
It's certainly strange, I cannot make it do anything wrong in this respect.
What's your hardware and are you using a RAM for temp?
Both systems are running on a hyper-v 2012 R2 server and I'm not using RAM for temp.
I'm not clear how dpinger works, but if it's pinging the ISP edge router, it would appear that releasing the interface doesn't seem to be actually releasing the ipv6 interface, at least not right away.
-
I think it's using the link local address for pinging ipv6, at least it is with my system; this may be part of the problem as that's not released. I have switched back to 2.4 now so I'll do some more testing this week and see what shows up.
-
@marjohn56:
I think it's using the link local address for pinging ipv6, at least it is with my system; this may be part of the problem as that's not released. I have switched back to 2.4 now so I'll do some more testing this week and see what shows up.
From what I recall about earlier versions, it has always used the link-local address. I believe that is the only address that's available. However, dpinger hasn't always had this issue. In an earlier iteration, when the interface was released, dpinger was not able to ping the edge router.
-
Interesting…
O.K. well I've finished off most of the changes to dhcp6c now and that's all sorted apart from removing rubbish from the log like ctrl crud on startup, but that can wait. I'll see if I can find out why dpinger is not closing.
