PC Engines APU1D4 and SNMP

[gderf]

I have been using IOG http://www.dynw.com/iog/ for many years with all sorts of firewall appliances with good results even though the program is very dated.


When I transitioned from my old ALIX 2C3 to my new APU1D4, IOG continued on seemingly well with no changes required to its configuration.


But I found myself in an unusual situation, unusual for me that is' and now IOG is broken, and badly.


What happened is that I did an extensive amount of downloading over a fairly short period of time ~175GB in just a few hours. What I observed is that IOG no longer reported bandwidth usage accurately, and I man WAY OFF as in way too low.


From what I can tell the problem is caused by the SNMP OID counters for the network interfaces in the router are only 32bit capable, and are wrapping around and starting over from zero more than once during any one hour period for which IOG polls the counters.


In the past this was never seen because my usage patterns combined with the prior low speed capability of my internet service meant that I couldn't or didn't exceed the counters' capabilities in any one hour period for which IOG polls the counters.


What's happening now is that my internet connection is now capable of more than 125mbps and running it flat out easily wraps the SNMP OID counters for the network interfaces of the router, probably several times in any one hour period before they are polled again by IOG.


Does anyone have any solution to this?


I did do an SNMP walk of the APU1D4 and didn't spot any OIDs that referenced 64bit within their names.


Is this a limitation of the APU1D4 and/or is it a deficiency of the SNMP MIB that is within t1n1wall?

[andywhite]

I'll take a look at the snmp agent, it is an old agent and maybe doesn't support 64bit counters at all (or maybe just not compiled in).  The snmp agent is quite old and there are issues with cpu and memory reporting, but the updated agent is considerably larger , which is why it hadn't been updated, but maybe it's now a big enough problem to take that step....

[gderf]

Thanks for looking into this. I am 'evaluating' cough.... pfsense which has the 64 bit counters. It handled way too slow when I last looked at it on ALIX2C3, but is fine on APU1D4. But I would like to stick with t1n1wall as there is nothing else in pfsense I would need right now other than maybe the temperature sensor.

[Lee Sharp]

I have been looking at this too, and so far I can not find out if UCD-snmp 4.2.7.1 supports 1.3.6.1.2.1.31.1.1.1.6.1 and 1.3.6.1.2.1.31.1.1.1.10.1 at all.  And the bump is non-trivial.

[gderf]

Well, I wouldn't know either. Are there any MIBs included in the distribution somewhere? When one snmpwalks a device, what is actually being read?


What I can say is this. Taken from the iog program:



 my %oidnames = qw(ifInOctets      1.3.6.1.2.1.2.2.1.10
           ifOutOctets     1.3.6.1.2.1.2.2.1.16
                     ifHCInOctets    1.3.6.1.2.1.31.1.1.1.6
                     ifHCOutOctets   1.3.6.1.2.1.31.1.1.1.10);


This program file is dated 10/15/2003. So the use of the 64bit (HC) counters isn't a recent phenomenon.


Thanks for looking into this.

[gderf]

I looked at a copy of ucd-snmp-4.2.7.1. The file of interest may be /mibs/IF-MIB.txt


The 64bit counters are mentioned there.


Maybe that file could be back-ported or does keeping track of 64bit numbers require running on a 64bit OS?

[Lee Sharp]

I am including the link in the SmallWall SVN, but the t1n1wall file is the same.  I am also posting this on the SmallWall forum as my links are "no follow" here.

The package is here. http://svn.smallwall.org/SmallWall/freebsd8/build/local-sources/ucd-snmp-4.2.7.1.tar.gz And here... http://sourceforge.net/p/t1n1wall/code/HEAD/tree/branches/freebsd8/build/local-sources/ucd-snmp-4.2.7.1.tar.gz?format=raw

The IF-MIB.txt file is rather large, but the options are defined. But I am having trouble finding where they are turned on.   There are also patches http://svn.smallwall.org/SmallWall/freebsd8/build/patches/packages/ucd-snmp.config.h.patch and http://svn.smallwall.org/SmallWall/freebsd8/build/patches/packages/ucd-snmp.patch

Lastly, the actual build takes place in script 2 at the bottom. http://svn.smallwall.org/SmallWall/freebsd8/build/scripts/2makebinaries.sh

I am thinking the key is in the build script with this line...

Code: [Select]

        '--with-mib-modules=host mibII/interfaces mibII/var_route ucd-snmp/vmstat_freebsd2' \

[andywhite]

the snmp package contains an agent as well as utilities.  the stuff you are looking at is reference to the utilities (snmpbulkwalk etc), not the agent.

The agent uses interfaces.c to answer queries about interfaces statistics, and it doesn't support the HC counters.

64 bit counters for Freebsd was first put into net-snmp 5.4 looking at the changelog, so we would have to look at that version as a minimum

[gderf]

Ouch. I was hoping this would be easier


Any idea what the pfsense guys did and can anything there be borrowed?

[gderf]

I got the sourceforge.net email about "try net-snmp v5.7."


I am keeping an eye on the 1.8 snapshots folder for the next build and will test.

[andywhite]

you can try build 43, has net-snmp 5.7 , should give you those counters, and also fix the memory reporting issue.  cpu reporting looks fine, as does sysuptime and hrsysuptime , these are the ones that we had issues with previously....

also should support ipv6 now, but I haven't tested this yet.

[gderf]

I just grabbed the image and will upgrade my build 42 with it. Thanks. I'll report back soon.

[gderf]

1.8.2b44 has the capabilities I was asking for.


Thanks Andy!