1
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
General Discussion / Re: How to use the entire delegated prefix for SLAAC?
« on: April 25, 2024, 08:59:51 am »
It's not about the size of the wave, it's about the motion of the ocean 
That's why I mentioned the Privacy Extension in my post. I want to randomize all address over the ocean, in this case the /56. Addresses in a /64 are regarded as coming from the same source when it comes to tracking, like a /32 in IPv4 terms. Using the full /56 would make it a little harder to track. Why waste them.
That's why I mentioned the Privacy Extension in my post. I want to randomize all address over the ocean, in this case the /56. Addresses in a /64 are regarded as coming from the same source when it comes to tracking, like a /32 in IPv4 terms. Using the full /56 would make it a little harder to track. Why waste them.
3
General Discussion / Re: How to use the entire delegated prefix for SLAAC?
« on: April 25, 2024, 08:53:08 am »
Ahh too bad 
Thanks guys!
Thanks guys!
4
General Discussion / How to use the entire delegated prefix for SLAAC?
« on: April 25, 2024, 08:47:43 am »
I have a very simple IPv6 setup. No VLANs, no prefix delegation to other routers. I request a prefix from my ISP, get a (random) ::/56 assigned and use Track Interface on the LAN-side which chops the /56 into /64s depending on the prefix id. A static /56 DHCPv6 configuration on the LAN side breaks every time I'm getting a new prefix. That's why I'm only using SLAAC via an unmanaged RA in the LAN.
Now, since I like the Privacy Extension very much, I would like to make the entire /56 available for SLAAC on the LAN side instead of just one /64. How could I do this with a non-static/stateless (redarding a specific IPv6 prefix) approach?
I already tried with 0 in "Prefix Interface Site-Level Aggregation Length" (instead of 8 ) which did not work in combination with the Track Interface option.
Now, since I like the Privacy Extension very much, I would like to make the entire /56 available for SLAAC on the LAN side instead of just one /64. How could I do this with a non-static/stateless (redarding a specific IPv6 prefix) approach?
I already tried with 0 in "Prefix Interface Site-Level Aggregation Length" (instead of 8 ) which did not work in combination with the Track Interface option.
5
24.1 Legacy Series / Solved: php-cgi hogging 100% CPU
« on: April 21, 2024, 09:29:13 am »
I had been experiencing an issue where the CPU usage spiked to 100% when accessing the OPNsense dashboard or navigating through the UI. When using the top command, I saw one or more php-cgi processes consuming close to 100% CPU and using up all available memory until they were terminated. This problem worsened over the past few weeks, and I found myself having to manually terminate the php-cgi processes frequently.
While exploring the file system, I stumbled upon the /var/lib/php/sessions directory and discovered I couldn't list its contents due to the sheer number of leftover PHP session files. These files were so abundant that they severely impacted PHP's session handling capabilities. I was unable to delete the files using rm * due to their volume. Ultimately, I had to remove the entire directory with rm -f /var/lib/php/sessions/ (it gets recreated automatically).
I traced the issue back to an unusually high value set for Session Timeout under System -> Settings -> Administration. I don't recall changing this setting to a value in the millions of minutes, it just makes no sense. I don't know how the default was changed, maybe during previous a config restore?
After deleting the session files and setting the timeout back to 240 minutes no more CPU hogging php-cgi processes!
I'm sharing this in case anyone else encounters a similar issue.
While exploring the file system, I stumbled upon the /var/lib/php/sessions directory and discovered I couldn't list its contents due to the sheer number of leftover PHP session files. These files were so abundant that they severely impacted PHP's session handling capabilities. I was unable to delete the files using rm * due to their volume. Ultimately, I had to remove the entire directory with rm -f /var/lib/php/sessions/ (it gets recreated automatically).
I traced the issue back to an unusually high value set for Session Timeout under System -> Settings -> Administration. I don't recall changing this setting to a value in the millions of minutes, it just makes no sense. I don't know how the default was changed, maybe during previous a config restore?
After deleting the session files and setting the timeout back to 240 minutes no more CPU hogging php-cgi processes!
I'm sharing this in case anyone else encounters a similar issue.
Pages: [1]