On Mon, Feb 27, 2012 at 5:35 PM, Robert Story wrote:
> On Wed, 15 Feb 2012 11:36:17 +0100 Bart wrote:
> BVA> Update: the changes that were present on the master+ntpd-fix branch
> BVA> have been committed on the v5.7 and master branches, and the
> BVA> master+ntpd-fix branch itself has been delete
On Wed, 15 Feb 2012 11:36:17 +0100 Bart wrote:
BVA> On Fri, Feb 10, 2012 at 8:46 PM, Bart Van Assche
BVA> wrote:
BVA> > In case anyone wants to help testing, I've just created a branch called
BVA> > master+ntpd-fix in the SourceForge Net-SNMP git repository. The code on
BVA> > that branch includes
On Fri, 10 Feb 2012 10:53:25 -0500 Doug wrote:
DM> Two weeks ago, one of my customers had an issue with polling their
DM> SNMPv3 devices; we have a single-process, multi-threaded poller that
DM> uses net-snmp 5.4.3
Unfortunately, the SNMPv3 code is not thread safe.
---
On Fri, Feb 10, 2012 at 8:46 PM, Bart Van Assche wrote:
> In case anyone wants to help testing, I've just created a branch called
> master+ntpd-fix in the SourceForge Net-SNMP git repository. The code on that
> branch includes the snmpEngineTime fix that was posted on this mailing list.
Update: t
On Fri, Feb 10, 2012 at 3:53 PM, Doug Manley wrote:
> In any case, I patched my net-snmp to always leave SNMP_USE_TIMES
> undefined, and I am 99% certain that my change will fix the crazy
> issues that I've been seeing. I'd be interested to see how this patch
> performs in my situation.
>
In ca
On Fri, Feb 10, 2012 at 7:16 PM, Bart Van Assche wrote:
> However, I found this in RFC 3414 (http://tools.ietf.org/html/rfc3414):
>
>When an SNMP engine is first installed, it sets its local values of
>snmpEngineBoots and snmpEngineTime to zero. If snmpEngineTime ever
>reaches its ma
On Fri, Feb 10, 2012 at 3:53 PM, Doug Manley wrote:
> After weeks of testing, we concluded this:
> 1. It had something to do with net-snmp; the memory was not getting
> clobbered by anything else.
> 2. It had something to do with the fact that we would send out a
> msgAuthoritativeEngineTime with
> On Fri, Feb 3, 2012 at 8:47 AM, Bart Van Assche wrote:
>> It is known that backwards and forwards adjustments of the system clock can
>> cause snmpd and libsnmp to behave different than documented. The patch below
>> addresses this. Because of the impact of this patch (it changes the ABI
>> some
On Sun, Feb 5, 2012 at 9:25 AM, Magnus Fromreide wrote:
> On Sun, 2012-02-05 at 08:26 +, Bart Van Assche wrote:
> > One possible approach is to use times() as a fallback instead of
> > gettimeofday() for systems that do not have CLOCK_MONOTONIC.
>
> Yes, but as I said, I do not think it is wor
On Sun, 2012-02-05 at 08:26 +, Bart Van Assche wrote:
> On Fri, Feb 3, 2012 at 9:22 PM, Magnus Fromreide
> wrote:
> * I dislike that netsnmp_get_monotonic_clock might return
>gettimeofday but I suppose that there isn't much to do
> about
>th
On Fri, Feb 3, 2012 at 9:22 PM, Magnus Fromreide wrote:
> * I dislike that netsnmp_get_monotonic_clock might return
>gettimeofday but I suppose that there isn't much to do about
>that but maybe it is possible to get a better name for the
>function? One could do heroics
On Fri, Feb 3, 2012 at 9:22 PM, Magnus Fromreide wrote:
> On Fri, 2012-02-03 at 14:47 +0100, Bart Van Assche wrote:
> > It is known that backwards and forwards adjustments of the system
> > clock can cause snmpd and libsnmp to behave different than documented.
> > The patch below addresses this. B
On Fri, 2012-02-03 at 14:47 +0100, Bart Van Assche wrote:
> It is known that backwards and forwards adjustments of the system
> clock can cause snmpd and libsnmp to behave different than documented.
> The patch below addresses this. Because of the impact of this patch
> (it changes the ABI somewhat
13 matches
Mail list logo
