System Advanced >Networking
-
What do you have 'DHCP6 DUID' set to on that page? Was that setting something you changed previously?
-
@gawd21 said in System Advanced >Networking:
I wonder if I just put in come commented out text in the file if it will correct the issue.
It would prevent the immediate error, but may cause grief further down in the code someplace. I'm not an IPv6 expert, but I believe that file is supposed to contain the default DUID for your firewall. I looked at mine and it contains binary characters as they do not display properly in the DIAGNOSTICS > EDIT FILE menu option.
-
@stephenw10
I had just unchecked it a while back. I can't remember the layout of the page, but I am sure it had a check box that all ipv6 will be disabled if unchecked. However, I haven't made any changes on that page since maybe June. I am thinking the issues occurred when I restored the backup, on the 15th. -
Yes it should be populated. But since it exists it's checking it. Feels like it might not be referencing it, the DUID setting set to something other than default, and it should have been removed?
-
@bmeeks
Well that would cut off my next question. LOL I was going to see if I could get the code, however, it may contain private info, so wouldn't be a good idea for anyone to share the file, plus different configs and all. -
By default it references that file like this:
-
@bmeeks said in System Advanced >Networking:
On your system that file is either missing or empty.
It exists and is empty.
If it was missing, the first test, file_exists("{$g['vardb_path']}/dhcp6c_duid") would fail.Btw : This is mine : 16 bytes - so less then 132.
I have IPv6 activated on WAN and LAN, and using IPv6 right on this forum.
The question is : what creates a empty /var/db/dhcp6c_duid file ?
Answer : it's in the same file /etc/inc/util.inc - 15 lines above :function write_dhcp6_duid($duidstring)and this function will first check if the $duidstring contains a valid duid using the fucntion is_duid() (in the same file).
function is_duid() is really throwing a maximum effort in proving that $duidstring is not a duid and it will return false if the there is a problem, like $duidstring not being a $duidstring.
If function is_duid() reurn true, then the /var/db/dhcp6c_duid file is created with the $duidstring content.
What is the time stamp of this file ? It dates from when ?
If pfSense can not create that file because there is not a valid or empty $duidstring - should it keep the file in place
or
just delete the file ?The /var/db/dhcp6c_duid is only created or updates on one place : function write_dhcp6_duid($duidstring) - I can't see how this function can create an empty file.
I vote for : just wipe the zero length file /var/db/dhcp6c_duid and call it a day.
Note to myself : who is this dude ?
-
@stephenw10
I put this in and it allowed me to access the page./* ignore this test */However, it just shows the -:-: and none of the numbers like yours.
-
Yup what is coming from that file and yours is empty.
I agree, try deleting the file and see if it's regenerated.
-
@stephenw10 I deleted it. Waiting to reboot.
-
File was not created on reboot.
-
It wasn't created on reboot, and I just noticed that /var/dhcpd/var/db/dhcpd6.leases is also a zeroed out file. I wonder if I have a bad stick of RAM.
-
And that removed the error I assume?
Any guess what combination of settings created that file without content? I'll try to replicate it.
-
It's not the file that is zeroed out, the /var/dhcpd/var/db/dhcpd6.leases is too.
It maybe bad RAM.
I was having a bunch of problems with multicast working and I am sure that I changed something that I shouldn't have, in my frustration and after hours of messing with it, my network started to fall apart as in I couldn't communicate with other lans and everything was going very slowly, even loading the diag page too seconds, so I said the hell with it and restored my backup from right after the update to 23.05.01, that was on the 15th. Yesterday/early this morning, I say IPv6 traffic and I went to go check the networking page to make sure it was off and that is when I found the error.Yes, the error is gone now.
-
-
@gawd21 said in System Advanced >Networking:
/var/dhcpd/var/db/dhcpd6.leases is also a zeroed out file
That's another animal.
Created by the DHCP IPv6 server, who servers IPv6 leases on your LANs for the devices that want to do IPv6 networking.Again : what is the time stamp of the file ?
Maybe you had the DHCP v6 servers active on your LANs in the past ?You can delete this file.
This file is a scrath pad for the DHCP v6 server process, so it knows, even after a power down, and power up, what device had what lease when.
And it permits to show in the GUI all the DHCPv6 leases handed out. -
-
Oh, joy. just found this minor issue. However, I am tired and I need to take a break from sitting here for a bit. Been sitting here for going on 11 hours.
Crash report begins. Anonymous machine information: amd64 14.0-CURRENT FreeBSD 14.0-CURRENT #1 plus-RELENG_23_05_1-n256108-459fc493a87: Wed Jun 28 04:26:04 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/obj/amd64/f2Em2w3l/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/sources/ Crash report details: PHP Errors: [17-Aug-2023 10:38:15 America/Kentucky/Louisville] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 218439680 bytes) in /usr/local/www/diag_edit.php on line 62 No FreeBSD crash data found. -
That's just exhausting the php process limit. Likely you accidentally tried to open a large binary file or similar. I wouldn't expect to see that again.
-
@gawd21 said in System Advanced >Networking:
Allowed memory size of 536870912 bytes exhausted (tried to allocate 218439680 bytes) in /usr/local/www/diag_edit.php on line 62
You asked the GUI to load a file that was a bit more then 218 Mbytes. The total available memory of PHP ran dry.
Use the console, or far better : the SSH access.
