On Tue, 2010-03-23 at 20:53 +0100, Bart Van Assche wrote:
> Hello,
>
> Currently the behavior with regard to AgentX over TCP is as follows:
>
> snmpd -x tcp: listens to *:705 (!)
> agentxtrap -x tcp: connects to 0.0.0.0:705
>
> The patch below changes the AgentX over TCP behavior into:
>
> snmp
Dave Shield wrote:
> 1) Latch disk statistics: no / 54x only / both 54x and 52x
> 2) Missing privKey crash: no / 54x only / both 54x and 52x
> 3) VACM best match: no / 54x only / both 54x and 52x
> 4) MIB dir path logging: no / 54x only / both 54x and 52x
+1 for 1), 2), 3): both 54x and
Bart Van Assche wrote:
> Since the 5.4 branch is currently in release-candidate freeze mode,
> this patch has to be voted upon before it can be applied to the 5.4
> branch. Please vote whether or not you want to see this patch applied
> on the 5.4 branch.
+1
+Thomas
On Tue, 23 Mar 2010 20:53:32 +0100 Bart wrote:
BVA> Hello,
BVA>
BVA> Currently the behavior with regard to AgentX over TCP is as follows:
BVA>
BVA> snmpd -x tcp: listens to *:705 (!)
BVA> agentxtrap -x tcp: connects to 0.0.0.0:705
BVA>
BVA> The patch below changes the AgentX over TCP behavior in
On Wed, Mar 17, 2010 at 10:09 AM, Dave Shield
wrote:
> I've had a quick look at the code for winExtDLL.c
> (in response to bug #2971257), and there's something
> that confuses (/concerns) me.
>
> Within the var_winExtDLL handler, there's the usual
> (for request = requests; request; request =
Hello,
Currently the behavior with regard to AgentX over TCP is as follows:
snmpd -x tcp: listens to *:705 (!)
agentxtrap -x tcp: connects to 0.0.0.0:705
The patch below changes the AgentX over TCP behavior into:
snmpd -x tcp: listens to localhost:705
agentxtrap -x tcp: connects to localhost:70
On Mon, Mar 22, 2010 at 4:54 PM, Dave Shield wrote:
> Please find attached four proposed patches, which could potentially be
> applied to the 5.4.x (and 5.2.x) lines. We're currently in release-freeze
> for both of these branches, so could people please indicate whether or
> not they would like
On Tue, Mar 23, 2010 at 1:27 PM, Dave Shield wrote:
> On 23 March 2010 11:44, Bart Van Assche wrote:
> > Personally I consider the fact that the patch does not have the same
> effect
> > on 32-bit systems as on 64-bit systems as a flaw.
> >
> > There is yet another shortcoming in the patch that I
On 23 March 2010 13:15, Fatima Peter wrote:
> .. My understanding of the mask is "1 means that the oid
> tree is in view and "0" means not in view. Another colleague told me
> that "1" means that we need an exact match and "0" means the view does
> not care about the "oid" tree.
See RFC 3415,
On Tue, 23 Mar 2010 15:08:43 +0900 (KST) 생각하기 wrote:
> fan.o: In function `handle_Fm2rpms':
> fan.c:(.text+0x0): multiple definition of `handle_Fm2rpms'
> agentx.o:agentx.c:(.text+0x2190): first defined here
seems like you've got lots of code duplicated in fan.c and agentx.c.
> /usr/bin/ld: skipp
On Mon, 22 Mar 2010 15:54:56 + Dave wrote:
DS> 2) Missing privKey crash: no / 54x only / both 54x and 52x
This is a protocol bug that affects all platforms, so I vote both 54x and 52x
DS> 3) VACM best match: no / 54x only / both 54x and 52x
This is a protocol bug that affects all platf
Hi Dave,
Thanks for the input. I didn't know what "rocommunity global" does
and I will try retesting with rocommunity removed and post the
results.
But, it does not look like the results match the function of "vacm
mask", isn't it. My understanding of the mask is "1 means that the oid
tree is i
On 23 March 2010 11:44, Bart Van Assche wrote:
> Personally I consider the fact that the patch does not have the same effect
> on 32-bit systems as on 64-bit systems as a flaw.
>
> There is yet another shortcoming in the patch that I hadn't mentioned yet:
> limiting values to 0x7fff introduces
On Tue, Mar 23, 2010 at 10:34 AM, Dave Shield
wrote:
> On 22 March 2010 18:46, Bart Van Assche wrote:
> > How well have these patches been tested, and on which platforms ?
>
> The first three were in response to queries on the mailing list.
> I've tested (2) and (3) myself (on Fedora), and recei
On 22 March 2010 15:20, Fatima Peter wrote:
> # sec.name source community
> com2sec test1 10.10.0.0/16 global
>
> rocommunity global
If you are running view tests using the community name "global",
then it's not really sensible to configure full access for this
community st
On 22 March 2010 18:46, Bart Van Assche wrote:
> How well have these patches been tested, and on which platforms ?
The first three were in response to queries on the mailing list.
I've tested (2) and (3) myself (on Fedora), and received
positive feedback from the original posters.
(4) has also
16 matches
Mail list logo
