pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162016-03-06T14:40:23ZpfSense bugtracker
Redmine pfSense - Bug #5957 (Resolved): Fix for missing route creation during reboot for delegated prefix...https://redmine.pfsense.org/issues/59572016-03-06T14:40:23ZAnders Lindanders.lind@gmail.com
<p>I have noticed that if pfSense reboots then routes to sub-routers are not re-created.<br />Meaning subnets given by DHCPv6 using prefix delegation to sub-routers stop to work after pfSense reboots.</p>
<p>The reason for this is that routes are currently only created when there are changes to the lease file content.<br />Meaning first when a random dhcp6 client is asking for a new lease or a change to an existing lease dhcpleases6 will detect this and recreate all routes to active leases.</p>
I have the following assumptions (just correct me if I am wrong):
<ul>
<li>The sub-router is responsible for its own routes from its subnets and out through its WAN interface</li>
<li>whereas pfSense is responsible for the routes in the direction towards the sub-routers.</li>
<li>As long as (active) leases are valid in the lease file pfSense should make sure routes to sub-routers exist.</li>
<li>What happens if something deletes the lease file or e.g. the subnet prefix (global routing prefix + subnet ID) of the pfSense WAN changes or the subnet prefix that pfSense delegates from changes I do not know, but in this case where the lease file contains (active) leases I assume it is irrelevant; something else must choose e.g. to delete the lease file if the subnet prefix changes.</li>
</ul>
<p>I have tried to analyze the problem and I have found that simply touching the lease file (after a reboot of pfSense) is enough like:<br /><pre>
touch -c -m /var/dhcpd/var/db/dhcpd6.leases
</pre><br />, meaning only if file exists (-c) then change modification time (-m) of the lease file.<br />(So -c to avoid creating the file if someone/something wanted it not to be there.)<br />This triggers dhcpleases6 to recreate the route to my sub-router.</p>
So I have come up with these two alternatives:
<ol>
<li>Using this 'hack' and setting it into:<br /><a class="external" href="https://github.com/pfsense/pfsense/blob/b5fcc2b5e4d13a766a3965f0997ccde450051757/src/etc/inc/services.inc#L1558">https://github.com/pfsense/pfsense/blob/b5fcc2b5e4d13a766a3965f0997ccde450051757/src/etc/inc/services.inc#L1558</a><br />between lines 1558 (meaning after "mwexec("/usr/local/sbin/dhcpleases6...") and 1559:<br /><pre>
mwexec("/usr/bin/touch -c -m {$g['dhcpd_chroot_path']}/var/db/dhcpd6.leases");
</pre><br />, e.g. with a 'sleep 1;' in front of '/usr/bin/touch' to make sure dhcpleases6 has deamonized itself.<br />I have tested this by adding the line to services.inc <em>however <strong>without</strong> using</em> 'sleep 1;' and it works on all the reboots I have made until now.</li>
<li>Adding some lines between lines 538 - 539 (<strong>untested</strong>):<br /><pre>
else {
system(command);
}
</pre><br />to dhcpleases6.c ( <a class="external" href="https://github.com/pfsense/FreeBSD-ports/blob/3faff56ee509fbcfc167c7c6d41f810239cd4e4f/sysutils/dhcpleases6/files/dhcpleases6.c#L538">https://github.com/pfsense/FreeBSD-ports/blob/3faff56ee509fbcfc167c7c6d41f810239cd4e4f/sysutils/dhcpleases6/files/dhcpleases6.c#L538</a> )<br />Note - 'command' points to: /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php|/bin/sh<br />as shown in <a class="external" href="https://github.com/pfsense/pfsense/blob/b5fcc2b5e4d13a766a3965f0997ccde450051757/src/etc/inc/services.inc#L1558">https://github.com/pfsense/pfsense/blob/b5fcc2b5e4d13a766a3965f0997ccde450051757/src/etc/inc/services.inc#L1558</a></li>
</ol>
<p>I will let you decide which of these two suggestions are more appropriate.</p>
<p>Again, thank you all for your time!</p> pfSense - Bug #5944 (Resolved): Fixes for various issues in status_dhcpv6_leases.php and prefixes...https://redmine.pfsense.org/issues/59442016-03-02T17:17:49ZAnders Lindanders.lind@gmail.com
<p>As a continuation of <a class="external" href="https://redmine.pfsense.org/issues/4206">https://redmine.pfsense.org/issues/4206</a> I have made some bug fixes.<br />They address the following issues:</p>
<em>status_dhcpv6_leases.php</em>
<ul>
<li>Fix indexing of $mappings: Remove "$entry['iaid'] . " from $mappings[] since the IAID of the IA_NA does not need to be equal to the IAID of the IA_PD, please see note in <a class="external" href="https://redmine.pfsense.org/issues/4206#note-9">https://redmine.pfsense.org/issues/4206#note-9</a><br />This makes sure that Routed To in Delegated Prefixes can be shown even when the IAID of the IA_NA != to the IAID of the IA_PD.</li>
</ul>
<ul>
<li>Fix column headers: Add table header for the icon in the Delegated Prefixes section to fix alignment of the column headers.</li>
</ul>
<ul>
<li>Fix lack of incrementation of index in parse_duid() when two characters have been combined and passed (meaning \\ and \") for use in the IAID and DUID strings.</li>
</ul>
<ul>
<li>Fix check in parse_duid() of $n so that the octal value is checked as an octal value and not with is_numeric($n).</li>
</ul>
<em>prefixes.php</em>
<ul>
<li>Fix substr mistake: I made a silly mistake in extract_duid() and overlooked an important difference between javascript substring() and php substr().</li>
</ul>
<ul>
<li>Tightened regex check for octal value in extract_duid().</li>
</ul>
<ul>
<li>Fix missing check for $active to avoid creating a route to a released lease.</li>
</ul>
<p>I will link to the pull request in a moment.</p> pfSense - Bug #5637 (Resolved): services_dhcpv6.php - DHCPv6 Server PD Range To/From: Form IDs !=...https://redmine.pfsense.org/issues/56372015-12-13T15:54:50ZAnders Lindanders.lind@gmail.com
<p>In "DHCPv6 Server / DHCPv6 Options" PD Range To/From differs.<br />Form IDs != $_POST IDs</p>
<p>More specific:<br />"Form_Input('prefix_from', ..." does not work well with $_POST['prefixrange_from']<br />Likewise for prefix_to != prefixrange_to</p>
<p>This is easy to fix.</p>
<p>Suggested fix:<br />Rename prefix_from and prefix_to to prefixrange_from and prefixrange_to.<br />(Remember there are 2x occurences of prefix_from/prefix_to)</p>
<p>Reference:<br /><a class="external" href="https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/services_dhcpv6.php">https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/services_dhcpv6.php</a></p> pfSense - Bug #4206 (Resolved): Missing route creation on DHCP-PD lease where ia-na != ia-pdhttps://redmine.pfsense.org/issues/42062015-01-12T15:52:43ZAnders Lindanders.lind@gmail.com
<p>The long story ( <a class="external" href="https://forum.pfsense.org/index.php?topic=86374.0">https://forum.pfsense.org/index.php?topic=86374.0</a> ) short:<br />When a prefix is delegated through DHCP for IPv6 from a pfSense edge router to a SOHO D-Link sub-router then only the DHCPv6 info is supplied to that sub-router, but pfSense does not create the route to the sub-router/delegated sub-network.</p>
<p>The problem short:<br />The route is never created because the resulting string generated by /usr/local/sbin/prefixes.php is:<br />/sbin/route change -inet6 <delegated network> <but missing WAN address of the sub-router><br /> E.g.:<br />/sbin/route change -inet6 2a02:abcd:dcba:3fff::/64</p>
<p>The cause ( <a class="external" href="https://forum.pfsense.org/index.php?topic=86374.msg474928#msg474928">https://forum.pfsense.org/index.php?topic=86374.msg474928#msg474928</a> ):<br />The lease file /var/dhcpd/var/db/dhcpd6.leases contains for the sub-router different strings for ia-na and ia-pd that leads to that the WAN address of the sub-router becomes the empty string, because /usr/local/sbin/prefixes.php at lines:<br /><pre>
55 $routes = array();
56 foreach ($duid_arr as $entry) {
57 if(!empty($entry['ia-pd'])) {
58 $routes[$entry['ia-na']] = $entry['ia-pd'];
59 }
60 }
</pre><br />, fails, because the IPv6 address of ia-na and the IPv6 network of ia-pd lies in each (but different) entries of the $duid_arr (and not the same entry if the strings of ia-na and ia-pd had been equal - see below!)</p>
<p>This happens because:<br /><pre>
ia-na:
ia-na "\273\240\300\034\000\003\000\001\300\240\273\034\xxx\xxx" {
ia-na in hex:
BB A0 C0 1C 00 03 00 01 C0 A0 BB 1C XX XX
ia-pd:
ia-pd "\000\000\000\000\000\003\000\001\300\240\273\034\xxx\xxx" {
ia-pd in hex:
00 00 00 00 00 03 00 01 C0 A0 BB 1C XX XX
mac address of the sub-router: c0 :a0 :bb :1c :xx :xx
</pre><br />and because the start of the prefixes.php file:<br /><pre>
10 $duid_arr = array();
11 while (( $line = fgets($fd, 4096)) !== false) {
12 // echo "$line";
13 if(preg_match("/^(ia-[np][ad])[ ]+\"(.*?)\"/i", $line, $duidmatch)) {
14 $type = $duidmatch[1];
15 $duid = $duidmatch[2];
16 continue;
17 }
</pre><br />, stores the entire octet strings into $duid instead of e.g. only the "real" duid part meaning excluding the first 4 octets. Well the DUID in this example is a type 3 (DUID-LL).</p>
<p>Question 1 is why this difference? I do not have a clue e.g. if it is the dhcp6 server or the client (the D-Link sub-router) that makes the alternative ia-na string compared to the ia-pd string, but if we look at the MAC address:<br /><pre>
c0 :a0 :bb :1c :xx :xx <-- MAC
c0 :a0 :bb :1c <-- First 4 blocks of MAC
BB A0 C0 1C <-- two blocks (first and third) switch places
BB A0 C0 1C == \273\240\300\034\ <-- start/first 4 octets of the ia-na string.
</pre><br />Question 2: Are the possible solutions to fix prefixes.php (line 13 and line 15) by either:<br />1) taking a part of the ia-na string and ia-pd string that corresponds to the DUID and remove(/leave out) the first 4 blocks (1 block => \xxx) or<br />2) forcing the first 4 blocks zeroed out (\000) or<br />3) do and verify what the dhcpv6 service or my D-Link sub-router does?</p>
<p>I just guess it has nothing to do with RFC6355 ( <a class="external" href="http://tools.ietf.org/html/rfc6355">http://tools.ietf.org/html/rfc6355</a> ), but "just" RFC3315 ( <a class="external" href="http://tools.ietf.org/html/rfc3315">http://tools.ietf.org/html/rfc3315</a> ) combined with some ISC DHCPv6 stuff and/or the D-Link stuff of which I have no understanding.</p> pfSense - Bug #3364 (Resolved): DHCPv6 "Deny unknown clients" does not workhttps://redmine.pfsense.org/issues/33642013-12-15T00:12:57ZAnders Lindanders.lind@gmail.com
<p>While experimenting with IPv6 I noticed that the "Deny unknown clients" option in "Services - DHCPv6 server" does not work.<br />I have not defined any entries in the table "DHCPv6 Static Mappings for this interface", but yet it happens.</p>
<p>New DHCPv6 leases pops up in "Status - DHCPv6 leases" even though "Deny unknown clients" has been enabled and the configuration has been saved (and Status - Filter Reload Status - Reload Filter button has been clicked) in advance.</p>
<p>I have also mentioned this issue in <a class="external" href="http://forum.pfsense.org/index.php/topic,69348.0.html">http://forum.pfsense.org/index.php/topic,69348.0.html</a></p> pfSense Packages - Bug #3363 (Needs Patch): TinyDNS does not respond to IPv6 subnethttps://redmine.pfsense.org/issues/33632013-12-14T23:24:05ZAnders Lindanders.lind@gmail.com
<p>TinyDNS seems not respond to IPv6 addresses when trying DNS Server - Settings - Respond to IP.<br />I have tried to make TinyDNS respond to fe80 (and fe80::) as well as addresses with global scope.<br />It might be easy to overlook this issue, but if you run a single stack of IPv6 you are in trouble.</p>
<p>(I have also tried to reboot the router since TinyDNS in other regards (like e.g. adding an A record) seems to return strange result on DNS queries if one just tried to restart the TinyDNS server)</p>
<p>jeffbrl seems to have a somewhat equal experience <a class="external" href="http://forum.pfsense.org/index.php/topic,67917.msg372360.html#msg372360">http://forum.pfsense.org/index.php/topic,67917.msg372360.html#msg372360</a> although he talks about binding to IPv6.</p>