DHCP v6 - no route to host
-
I was feeling brave and enabled DHCP6 on my pfSense. After some futzing around with firewall rules and client software I finally got a DHCP Solicit to pfSense dhcpd which wasn't able to process the solicit.
Here's an extract from the DHCP log:
Mar 5 14:22:20 dhcpd: DHCPREQUEST for 192.168.211.240 from 00:12:7b:46:e7:65 via bridge0
Mar 5 14:22:20 dhcpd: DHCPACK on 192.168.211.240 to 00:12:7b:46:e7:65 via bridge0
Mar 5 14:22:34 dhcpd: Solicit message from fe80::c57c:f1e6:9fd1:14fa port 546, transaction ID 0xCF57C400
Mar 5 14:22:34 dhcpd: Picking pool address 2001:470:1f05:14b3::16
Mar 5 14:22:34 dhcpd: Sending Advertise to fe80::c57c:f1e6:9fd1:14fa port 546
Mar 5 14:22:34 dhcpd: send_packet6: No route to host
Mar 5 14:22:34 dhcpd: dhcpv6: send_packet6() sent -1 of 104 bytes
Mar 5 14:22:35 dhcpd: DHCPREQUEST for 192.168.211.240 from 00:12:7b:46:e7:65 via bridge0
Mar 5 14:22:35 dhcpd: DHCPACK on 192.168.211.240 to 00:12:7b:46:e7:65 via bridge0I notice the dhcp log doesn't record the interface on which the DHCP solicit came in but it does record the interface on which DHCP v4 requests arrive. And when I compared the destination address for the Advertise with the route table (# netstat -rn) there wasn't any obvious route to that address. But why does it need a route? Surely the advertise should go out the interface on which the solicit arrived.
My DHCPV6 server is enabled on LAN. LAN interface is bridge0 (which has a configured IPv6 address) which has members vr0 and ath0, neither of which have configured IPv6 addresses.
I'm running 2.0-RC1 (i386)
built on Thu Mar 3 17:43:05 EST 2011. I'm using IPv6 address allocation associated with a Hurricane Electric tunnel. -
Ok, I might need to check the firewall rules, since you have a bridge that could complicate things.
When dhcp6 assigns a address it communicates via the fe80 link local address, and what might be happening here is that dhcpd is tied to the wrong interface causing it to use the the wrong link-local address.
I'd have to check, but i'd guess that dhcpd is not using the bridge0 interface. Maybe our bridge doesn't forward fe80 link local traffic, which I guess it should, it's a bridge.
-
Ok, I might need to check the firewall rules, since you have a bridge that could complicate things.
How would the firewall rules cause a "No route to host error return"? And dhcpd obviously reports receiving a request?
When dhcp6 assigns a address it communicates via the fe80 link local address, and what might be happening here is that dhcpd is tied to the wrong interface causing it to use the the wrong link-local address.
So it shouldn't be trying to route? Does the send/sendto/sendmsg system call in dhcpd source code have the MSG_DONTROUTE flag specified?
I'd have to check, but i'd guess that dhcpd is not using the bridge0 interface. Maybe our bridge doesn't forward fe80 link local traffic, which I guess it should, it's a bridge.
The log shows dhcpd seeing the DHCP V4 requests on bridge0 but there is ambiguity about DHCP V6 because dhcpd doesn't report the interface of the V6 request. And there seems to be separate processes for DHCP V4 and DHCP V6 so it may be reckless to assume the "V6" process will be listening on the same interface as the "V4".
Here's the contents of the DHCP configuration file:
more /var/dhcpd/etc/dhcpdv6.conf
option domain-name "example.org";
option ldap-server code 95 = text;
option domain-search-list code 119 = text;default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
subnet6 2001:470:1f05:14b3::/64 {
range6 2001:470:1f05:14b3::8 2001:470:1f05:14b3::16;
# Not supported in IPv6; option dhcp6.routers 2001:470:1f05:14b3::1;
option dhcp6.name-servers 2001:470:1f05:14b3::1;
}and the subnet6 clause specifies the bridge0 subnet:
ifconfig bridge0
bridge0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
ether a2:42:0b:44:ff:f2
inet 192.168.211.173 netmask 0xffffff80 broadcast 192.168.211.255
inet6 2001:470:1f05:14b3::1 prefixlen 64
nd6 options=3 <performnud,accept_rtadv>id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: vr0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 3 priority 128 path cost 200000
member: ath0_wlan0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 13 priority 128 path cost 370370
#</learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></performnud,accept_rtadv></up,broadcast,running,promisc,simplex,multicast>Any other information that might be useful? Or tests you would like me to run?
-
I remember reading somewhere that FreeBSD deliberately does not assign a link local address to a bridge interface because it is not a physical interface.
-
I remember reading somewhere that FreeBSD deliberately does not assign a link local address to a bridge interface because it is not a physical interface.
On thinking about this issue I wondered whether it would make a difference if the bridge had a link local address. In the absence of a link local address the send code for a bridge might decide that it needed to look up the routing table to find a way to get to the destination.
I added to the bridge a link local IPv6 address I calculated from the the bridge's assigned mac address (but I misread 'b' in the bridge MAC address as '6'):
ifconfig bridge0 inet6 add fe80::a242:06ff:fe44:fff2/64
ifconfig bridge0
bridge0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
ether a2:42:0b:44:ff:f2
inet 192.168.211.173 netmask 0xffffff80 broadcast 192.168.211.255
inet6 2001:470:1f05:14b3::1 prefixlen 64
inet6 fe80::a242:6ff:fe44:fff2%bridge0 prefixlen 64 scopeid 0xe
nd6 options=3 <performnud,accept_rtadv>id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: vr0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 3 priority 128 path cost 200000
member: ath0_wlan0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 13 priority 128 path cost 370370
#</learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></performnud,accept_rtadv></up,broadcast,running,promisc,simplex,multicast>Soon after the DHCP log started indicating the DHCP response completed successfully:
Mar 6 00:39:55 dhcpd: Solicit message from fe80::ec89:c46a:8e2f:4ad port 546, transaction ID 0x514AC200
Mar 6 00:39:55 dhcpd: Picking pool address 2001:470:1f05:14b3::16
Mar 6 00:39:55 dhcpd: Sending Advertise to fe80::ec89:c46a:8e2f:4ad port 546
Mar 6 00:39:55 dhcpd: send_packet6: No route to host
Mar 6 00:39:55 dhcpd: dhcpv6: send_packet6() sent -1 of 104 bytes
Mar 6 00:41:05 dhcpd: Solicit message from fe80::212:7bff:fe46:e765 port 546, transaction ID 0x1921C200
Mar 6 00:41:05 dhcpd: Picking pool address 2001:470:1f05:14b3::16
Mar 6 00:41:05 dhcpd: Sending Advertise to fe80::212:7bff:fe46:e765 port 546
Mar 6 00:41:05 dhcpd: Request message from fe80::212:7bff:fe46:e765 port 546, transaction ID 0x453A6600
Mar 6 00:41:05 dhcpd: Sending Reply to fe80::212:7bff:fe46:e765 port 546
Mar 6 00:41:23 dhcpd: DHCPREQUEST for 192.168.211.231 from 00:1c:bf:b8:96:1d via bridge0
Mar 6 00:41:23 dhcpd: DHCPACK on 192.168.211.231 to 00:1c:bf:b8:96:1d via bridge0
Mar 6 00:43:50 dhcpd: DHCPREQUEST for 192.168.211.191 from 00:03:47:81:cd:f7 via bridge0
Mar 6 00:43:50 dhcpd: DHCPACK on 192.168.211.191 to 00:03:47:81:cd:f7 via bridge0
Mar 6 00:46:00 dhcpd: Solicit message from fe80::ec89:c46a:8e2f:4ad port 546, transaction ID 0xC41D500
Mar 6 00:46:00 dhcpd: Picking pool address 2001:470:1f05:14b3::14
Mar 6 00:46:00 dhcpd: Sending Advertise to fe80::ec89:c46a:8e2f:4ad port 546
Mar 6 00:46:01 dhcpd: Request message from fe80::ec89:c46a:8e2f:4ad port 546, transaction ID 0xC41D500
Mar 6 00:46:01 dhcpd: Sending Reply to fe80::ec89:c46a:8e2f:4ad port 546and my Linux netbook suddenly showed an address matching one of the DHCP assigned IPv6 addresses:
root@kogan:~# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:12:7b:46:e7:65
inet addr:192.168.211.240 Bcast:192.168.211.255 Mask:255.255.255.128
inet6 addr: 2001:470:1f05:14b3:212:7bff:fe46:e765/64 Scope:Global
inet6 addr: fe80::212:7bff:fe46:e765/64 Scope:Link
inet6 addr: 2001:470:1f05:14b3::16/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1202584 errors:0 dropped:0 overruns:0 frame:0
TX packets:1097997 errors:7478 dropped:7478 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1080459299 (1.0 GB) TX bytes:264067254 (264.0 MB)There is an ifconfig option (eui64) that looks as if it might be useful in computing the link local address from the bridge MAC address but the man page doesn't give a usage example. I'll explore that and report back later.
-
that should be easy enough to fix then. Before activating the dhcp server for v6 I could just activate that.
-
Found it, this is why you don't have link local by default on bridges:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_ifattach.c
-
Sorry, I couldn't find an explanation in the revision history in the web page you linked to. Did you mean to link to a particular revision of that source file?
-
There is an ifconfig option (eui64) that looks as if it might be useful in computing the link local address from the bridge MAC address but the man page doesn't give a usage example. I'll explore that and report back later.
On reboot, my previously assigned link local address disappeared so there was an opportunity to try out the eui64 option:
# ifconfig bridge0 bridge0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 ether 86:8f:1f:f9:d3:c6 inet 192.168.211.173 netmask 0xffffff80 broadcast 192.168.211.255 inet6 2001:470:1f05:14b3::1 prefixlen 64 nd6 options=3 <performnud,accept_rtadv>id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 3 priority 128 path cost 200000 member: ath0_wlan0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 13 priority 128 path cost 370370 # ifconfig bridge0 inet6 add fe80::0/64 eui64 ifconfig: could not determine link local address # ifconfig bridge0 inet6 add fe80::868f:1fff:fef9:d3c6/64 # ifconfig bridge0 bridge0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 ether 86:8f:1f:f9:d3:c6 inet 192.168.211.173 netmask 0xffffff80 broadcast 192.168.211.255 inet6 2001:470:1f05:14b3::1 prefixlen 64 inet6 fe80::868f:1fff:fef9:d3c6%bridge0 prefixlen 64 scopeid 0xf nd6 options=3 <performnud,accept_rtadv>id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 3 priority 128 path cost 200000 member: ath0_wlan0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 13 priority 128 path cost 370370 #</learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></performnud,accept_rtadv></up,broadcast,running,promisc,simplex,multicast></learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></performnud,accept_rtadv></up,broadcast,running,promisc,simplex,multicast>so, looks as if the eui64 option is no use to generate a link local address from the "MAC" address of a bridge.
-
Sorry, I couldn't find an explanation in the revision history in the web page you linked to. Did you mean to link to a particular revision of that source file?
http://lists.freebsd.org/pipermail/freebsd-net/2007-March/013835.html
rev 1.28
Add support for multicast to the bridge and allow inet6 addresses to be
assigned to the interface.IPv6 auto-configuration is disabled. An IPv6 link-local address has a
link-local scope within one link, the spec is unclear for the bridge case and
it may cause scope violation.An address can be assigned in the usual way;
ifconfig bridge0 inet6 xxxx:… -
Thanks.
-
After updating to 2.0-RC1-IPv6 (i386)
built on Sun Mar 20 02:20:38 EDT 2011 I noticed in /var/log/system.log:Mar 21 06:29:42 pfsense php: : The command ' bridge0 inet6 fe80::/64 eui64' returned exit code '127', the output was ''
and
Mar 21 06:41:53 pfsense dhcpd: send_packet6: No route to host
Mar 21 06:41:53 pfsense dhcpd: dhcpv6: send_packet6() sent -1 of 84 bytesso I guess the eui64 option doesn't work on bridges. (I have a wired LAN and wireless LAN bridged together and DHCP server on the bridge.)
-
That means I need to write a php function to perform that calculation. Sometime this century then.
Attempted fix committed.
-
How is the MAC address of a bridge calculated anyway? Mine seems to change on every boot. Is it some random value?
-
How is the MAC address of a bridge calculated anyway? Mine seems to change on every boot. Is it some random value?
From the FreeBSD bridge man page:
The if_bridge interface randomly chooses a link (MAC) address in the range reserved for locally administered addresses when it is created. This address is guaranteed to be unique only across all if_bridge interfaces on the local machine. Thus you can theoretically have two bridges on the different machines with the same link addresses. The address can be changed by assigning the desired link address using ifconfig(8 ).
-
Ah.
There is a utility called ipv6calc that can be used to generate EUI 64 link local addresses.
http://www.tunnelbroker.net/forums/index.php?topic=751.0
In reality I've been able to get away with any random nonsense and it seems to work. It may not be right but so is assigning a link local to a bridge.
-
Calculating the eui64 from the existing hardware address isn't too bad with a bad of calculus and string replacement. I just have not tried reproducing it yet.
-
I was feeling brave and enabled DHCP6 on my pfSense. After some futzing around with firewall rules and client software I finally got a DHCP Solicit to pfSense dhcpd which wasn't able to process the solicit.
I still can not get the DHCPv6 service to work on my pfSense box. Can't figure out why. All it lists in the logs is:
May 2 11:23:38 dhcpd: Sending on Socket/14/em0/2001:470:xxx:51::/64
May 2 11:23:38 dhcpd: Listening on Socket/14/em0/2001:470:xxx:51::/64
May 2 11:23:38 dhcpd: Bound to *:547
May 2 11:23:38 dhcpd: Wrote 0 leases to leases file.
May 2 11:23:38 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
May 2 11:23:38 dhcpd: All rights reserved.
May 2 11:23:38 dhcpd: Copyright 2004-2010 Internet Systems Consortium.
May 2 11:23:38 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1DHCPv4 works fine, however DHCPv6 requests never arrive at or get logged by pfSense. Since you mention in your post you had to play with firewall rules to get it to work, I was wondering what exactly did you set in your rules? Possibly that's the issue here as well.
-
One step further.. it was indeed a firewall rule that blocked the DHCPv6 requests. I have an alias which specifies the IPv4 and IPv6 ranges on my local network which are allowed to send traffic through pfSense. From the logs posted here I noticed the DHCPv6 requests come from fe80::/64 addresses. So I added that to my alias specifying my local network addresses and the DHCP logs started to report the DHCPv6 requests and give out leases.
The problem I'm facing now is that my client does get an IPv6 lease from pfSense, but it doesn't request the gateway and it assumes the DHCPv6 address to have a CIDR of 128. So it can not connect to the outside world and can not reach other IPv6 hosts within the same /64 address space.
-
I think I have found the problem.
It is caused by this change about a week ago:
https://rcs.pfsense.org/projects/pfsense/repos/pfSense-smos/commits/753bd64dffb8352ea273c1bf1f00aa099ec38634The raflags for the rtadvd router discovery were changed from a numeric format to a letter in the /etc/inc/services.inc file. The translation for the "assist" mode wasn't correct though. The 192 number has been replaced by an O while this should be a M and an O. This will cause my Windows 7 client to discover the pfSense router first and get the assignment from it to request an IPv6 address via a DHCP broadcast resulting in both a gateway and an IPv6 lease. Currently since it only gives the O assignment, it only uses DHCPv6 to discover DNS services on the network, but not retrieve a DHCPv6 address. This causes it to generate its own address based on the address space the gateway is in.
Documentary supporting this thought: http://blogs.technet.com/b/teamdhcp/archive/2009/03/03/dhcpv6-understanding-of-address-configuration-in-automatic-mode-and-installation-of-dhcpv6-server.aspx from which I qoute:
Both M and O Flags are Set to 1. DHCPv6 is used for both addresses and other configuration settings. This combination is known as DHCPv6 stateful, in which DHCPv6 is assigning stateful addresses to IPv6 hosts.
And actually the /etc/inc/services.inc file also contains a comment supporting this:
/* raflags, other o, managed=64 m, stateful=128, both=192 */
@Databeestje, could you have a look at this and change it in the code if you confirm my suspicion to be correct?
I changed my DHCPv6 operating mode to Managed /services_dhcpv6.php to see what that would do and now my pfSense installation seems to have gotten corrupt. I'm getting loads of the following messages in my logs:
dhcpd: /var/db/dhcpd6.leases line 834: corrupt lease file; expecting ia_na contents, got ' '
When starting the dhcpd deamon it actually kills the whole webinterface and will eventually result in the following message in my browser:
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 24 bytes) in /etc/inc/util.inc on line 905
When I run killall dhcpd through the console, the webinterface comes back up. Even trying to set it back to operating mode Assisted will not get it working anymore. Also the mentioned file /var/db/dhcpd6.leases file does not exist so I have no idea why it tries to read line 834 from it.
Does anyone have a clue how I can fix this again?
-
I got the dhcpd deamon back up again. I simply went to Diagnostics -> Edit file -> /cf/conf/config.xml -> Load and replaced the <lan>contents within <dhcpdv6>with an empty set of nodes copied from a NIC on which DHCPv6 was not enabled. Now the dhcpd deamon starts again. However, when I try to enable the DHCPv6 service again in any operation mode, the problem returns. So there is a serious bug in there somewhere which once triggered will eliminate the use of the DHCPv6 service.</dhcpdv6></lan>
-
Now I know how to reproduce the out of memory issue. I'll have a look later this evening.
-
I saw you have adjusted the raflags accordingly. Just gitsynced and ran some tests and it works like a charm now! Only thing I can't get to work yet is the DHCPv6 reservations. Reservations are simply ignored and an address from the address pool is provided. Is this a thing you're still working on or should it work and do I need to play with it some more to try to get it to work?
-
Actually what I can not do anymore with the latest version is let pfSense send out the advertisements through rtadvd and let my Windows DHCPv6 hand out the IPv6 addresses as it used to do (since I have the IPv6 reservations working on my Windows server). For it to work I need pfSense to advertise itself using the MO flags, but when I configure pfSense in Assisted mode, it automatically also enables its own DHCPv6 service thus causing a conflict on the network with pfSense which is also giving out addresses. Ideally it should be that I can always choose an operating mode on the DHCPv6 page in pfSense, but only when I check the box to enable the DHCPv6 server, it will also enable the DHCPv6 service. Sounds rather logical too if you think about it. Is this a thing you agree on Databeestje and can realize? I can change the Javascript on the page to allow this if you want.
-
Databeestje, I saw you have followed up on my proposal already and checked in some changes regarding this matter. Great work! I have found a few issues with it so far:
1. When I keep the mode at advertised and disable the DHCPv6 service, it still provides DHCPv6 addresses
2. The DHCP service reports an error on startup in the system log:php: /services_dhcpv6.php: The command '/usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid em0_vlan3' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ /etc/dhcpdv6.conf line 23: expecting string or hexadecimal data. host-identifier option dhcp6.client-id ; ^ /etc/dhcpdv6.conf line 28: expecting string or hexadecimal data. host-identifier option dhcp6.client-id ; ^ Configuration file errors encountered – exiting If you did not get this software from ftp.isc.org, please get the latest from ftp.isc.org and install that before requesting help. If you did get this software from ftp.isc.org and have not yet read the README, please read it before requesting help. If yo
3. When entering a DUID at the DHCPv6 reservation page, it does not get past the validator which keeps stating that it is not a valid DUID while it is. I also do not understand the remark posted under the field:
Enter a DUID Identifier in the following format:
"DUID-LLT - ETH – TIME --- ---- address ----"
"xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx"My DUID matches the xx:xx format shown, but is not accepted. What is meant with the line above the xx:xx?
-
I see new checkins have been done which fix the DUID problem. I can indeed add a DUID reservation now. However, the whole DHCPv6 system doesn't work anymore with the latest gitsync. I'm getting this error in the system log:
php: /services_dhcpv6.php: The command '/usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid em0 em0_vlan3' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ /etc/dhcpdv6.conf line 23: expecting string or hexadecimal data. host-identifier option dhcp6.client-id 00-01-00-01-12-0D-0D-6C-00-1E-8C-4A-56-F ^ /etc/dhcpdv6.conf line 36: expecting string or hexadecimal data. host-identifier option dhcp6.client-id ; ^ /etc/dhcpdv6.conf line 41: expecting string or hexadecimal data. host-identifier option dhcp6.client-id ; ^ Configuration file errors encountered – exiting If you did not get this software from ftp.isc.org, pleas
I noticed it complaining about my DUID reservation. I have added it as Windows reports it: in the xx-xx-xx format instead of the required xx:xx:xx format. You might want to add a little regular expression JavaScript validation on the DUID field to make sure its added in the xx:xx:xx format. Or better yet, add a piece of JavaScript to the onblur of the textfield that will replace the '-' with ':' so it's still Windows copy/paste friendly :)
I just changed the DUID to the correct xx:xx:xx format. I'm still getting an error in the system logs and am still not getting a DHCPv6 lease. Also still nothing in the DHCP logs regarding IPv6 requests or responses. The error I'm getting in the system logs is:
php: /services_dhcpv6.php: The command '/usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid em0 em0_vlan3' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ /etc/dhcpdv6.conf line 36: expecting string or hexadecimal data. host-identifier option dhcp6.client-id ; ^ /etc/dhcpdv6.conf line 41: expecting string or hexadecimal data. host-identifier option dhcp6.client-id ; ^ Configuration file errors encountered – exiting If you did not get this software from ftp.isc.org, please get the latest from ftp.isc.org and install that before requesting help. If you did get this software from ftp.isc.org and have not yet read the README, please read it before requesting help. I
It seems there is still something wrong with my reservation so I removed the reservation and restarted the dhcp deamon. Now I'm getting in the situation again where the dhcpd service kills the webinterface of pfSense. Only this time, doing a killall dhcpd on the console did not bring it back up. So next I tried rebooting the pfSense server. Luckily this brings it back up again. I did notice an error during the boot though. Something with a foreach loop in some interfaces file. I tried rebooting again and recording the bootup into an AVI to capture the error, but it did not occur anymore.
After the reboot, still no response from the DHCPv6 service and still this error with all DUID reservations now being removed:
php: : The command '/usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid em0 em0_vlan3' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ /etc/dhcpdv6.conf line 31: expecting string or hexadecimal data. host-identifier option dhcp6.client-id ; ^ /etc/dhcpdv6.conf line 36: expecting string or hexadecimal data. host-identifier option dhcp6.client-id ; ^ Configuration file errors encountered – exiting If you did not get this software from ftp.isc.org, please get the latest from ftp.isc.org and install that before requesting help. If you did get this software from ftp.isc.org and have not yet read the README, please read it before requesting help. If you intend to requ
The router advertisement flags are still handed out correctly using assisted mode, DHCPv4 addresses are still provided, but no response at all from the DHCPv6 service anymore. May it have something to do with the firwall rules you have cooked into the software? The behavior is the same as when I had my firewall rules set incorrectly.
When I set it to unmanaged mode on the router advertisements, my clients discover the gateway and will auto-generate an IPV6 address to use. So that is okay.
-
More findings. Checking the in the error reported config file at /var/dhcpd/etc/dhcpdv6.conf I noticed the error is referring to the following content of this file:
}host s_opt1_0 {
host-identifier option dhcp6.client-id ;
fixed-address6 2001:470:-removed-:52::21;
option host-name DC4;
}
host s_opt1_1 {
host-identifier option dhcp6.client-id ;
fixed-address6 2001:470:-removed-:52::55;
option host-name KoenLaptop;
}Turns out on a different interface I still had two reservations. I removed these, restarted the dhcp deamon and no errors in the system logs anymore and it did start to provide DHCPv6 addresses again from the pool!
Next I tried adding a DUID reservation again. I did an ipconfig /renew6 on my Windows 7 x64 client and voila: my reserved IPv6 address was returned. Databeestje, you da man! :D
-
One more question.. I notice that when getting an DHCPv6 address from pfSense (either a static reservation or pool address), my Windows 7 x64 client will add a route to the routing table like this:
2001:470:-removed-:51::1111/128
Meaning.. all data between hosts on my local 2001:470:-removed-:51::/64 subnet will be routed to the default IPv6 gateway being pfSense. This brings extra unnecessary load on pfSense and causes the pfSense logs to be filled with entries regarding my local IPv6 traffic. Is it possible to have the clients designate a /64 route to the assigned IPv6 address?
Another question.. what is the IPv6 Prefix Pool field for in a DCHPv6 reservation?
Last thing.. don't forget to put updating /status_dhcpv6_leases.php on the todo list. It does show the leases, but not the IPv6 addresses, still shows a column MAC address instead of DUID and does not allow for pool leases to be translated to a reservation.
-
I was playing with the IPv6 Prefix Pool field and apparently it can kill whole pfSense. I now know why I didn't see the error during boot on the interfaces.inc file anymore. It only appears when having this field set and if so, it will kill the WAN interface completely. I caught the error. Check the attached screenshot. The error points to this section in the interfaces.inc file:
/* Setup the prefix delegation */
foreach($IfList as $pdinterface => $friendly) {
if(is_numeric($interface['ia-pd'])) {
$realif = get_real_interface($friendly);
$dhcp6cconf .= " prefix-interface {$realif} {\n";
$dhcp6cconf .= " sla-id {$interface['ia-pd']};\n";
$dhcp6cconf .= " sla-len {$config['interface'][$interface]['dhcp-ia-pd-len']};\n";
$dhcp6cconf .= " };\n";
}
}I removed this block completely from the interfaces.inc file, rebooted pfSense and now I have a working pfSense installation again. So there is a bug in this block that kills the WAN interface.
-
I also just found out that the DHCPv6 service is still very unstable. After a couple of successful DHCPv6 requests, it will stop responding to DHCPv6 requests. Restarting the dhcpd service will get it going again for a few requests. No errors logged though, so probably very difficult to trace to the cause.
-
The dhcp support is still very much a work in progress. The prefix pool setting for the dhcp client static mapping is for dhcp-pd support. This is what preactically the world will use for deploying IPv6 to end users.
You can save the prefix pool but is not used anywhere yet. That will come later. I need to BBQ first.
-
Might be work in progress, but works very well already :) I found out that deleting the existing /var/dhcpd/var/db/dhcpd6.leases file on my system and restarting the dhcpd service solved the problem of the dhcpd service only staying active for a few requests. It did give my quite some errors after restarting the dhcpd service the first time, but now it's up and running for two days already and still providing IPv6 addresses according to both the pool addresses and the configured reservations. So its almost perfect now.
I'm still wondering how I can solve the problem where the clients assign a /128 route to the assigned IPv6 address thus sending all IPv6 traffic via the pfSense firewall which is the default gateway. For IPv6 traffic on my local LAN this causes a lot of problems. Remote desktops from one machine to another for example will go over IPv6 by default but pfSense will drop a few packets every now and then causing the remote desktop to freeze. These dropped packets are logged by pfSense. When connecting to the same client using its local IPv4 address, it works well. If I could just get it to assign a /64 in the routing table on the client the problem would be solved. Anyone got a clue how to get this done?
-
https://lists.isc.org/pipermail/dhcp-users/2010-January/010810.html
-
Sounds like exactly the problem I was facing. Same errors and outcome. As stated above, for me it was solved by deleting the leases file and having dhcpd create a new one. Its still happily providing IPv6 leases now after being up for 2,5 day already.
-
Currently importing isc dhcpd 4.2.1-P1
-
Cool :) Do you have a clue how I could have the DHCPv6 leases set to /64 in the clients routing table?
-
not yet, open for options. new snapshots on my site with the new dhcpd
-
Hmm.. isn't this a thing that rtadvd should provide? My knowledge about IPv6 isn't sufficient to know if router advertisements should provide this, but it sounds logical. I'll do some searches on the internet to find out more about this.
-
I found a statement in RFC4862 on page 8 which to me sounds like the router advertisement should indeed provide the cidr block by providing an address prefix. I quote:
Router Advertisements also contain zero or more Prefix Information
options that contain information used by stateless address
autoconfiguration to generate global addresses. It should be noted
that a host may use both stateless address autoconfiguration and
DHCPv6 simultaneously. One Prefix Information option field, the
"autonomous address-configuration flag", indicates whether or not the
option even applies to stateless autoconfiguration. If it does,
additional option fields contain a subnet prefix, together with
lifetime values, indicating how long addresses created from the
prefix remain preferred and valid.I remember seeing the cidr notation in the rta config before. I'll check out the rtadvd man pages for more info.
-
I see you already got this stuff included in the /var/etc/rtadvd.conf file and it looks fine. Hmm. What could it be.