On Thu, Jun 24, 2004 at 01:36:44PM +0100, Dave Shield wrote:
> I'm not quite sure where you got that idea from, Robert.
> I'd also prefer to see an indication that this is a CVS-based version
> of the code.
I fully agree. The first thing I do after running cvs update is to patch
snmp_version to sa
Thomas> BTW, shouldn't snmplib/snmp_version.c in CVS MAIN now have
Thomas> const char *NetSnmpVersionInfo = "5.2";
Robert> I'd actually prefer something that indicated cvs,
Robert> too: "5.2.0-cvs", or "pre-5.2.0-cvs".
Robert> The other developers don't agree with us.
I'm not quite sure w
On Thu, 24 Jun 2004 12:37:08 +0200 Thomas wrote:
TA> Thomas Anders wrote:
TA> BTW, shouldn't snmplib/snmp_version.c in CVS MAIN now have
TA>
TA> const char *NetSnmpVersionInfo = "5.2";
TA>
TA> instead of "5.1"?
You'd think so, wouldn't you? I'd actually prefer something that indicated cvs,
t
Thomas Anders wrote:
Here's the last output from "snmpget -Dall ..." before the client gets
stuck in select():
dumpv_recv:ObjID:
SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0
trace: snmp_pdu_parse(): snmp_api.c, 4257:
dumph_recv: Value
dumpx_recv: 41 0
Martin> There are indeed some issues with the enginetime (at least in
Martin> 5.0.8 and probably still in 5.1.x). [...]
Martin> Looking at the code there also seemed
Martin> to be an overflow problem occuring after 248 days and some tests
Martin> seemed to verify this. Both large time changes and t
There are indeed some issues with the enginetime (at least in
5.0.8 and probably still in 5.1.x).
We came across a similar problem when setting the
clock with NTP for our boxes that lack a battery backed clock.
They start up in 1970 and suddenly (back to the future)
they are in 2004. Looking at the
