We now analyzed the problem with the Support of our NAC Software. It has nothing to do with V2 or V3.
The problem is, that with pfsense+ 23.05.1 all SNMP requests get delayed by the factor 3-4.

With pfsense+ 22.05, it takes between 2-3 seconds to get the status of all Interfaces from a Switch:
2205.jpg

With pfsense+ 23.05.1, its takes between 9-11 seconds to get the status of all Interfaces from a Switch:
23051.jpg

They say, that there is probably some kind of "internal QOS" delaying SNMP requests in the new firmware, or SNMP has a very low priority in some system services.
Is that the fact? Or why does the SNMP responses get such a high delay?

The base configuration of our NAC Software is 32 OIDs per request, with 30 values per response packet in the answer, with a timeout of 2 Seconds per answer. This worked without problems under 22.05.
We could make a workaround for our NAC Software. We had to set it to 1 OID, with 8 values per packet and a timeout of 10 seconds. SNMP is working with this config again, but as I said above, with a delay factor of 3-4 compared to pfsense 22.05.

@jimp
It's work fine!
Many thanks!

https://redmine.pfsense.org/issues/13976

@keyser Here are a couple of net-snmp extend scripts as examples. The first is multi line, and the second is single line. Which to use depends upon how you want to parse on the other end. To me, multi line is simpler, but some people strongly prefer single line. To each their own.

Assuming that you name the extend "dpinger", you will find the OID at

NET-SNMP-EXTEND-MIB::nsExtendOutputFull."dpinger"
(.1.3.6.1.4.1.8072.1.3.2.3.1.2.7.100.112.105.110.103.101.114)

Enjoy.

#!/bin/sh for file in /var/run/dpinger*.sock do cat $file | awk '{print "name:"$1",latency:"$2",stddev:"$3",loss:"$4}' done #!/bin/sh for file in /var/run/dpinger*.sock do if [ "${result}" ] then result="${result}," fi new=`cat $file | awk '{print "{name:"$1",latency:"$2",stddev:"$3",loss:"$4"}" }'` result="${result}${new}" done echo "${result}"

@munzy Status > System Log >OpenVPN should be able to provide you that info.

Screenshot 2023-01-05 at 9.06.59 PM.png

@tdowers
Guess I answered my own question.
NET-SNMP MRTG pfsense============================================
So like the example someone supplied for temperatures, you do the same for the pfsense states table.
Best Practice for SNMP version with extended is version 3. This example is using version 2c for illustration.

create the shell script /root/pfsenseStsteEntries.sh:

ssh to firewall
select (8) Shell
you will be at /root
vi pfsenseStateEntries.sh
press i for insert
paste in the following

#!/bin/sh
pfctl -s info | /usr/bin/awk '/current entries/ {print $3;}'

press [escape key], then enter :wq , then press [enter key]
[esacpe key] to get out of insert mode, : is escape, w is write the file and q is quit.

then
chmod u+x pfsenseStateEntries.sh
chmod g+x pfsenseStateEntries.sh

Set it executable, and then use the line-by-line extended OID to access it.

Use the NET-SNMP package. On the Host Information tab, setup an Extended Command:

Type: extend MIB: .1.3.6.1.4.1.8072.9999 Name: pfsenseStateEntries Program: /root/pfsenseStateEntries.sh Arguments: [none required for the script]

Then snmpwalk the mib to see all the values. Identify the values you need in MRTG.

tdowers@gemini:~$ snmpwalk -v2c -c [read community] 192.168.1.1 .1.3.6.1.4.1.8072.9999
iso.3.6.1.4.1.8072.9999.1.0 = INTEGER: 2
iso.3.6.1.4.1.8072.9999.2.1.2.8.103.101.116.116.101.109.112.115 = STRING: "/root/gettemps.sh"
iso.3.6.1.4.1.8072.9999.2.1.2.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = STRING: "/root/pfsenseStateEntries.sh"
iso.3.6.1.4.1.8072.9999.2.1.3.8.103.101.116.116.101.109.112.115 = ""
iso.3.6.1.4.1.8072.9999.2.1.3.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = ""
iso.3.6.1.4.1.8072.9999.2.1.4.8.103.101.116.116.101.109.112.115 = ""
iso.3.6.1.4.1.8072.9999.2.1.4.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = ""
iso.3.6.1.4.1.8072.9999.2.1.5.8.103.101.116.116.101.109.112.115 = INTEGER: 5
iso.3.6.1.4.1.8072.9999.2.1.5.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = INTEGER: 5
iso.3.6.1.4.1.8072.9999.2.1.6.8.103.101.116.116.101.109.112.115 = INTEGER: 1
iso.3.6.1.4.1.8072.9999.2.1.6.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = INTEGER: 1
iso.3.6.1.4.1.8072.9999.2.1.7.8.103.101.116.116.101.109.112.115 = INTEGER: 1
iso.3.6.1.4.1.8072.9999.2.1.7.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = INTEGER: 1
iso.3.6.1.4.1.8072.9999.2.1.20.8.103.101.116.116.101.109.112.115 = INTEGER: 4
iso.3.6.1.4.1.8072.9999.2.1.20.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = INTEGER: 4
iso.3.6.1.4.1.8072.9999.2.1.21.8.103.101.116.116.101.109.112.115 = INTEGER: 1
iso.3.6.1.4.1.8072.9999.2.1.21.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = INTEGER: 1
iso.3.6.1.4.1.8072.9999.3.1.1.8.103.101.116.116.101.109.112.115 = STRING: "28.0"
iso.3.6.1.4.1.8072.9999.3.1.1.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = STRING: "410"
iso.3.6.1.4.1.8072.9999.3.1.2.8.103.101.116.116.101.109.112.115 = STRING: "28.0
25.0
27.0
28.0"
iso.3.6.1.4.1.8072.9999.3.1.2.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = STRING: "410"
iso.3.6.1.4.1.8072.9999.3.1.3.8.103.101.116.116.101.109.112.115 = INTEGER: 4
iso.3.6.1.4.1.8072.9999.3.1.3.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = INTEGER: 1
iso.3.6.1.4.1.8072.9999.3.1.4.8.103.101.116.116.101.109.112.115 = INTEGER: 0
iso.3.6.1.4.1.8072.9999.3.1.4.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115 = INTEGER: 0
iso.3.6.1.4.1.8072.9999.4.1.2.8.103.101.116.116.101.109.112.115.1 = STRING: "28.0"
iso.3.6.1.4.1.8072.9999.4.1.2.8.103.101.116.116.101.109.112.115.2 = STRING: "25.0"
iso.3.6.1.4.1.8072.9999.4.1.2.8.103.101.116.116.101.109.112.115.3 = STRING: "27.0"
iso.3.6.1.4.1.8072.9999.4.1.2.8.103.101.116.116.101.109.112.115.4 = STRING: "28.0"
iso.3.6.1.4.1.8072.9999.4.1.2.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115.1 = STRING: "410"

MRTG cfg file entries:

Target[192.168.1.1.sessions]: .1.3.6.1.4.1.8072.9999.4.1.2.19.112.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115.1&.1.3.6.1.4.1.8072.9999.4.1.2.19.1
12.102.115.101.110.115.101.83.116.97.116.101.69.110.116.114.105.101.115.1:[read community]@192.168.1.1
SetEnv[192.168.1.1.sessions]: MRTG_INT_DESCR="States - Sessions"
MaxBytes[192.168.1.1.sessions]: 100000
Background[192.168.1.1.sessions]: #738AA6
AbsMax[192.168.1.1.sessions]: 1000000
Options[192.168.1.1.sessions]: gauge, growright, nolegend, noo
Title[192.168.1.1.sessions]: Firewall Sessions
PageTop[192.168.1.1.sessions]: <H1 align="center">Sessions</H1>
YLegend[192.168.1.1.sessions]: sessions 192.168.1.1.sessions
LegendI[192.168.1.1.sessions]: sessions:&nbsp
LegendO[192.168.1.1.sessions]: sessions:&nbsp
ShortLegend[192.168.1.1.sessions]: Count

@viragomann I thought that initially but it would reflect it in the system, too.

@RedSock if you go to Diagnostics -> System Activity what's using all the RAM? If it is pcscd then that bug has patches that will fix it for 2.5.2, or you can upgrade to 2.6-RELEASE and it will be fixed there.

For posterity, I may have solved this issue.

What I am finding is that relying on the default values in the net-snmp daemon's configuration gui for interface binding does not work well. It's possible that the default behavior is to bind to a loopback adapter or something of that nature.

Specifying my router's ip address in its management vlan and port number resolves the issue.

@jimp P.S. BTW what system for real-time Monitoring You use for 5-10G pfSense device?

@jimp thank you I thought that might of been the case. The tool I am using isn't a proper network management it was more informational on home automation.