Dave Shield wrote:
But I'll get the main man page documentation finished first.
I like what you did. Even so much that I'd call for comments whether to
apply similar changes to snmpd.conf(5) in 5.2.2. Anyone?
As another possible improvement: may it make sense to explicitely tell
people abou
On Mon, 14 Nov 2005 13:29:16 -0500 Robert wrote:
RS> On Mon, 14 Nov 2005 10:05:43 -0800 Fong wrote:
RS> FT> In snmp_api.c, when (transport->flags & NETSNMP_TRANSPORT_FLAG_STREAM)
RS> FT> is not true, it malloc the memory for rxbuf at line 5289. By the time,
RS> FT> rxbuf doesn't point to isp->packe
On Mon, 14 Nov 2005 19:36:13 +0100 Thomas wrote:
TA> 3-1? Dave, Wes and um.. who? If you've got the impression that *I* have
TA> voted: no, I haven't.
Ah, I took the ":-/" in your email as disapproval. And at any rate, even if
you were in favor, at 2-2, that would require 3 more yes votes from co
On Fri, 11 Nov 2005 15:50:01 +0100 Palmentieri wrote:
PN> Now, we want to port that application on a Linux environment (UCD-snmp
PN> version: 4.2.5)
4.2.5 is pretty old. Consider using a newer version.
Check the web-site for tutorials, and try mib2c to generate skeleton code for
your MIBs.
--
Robert Story wrote:
Well, color me stunned. Appears to be 3-1 against me, so I've put things back
as they were, infinite loop and all.
3-1? Dave, Wes and um.. who? If you've got the impression that *I* have
voted: no, I haven't.
+Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)
On Mon, 14 Nov 2005 10:05:43 -0800 Fong wrote:
FT> In snmp_api.c, when (transport->flags & NETSNMP_TRANSPORT_FLAG_STREAM)
FT> is not true, it malloc the memory for rxbuf at line 5289. By the time,
FT> rxbuf doesn't point to isp->packet.
FT> When transport->f_recv fails (return -1), it should free
On Mon, 14 Nov 2005 09:07:55 -0800 Wes wrote:
WH> Robert> The other options would be moving the variable into the
WH> Robert> library. Then any application that installed a signal handler
WH> Robert> and set the flag would be able to exit these loops.
WH>
WH> Robert> Thoughts?
WH>
WH> I think Dav
In snmp_api.c, when (transport->flags & NETSNMP_TRANSPORT_FLAG_STREAM)
is not true, it malloc the memory for rxbuf at line 5289. By the time,
rxbuf doesn't point to isp->packet.
When transport->f_recv fails (return -1), it should free (rxbuf) not
isp->packet, at line 5302.
-Original Message-
On Sat, 12 Nov 2005 08:50:06 -0500 George wrote:
GH> When I do snmpwalk I see a lot of IPv4 information, but I only see 10-15
GH> entries reflecting the IPV6-MIB.
GH> Also, when I do snmpget to retrieve information such as ipv6RouteDest I
GH> get an error that the object does not exist.
GH> I am c
On Fri, 11 Nov 2005 07:27:21 -0800 (PST) md wrote:
MS> I am using montavista linux2.4.18 on ixp425 platform (armv5teb).
Did you configure both versions the same way?
Do you have both versions installed at the same time? (you shouldn't)
Are there any error messages in the log files?
MS> I have
On Thu, 10 Nov 2005 13:43:50 -0800 Fong wrote:
FT> I tested on our system, not standard linux.
FT>
FT> I dig into the code and found that it frees wrong memory when it is in
FT> non- NETSNMP_TRANSPORT_FLAG_STREAM situation.
FT>
FT> It is in snmp_api.c at line:5302 on release version 5.0.10.2.
> On Sun, 13 Nov 2005 23:28:07 -0500, Sharon Gowan <[EMAIL PROTECTED]> said:
Sharon> I have been looking for a good example of using get next to
Sharon> walk a section of a mib, but it doesn't pop out at me from the
Sharon> net-snmp development web site. Can anyone on this mailing
Sharon> lis
> On Wed, 09 Nov 2005 09:58:03 +, Dave Shield <[EMAIL PROTECTED]> said:
>> But does the behaviour do what the MIB says it should?
Dave> In most cases - yes. (E.g. not generating a mteTrigger*
Dave> notification unless the mteEventNotificationTable explicitly
Dave> says to do so, whether
> On Sun, 13 Nov 2005 20:16:58 -0500, Robert Story <[EMAIL PROTECTED]> said:
Robert> The other options would be moving the variable into the
Robert> library. Then any application that installed a signal handler
Robert> and set the flag would be able to exit these loops.
Robert> Thoughts?
I t
On Mon, 14 Nov 2005 16:30:27 + Dave wrote:
DS> As far as the 5.3 stuff is concerned, I may have got the wrong idea.
DS> You seemed to be talking about breaking backwards compatibility,
DS> and moving things from one library to another. That felt more
DS> than simply fixing bugs, which is why I
On Sun, 2005-11-13 at 23:28 -0500, Sharon Gowan wrote:
> I have been looking for a good example of using get next to walk a section
> of a mib, but it doesn't pop out at me from the net-snmp development web
> site. Can anyone on this mailing list point me to a good, clearly-written,
> bare-bone
On Mon, 2005-11-14 at 10:48 -0500, Robert Story wrote:
> DS> I'm also concerned about how many changes seem to be being made in the
> DS> supposed 5.2.2 "release candidate", without discussion.
>
> This is one of the reasons I suggested we move to 5.2.3.pre instead
> of staying with the rc name. B
On Thu, 10 Nov 2005 17:15:01 -0500 [EMAIL PROTECTED] wrote:
DC> Tried to install 5.1.3.1 under Cygwin on a Win 2003 - SP1 server and got
DC> the following message. (Installation was just ./configure, make, and make
DC> install).
DC>
DC> I got the following error message from running ./configure.
D
On Mon, 14 Nov 2005 11:59:44 + Dave wrote:
DS> > Please note that it looks like the 5.3 Release Manager has decided to
DS> > rush this into 5.3.pre3 which has already been released, so any future
DS> > discussion on this thread may well be academic by nature. :-/
Well, I had 2 choices for a
HI
In snmpd.conf (in 5.2.1) we are using trapsess
to send trap to V3 manager.
snmpTargetAddrTable is not getting populated
with the trapsess entry, it comes up with trapsink , trap2sink and infromsink.
Please clarify.
Regards,
Hey thanks Dave:)
The access configuration was
"rocommunity public 127.0.0.1" in snmpd.conf file
so I made a change to this as "rocommunity public"
later I was able to get the values appropriately.
This e-mail and attachments contain confidential information
from HUAWEI, which is
George Hadjichristofi wrote:
When I do snmpwalk I see a lot of IPv4 information, but I only see 10-15
entries reflecting the IPV6-MIB.
Also, when I do snmpget to retrieve information such as ipv6RouteDest I
get an error that the object does not exist.
I am currently using Fedora Core 3,kernel 2
On Fri, 2005-11-11 at 23:04 +0100, Thomas Anders wrote:
> Dave Shield wrote:
> >What do people think about splitting this into a number
> > of separate man pages?
> I'm not convinced splitting (a lot) is too helpful.
Having to look through a multitude of itty-bitty man
pages is obviously no
On Fri, 2005-11-11 at 14:53 -0500, Paul D. Murphy wrote:
> Here is a replacement file for the SNMP++ Managed wrappers that will compile
> again the 2.0 version of the CLR (MSVC8). You also need to remove the
> include for libcmt.lib (Project Properties --> Linker --> Input -->
> Additional Dependen
On Mon, 2005-11-14 at 16:57 +0530, Naganarasimha wrote:
> if I execute any command from the same system, I am able see receiving and
> sending information but from any other machine I am able to see it is just
> receiving the data but not "sending".
So the agent *is* receiving the requests OK?
Tha
On Mon, 2005-11-14 at 10:53 +0100, Thomas Anders wrote:
> Dave Shield wrote:
> > Now I know that I've a much more conservative attitude towards this
> > than everyone else, so I fully expect to be shot down in flames yet
> > again. But I don't believe we should be contemplating such structural
> >
On Sun, 2005-11-13 at 20:16 -0500, Robert Story wrote:
> Obviously introducing a dependency on an external variable, and breaking
> backwards compatibility, is not a good thing. However, if we were going to do
> it, 5.3 would be the right time.
>
> The other options would be moving the variable in
- do the agent's control settings allow this request?
(The 'snmpd -f -Le -d' command will show a series of
incoming PDUs with *no* corresponding outgoing PDUs)
this is the reason I could see
if I execute any command from the same system, I am able see receiving an
On Mon, 2005-11-14 at 12:22 +0100, Thomas Anders wrote:
> README.agent-libs in MAIN doesn't seem up-to-date wrt. disman/*.
> Can you please update it?
Will do.
Just as soon as I've finished with snmpd.conf(5)
The DisMan stuff there needs reworking too.
Dave
Dave Shield wrote:
Now I know that I've a much more conservative attitude towards this
than everyone else, so I fully expect to be shot down in flames yet
again. But I don't believe we should be contemplating such structural
changes at this point - maybe two or three weeks ago, but not now.
Pl
Dave,
README.agent-libs in MAIN doesn't seem up-to-date wrt. disman/*. Can you
please update it?
Cheers,
Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)
---
SF.Net email is sponsored by:
Tame your development challenges with Apac
On Mon, 2005-11-14 at 14:29 +0530, Naganarasimha wrote:
> I am able to enable the snmp in that machine and get the
> mib values thru snmp walk in the same machine
>
> But if I try to see the mib values thru mib browser from
> some other PC I am not able too.
>
> I presume snmp is listening on som
Hi:
I have been looking for a good example of using get next to walk a section
of a mib, but it doesn't pop out at me from the net-snmp development web
site. Can anyone on this mailing list point me to a good, clearly-written,
bare-bones example similar to the one on the net-snmp site shows f
On Sun, 2005-11-13 at 09:02 -0800, mahua dutta wrote:
> I am in one peculiar need.
> The snmp master is based on snmpv2p.
>
> I need to run snmpwalk on that snmp master. Does
> snmpwalk/snmpget work work for snmpv2p?
No.
>From the FAQ:
Which versions of SNMP are supported in this package?
-
On Mon, 2005-11-14 at 11:31 +0530, aakansha rajvi wrote:
Thomas> If it doesn't work for you (it does for me), then ...
Thomas> and post the output (of both agents)
> Output of
> snmpd -f -Le -Dread_config,tdomain,netsnmp_udp,snmp_agent 10.0.0.11
[snip]
And what is the output of
s
I have a suse linux 9.0 with net snmp 5.1
I am able to enable the snmp in that machine and get
the mib values thru snmp walk in the same machine
But if I try to see the mib values thru mib browser
from some other PC I am not able too.
I presume snmp is listening on some other port
rat
Dave Shield schrieb:
Very nearly.
The one thing that seems wrong is the ordering of the indexes
in the camTable:
satEntryOBJECT-TYPE
INDEX { satIndex }
::= { satTable 1 }
camEntryOBJECT-TYPE
INDEX { camI
37 matches
Mail list logo
