On Wed, 31 Mar 2010 09:11:25 +0100 Dave wrote:
DS> Is this ever going to happen?
DS> The value 'multiplier' is based on either 'f_bsize' or 'f_frsize'
DS> (scaled from bytes to kB)
DS>Are either of these ever going to be zero?
DS>
DS> If so, the underlying system is probably fundamentally brok
On 30 March 2010 20:32, Magnus Fromreide wrote:
> a) It won't compile due to
>
> if (x < (y / z)
Argghhh!!!
Thanks.
> b) I would probably prefer the following since it makes sense to use
> a well known name and this define is located in an implementation
> file.
>
> #ifndef INT32_MAX
>
On 31 March 2010 07:49, Bart Van Assche wrote:
> The code in the patch you posted will trigger a division by zero when
> multiplier == 0.
Is this ever going to happen?
The value 'multiplier' is based on either 'f_bsize' or 'f_frsize'
(scaled from bytes to kB)
Are either of these ever going to
On Tue, Mar 30, 2010 at 2:07 PM, Dave Shield wrote:
> [ ... ]
>
> In response to these comments, I've drafted a revised version
> of this patch (attached), which uses the comparison code
> structure that you suggest.
> It also uses INT32_MAX where available (but doesn't rely
> on this necessaril
On Tue, 2010-03-30 at 13:07 +0100, Dave Shield wrote:
> On 24 March 2010 07:56, Magnus Fromreide wrote:
> >> 1) Latch disk statistics: no / 54x only / both 54x and 52x
> >
> > both -1
> >
> > Adds warnings about silly compares on 32 bit platforms.
> > Adds magic constant instead of using INT32_M
On 24 March 2010 07:56, Magnus Fromreide wrote:
>> 1) Latch disk statistics: no / 54x only / both 54x and 52x
>
> both -1
>
> Adds warnings about silly compares on 32 bit platforms.
> Adds magic constant instead of using INT32_MAX
> Works differently on 32 and 64 bit if the multiplication above
On 03/22/2010 04:54 PM, Dave Shield wrote:
> 1) Latch disk statistics (disk-latch.patch)
+1 both
> 2) Missing privKey crash (des-priv.patch)
+1 both
> 3) VACM best match(vacm-best-match.patch)
0
> 4) MIB dir path logging (mibdir-log.patch)
0
Jan
---
On 23 March 2010 19:53, Bart Van Assche wrote:
> The patch below changes the AgentX over TCP behavior into:
>
> snmpd -x tcp: listens to localhost:705
> agentxtrap -x tcp: connects to localhost:705
>
> Since the 5.4 branch is currently in release-candidate freeze mode,
> this patch has to be voted
On Mon, 2010-03-22 at 15:54 +, Dave Shield wrote:
> On 21 March 2010 08:45, Dave Shield wrote:
> > On 20 March 2010 15:13, Robert Story wrote:
> >> Dave, have any other issues come up that might warrant a rc2?
> >
> > I've got a list of three or four possible patches sitting on my desk at
>
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
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 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
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 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
On Mon, Mar 22, 2010 at 4:54 PM, Dave Shield wrote:
> On 21 March 2010 08:45, Dave Shield wrote:
> > On 20 March 2010 15:13, Robert Story wrote:
> >> Dave, have any other issues come up that might warrant a rc2?
> >
> > I've got a list of three or four possible patches sitting on my desk at
> wo
On 21 March 2010 08:45, Dave Shield wrote:
> On 20 March 2010 15:13, Robert Story wrote:
>> Dave, have any other issues come up that might warrant a rc2?
>
> I've got a list of three or four possible patches sitting on my desk at work.
> I'll send out a CFV tomorrow.
Please find attached four p
On 20 March 2010 15:13, Robert Story wrote:
> Dave, have any other issues come up that might warrant a rc2?
I've got a list of three or four possible patches sitting on my desk at work.
I'll send out a CFV tomorrow.
Dave
--
> Note the security implications, so I think tihs should be backported to 5.5 as
> well. (In 4.4 I think the fallback code to tcp was missing so it is not needed
> due to security there but the nicer properties when connecting to a socket
> makes it worthwile).
I have checked and the fallback to
On Fri, 19 Mar 2010 14:01:38 +0100 Thomas wrote:
TA> Bart Van Assche wrote:
TA> > I'm not sure it's OK to change the V5.4 behavior now since the 5.4
TA> > branch is in RC stage (see also
TA> > http://net-snmp.sourceforge.net/dev/release-policy.html).
TA>
TA> Feel free to call for votes.
Dave, hav
Bart Van Assche wrote:
> I'm not sure it's OK to change the V5.4 behavior now since the 5.4
> branch is in RC stage (see also
> http://net-snmp.sourceforge.net/dev/release-policy.html).
Feel free to call for votes.
+Thomas
On Fri, Mar 19, 2010 at 8:24 AM, Thomas Anders
wrote:
> Magnus Fromreide wrote:
> > This patch is something I think should be applied overall as it will
> affect
> > the default tcp host for master agents on unices as well and make it more
> > likely that it just works for subagents since they wil
Magnus Fromreide wrote:
> This patch is something I think should be applied overall as it will affect
> the default tcp host for master agents on unices as well and make it more
> likely that it just works for subagents since they will try to connect to
> localhost by default.
Given the insecure n
"localhost:705". The
> patch below overcomes this, but at the same time changes the default AgentX
> target socket from ":705" (any interface) to "localhost:705". Is this
> acceptab
he default AgentX
target socket from ":705" (any interface) to "localhost:705". Is this
acceptable ?
Index: agent/mibgroup/agentx/agentx_config.c
===
--- agent/mibgroup/agentx/agentx_config.c (revision 18
30 matches
Mail list logo
