IPv6 testing
-
Just tried getting my pfSense box to work again. Something is seriously wrong with the releases. When I take the RC1 IPv6 i386 image of the 1st of March it installs well on clean system. When I restore my config I get an error during boot time that my config is from a newer version and I should urgently upgrade. When I just do a gitsync on this version, the whole IPv6 support is gone right after the gitsync as reported earlier. When I do a full firmware update + gitsync + reboot, IPv6 is still gone. When I take the 22nd of March RC1 IPv6 i386 image and clean install that, it works fine after installation. When I just gitsync that, same shit.. IPv6 support is totally gone. I now took the 22nd of March RC1 IPv6 i386 release and just restored my backup without gitsyncing or firmware updating. IPv6 support is still there and no warnings during boot time. I wonder if this brings back stability.
Funny thing is that I have two other pfSense boxes running which I haven't updated (either gitsync or firmware update) for about a month (both RC1 non IPv6 release gitsynced with IPv6 support) and they run smoothly and without any problems with both IPv4 and IPv6. I also didn't have any problems with my 3rd pfSense box which I do update frequently against the latest firmware and gitsyncs since about two weeks ago. So the problems seems to be introduced in changes made in the last month and most likely in the past two weeks. I hope the developers are able to find the cause. I am using IPSec tunnels but am not using Intel NICs by the way.
@Databeestje, I'll be happy to take a look at the JavaScript. How can I do this? Does it require gitsyncing with the latest version and then just checking out the source of the page? If so, I'll set up a new testbox first so it will not disrupt my pfSense home internet router.
-
I'm using the pfSense 2.0-RC1 binary release and then gitsynced my branch over it. It's been working well over the last month.
-
That's weird. There's not much that one can be doing wrong with a clean install. Do you recon there's something in my configuration that I keep restoring that ruins the setup after gitsyncing?
-
I've been using the gitsync method since I started developing in october or so. It just works. Not sure what you are doing that fails to perform this step.
If you end up with a tree without v6 bits you are syncing the wrong tree, this could be script failing but it has absolutely nothing to do with the git tree.
-
I believe you that it all should work fine. Just trying to find out what I can be doing wrong. This is exactly what I do:
1. Burn the pfSense-2.0-RC1-IPv6-i386-20110321-2139.iso.gz image to CD
2. Insert the CD into my old Compaq P3 800 Mhz PC that functions as my home router
3. Reboot the machine from the console menu
4. The system boots from the CD and when it asks me if I want to install, recover or boot normally I choose install.
5. In the setup screen I accept the default keyboard, vga, etc.
6. In the next screen I choose easy setup and let the installer do its thing and copy the files
7. When it's ready, it will reboot and I will remove the CD from the drive
8. Once booted, I choose not to assign VLANs and I assign the WAN and LAN to my nics
9. I choose to assign the proper private IP address to my LAN facing NIC, disable DHCP and revert to HTTP for web access all using the second menu option in the console
10. I use Firefox to browse to the webinterface of the pfSense installation and choose to restore the config from my backed up XML file
11. In the console I use option 12 and enter playback gitsync. It downloads and installs the gitsync software addons and starts gitsyncing with the tree as defined on your tutorial page. No errors, no problems during the update. It returns to the console menu and the IPv6 addresses are gone.What am I doing wrong?
-
What am I doing wrong?
I would guess you should do your step 11 before your step 10 on the grounds you probably need to have the system "IPv6 aware" before you try to import IPv6 configuration items.
-
Thanks for the advice, do note though that I'm using the IPv6 RC1 image from Databeestje which is IPv6 aware "out of the box". The only thing I can think of is that the error is caused by my config.
The reinstall I did this morning is still up and running by the way.
-
Wishful thinking unfortunately. It has crashed three times again today. And people say Microsoft stuff tends to hang :P It just showed me the following at the console screen when it got stuck. I noticed its mentioning nge0 which is my lan facing NIC. Can I assume the problems are caused by my NIC? Its not an Intel. Not sure which brand it is, but appearantly not only Intel is causing trouble. The WAN facing NIC is the exact same type. And again they worked without any hassle for a couple of months until two weeks ago :( I'm going to put together another system tomorrow with different NICs to see if that finally solves this instability.
-
do note though that I'm using the IPv6 RC1 image from Databeestje which is IPv6 aware "out of the box".
Sorry I didn't pick that up. Maybe something in the "config import" is not fully IPv6 aware. Where does this backup config file come from? Maybe pfSense thinks it need to do a version conversion on import and that is not fully IPv6 aware.
Have you tried copying your backup config file directly to /cf/conf/config.xml (not a restore through web GUI) and rebooting?
-
Can I assume the problems are caused by my NIC?
Its possible but not certain. The NIC driver (nge) might just be the place where a far earlier "corruption" manifested.
If you have this happen again please type bt at the db> prompt. This will cause the kernel debugger to display a stack trace which will provide at least a little more information about what was going on in the system leading up to the trap.
-
When I restore my config I get an error during boot time that my config is from a newer version and I should urgently upgrade.
Please post the first three lines from the configuration file you are restoring. This should show the version number. For example, on my system:
more /cf/conf/config.xml
<pfsense><version>7.9</version></pfsense>
Are you certain the configuration file you are restoring contains IPv6 information? Have you searched it for ipaddrv6 tags (for example)?
-
Thanks for your help wallabybob. The first lines of my saved config file also show version 7.9 here. I'm restoring my backup from an earlier made config file when all was still working fine on the same system. The XML does show several ipaddrv6 XML nodes. I'll type the bt command next time I catch it being stuck. Currently it just spontaneously seems to reboot every approxemately 20 minutes instead of getting stuck at that screen.
-
It seems like I'm having a clear moment today after some time. I must apologize to you guys. I believe I have found the cause of the IPv6 settings being gone after a gitsync and I must admit you guys were right all along. Amazing how often I have been reading and checking the gitsync URL and each and every time did not notice the mainline at the end of the URL :-[ I just gitsynced using the right pfSense-smos.git master branch and the IPv6 settings are still there ;D
The clear moment today also brought up in my mind that about two weeks ago I have added the BandwidthD package to my pfSense box which is causing the problems. I kind of get the impression that it crashes when large amounts of data are transfered so 1 + 1 might be two in this case and I removed BandwidthD. Let's see if this solves the mistery.
Sorry again for being so ignorant :-\
As for the last IPv6 smos gitsync, I notice there's an option Operating Mode on the DHCPv6 page. @Databeestje, care to explain its functionality in short?
-
On system_services_dhcpv6.php there is a javascript message that should disable all dhcp fields when disabling DHCP or when it's set to "unmanaged". I failed to get this javascript check working. Perhaps you can have a look @Koen.
@Databeestje, I also had a look at the JavaScript rightaway now I got the latest version working again. Easy one. Update the JavaScript method to:
function enable_change(disableFields) {
document.iform.range_from.disabled = disableFields;
document.iform.range_to.disabled = disableFields;
document.iform.dns1.disabled = disableFields;
document.iform.dns2.disabled =disableFields;
document.iform.deftime.disabled = disableFields;
document.iform.maxtime.disabled = disableFields;
document.iform.gateway.disabled = disableFields;
document.iform.failover_peerip.disabled = disableFields;
document.iform.domain.disabled = disableFields;
document.iform.domainsearchlist.disabled = disableFields;
document.iform.staticarp.disabled = disableFields;
document.iform.ddnsdomain.disabled = disableFields;
document.iform.ddnsupdate.disabled = disableFields;
document.iform.ntp1.disabled = disableFields;
document.iform.ntp2.disabled = disableFields;
document.iform.tftp.disabled = disableFields;
document.iform.ldap.disabled = disableFields;
document.iform.netboot.disabled = disableFields;
document.iform.nextserver.disabled = disableFields;
document.iform.filename.disabled = disableFields;
document.iform.rootpath.disabled = disableFields;
document.iform.denyunknown.disabled = disableFields;
}And update the HTML of the dropdownlist to:
<select id="mode" name="mode" onchange="enable_change(this.value=='unmanaged');"> <option value="unmanaged">Unmanaged</option> <option value="managed">Managed</option> <option value="assist">Assisted</option></select>
You did have a text included within the <select>tag which was incorrectly put there and therefore not being displayed. Move it out of the</select> tag:
Select the Operating Mode. Use Unmanaged for Router Advertising only, Managed for DHCPv6 only, Assisted for Combined
I guess this text also answers my previous question to elaborate on this function ;)
Furthermore, change the HTML of the checkbox to:
That should fix it.
-
Code committed, the toggle does not appear to work entirely right.
-
It's wrong indeed. Difficult to write JavaSript without being able to test it directly :)
Change the JavaScript function to:
function enable_change() {
var disableFields = (document.iform.mode.value=='unmanaged' || !document.iform.enable.checked);
document.iform.range_from.disabled = disableFields;
document.iform.range_to.disabled = disableFields;
document.iform.dns1.disabled = disableFields;
document.iform.dns2.disabled =disableFields;
document.iform.deftime.disabled = disableFields;
document.iform.maxtime.disabled = disableFields;
document.iform.gateway.disabled = disableFields;
document.iform.failover_peerip.disabled = disableFields;
document.iform.domain.disabled = disableFields;
document.iform.domainsearchlist.disabled = disableFields;
document.iform.staticarp.disabled = disableFields;
document.iform.ddnsdomain.disabled = disableFields;
document.iform.ddnsupdate.disabled = disableFields;
document.iform.ntp1.disabled = disableFields;
document.iform.ntp2.disabled = disableFields;
document.iform.tftp.disabled = disableFields;
document.iform.ldap.disabled = disableFields;
document.iform.netboot.disabled = disableFields;
document.iform.nextserver.disabled = disableFields;
document.iform.filename.disabled = disableFields;
document.iform.rootpath.disabled = disableFields;
document.iform.denyunknown.disabled = disableFields;
}Change the dropdownlist HTML to:
<select id="mode" name="mode" onchange="enable_change();"> <option value="unmanaged">Unmanaged</option> <option value="managed">Managed</option> <option value="assist">Assisted</option></select>
And change the HTML of the checkbox to:
-
I see its working now :) Nice. Probably needless to say, but when using disabled on fields like this remember that the values from those fields are not sent in the HTTP Post header if the fields are disabled. Also remember that setting disabled on fields provides no guarantees that the fields will remain disabled and thus the values will not be submitted. One could easily override the JavaScript since its client side script and enable the field again. Therefore server side validation for the checkbox is also required.
My pfsense box without BandwidthD is still crashing and automatically rebooting every hour or so. Also no luck yet with getting DHCPv6 to hand out leases to my clients. Guess its time to build up another system and give pfSense a try on that one.
-
Looks like the latest update is causing a problem with reloading the pf rules:
Mar 26 02:28:31 php: : Start Configuration upgrade at 02:28:31, set execution timeout to 15 minutes
Mar 26 02:28:33 php: : The command '/sbin/pfctl -o basic -f /tmp/rules.debug' returned exit code '1', the output was '/tmp/rules.debug:190: syntax error /tmp/rules.debug:191: syntax error pfctl: Syntax error in config file: pf rules not loaded'
Mar 26 02:28:33 php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:190: syntax error /tmp/rules.debug:191: syntax error pfctl: Syntax error in config file: pf rules not loaded The line in question reads [190]: pass in quick on $AIR_GUEST inet6 proto { tcp udp } from any to any divert 56262 keep state ( ) label "USER_RULE"
Mar 26 02:28:33 php: : There were error(s) loading the rules: /tmp/rules.debug:190: syntax error /tmp/rules.debug:191: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [190]: pass in quick on $AIR_GUEST inet6 proto { tcp udp } from any to any divert 56262 keep state ( ) label "USER_RULE""AIR_GUEST" is the name of my guest WLAN interface.
-
Looks like it has a problem with the traffic shaper, specifically Layer 7. Whenever I enable a layer 7 container it complains about the syntax error.
I wonder if it's specific to the IPv6 branch?
-
i had the same issue but i dont think its related to the ipv6 code… re-save rules and layer7 container... see if that helps.. it did for me