>
> Hmm, the current CVS seems to have a few problems.
> One I think is sorting related with the actual stored data:
>
Not so... It's a well known "problem" ;-) .
> (cairo 192.168.0.14, rio 192.168.0.12)
>
> ./test.snmp
> ...
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.192.168.0.14 = STRING:
> "ipv4.cairo.treenetnz.com"
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.192.168.0.12 = STRING:
> "rio.treenetnz.com"
> Error: OID not increasing:
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.192.168.0.14
>
> >= SNMPv2-SMI::enterprises.3495.1.5.1.1.1.192.168.0.12
>
To solve this, apply the flag "-Cc" to the snmpwalk script on test.snmpd.
man snmpwalk.
-Cc Do not check whether the returned OIDs are increasing. Some
agents (LaserJets are an example) return OIDs out of order, but
can complete the walk anyway. Other agents return OIDs that
are out of order and can cause snmpwalk to loop indefinitely.
By default, snmpwalk tries to detect this behavior and warns
you when it hits an agent acting illegally. Use -Cc to turn
off this check.
Squid is not returning OIDs increasing because the peer table is not ordered
as expected according to IP ( I guess it adds peers as it find them on
squid.conf . FIXME IPv6 ? ).
For the time beeing, you can
* either reverse order ....
( rio 192.168.0.12, cairo 192.168.0.14)
* apply the "-Cc" flag to snmpwalk .
I guess the cache_peer on IPv6 does not work yet.
Thanks for testing.
