Hi Dave,
Sorry, the below issue is a false alarm.
The user has encountered a firewall issue.
So NET-SNMP is properly using the authoritative
engine ID for discovery!
Cheers,
Frank
Frank Fock wrote:
Hi Dave,
I have not forgotten to put together the AgentX
issues that I have found while
Hi Dave,
I have not forgotten to put together the AgentX
issues that I have found while testing NET-SNMP
interoperability. I think I can provide that
report next weekend.
Meanwhile I came across another issue related
to NET-SNMP:
SNMP4J(-Agent) supports engine ID discovery.
A SNMP4J user
Hi Dave,
I have placed this issue on the AgentX mailing list
and reached consensus regarding the null object
identifier usage. This zero length OID must be used
where explicitly mentioned in RFC2741 only. The
references I found refer to the AgentXOpen PDU
and AgentX SearchRanges. A zero length
On 21/02/07, Frank Fock [EMAIL PROTECTED] wrote:
I have placed this issue on the AgentX mailing list
and reached consensus regarding the null object
identifier usage.
Yes - I've been following the discussion.
Do you have an estimation in which NET-SNMP version
this fix will be available?
Hello again
I'll bring it up with the Agentpp developers to see if they should deal
with this differently. At least it seems like they should.
Just a follow up with the answer from Frank Fock:
a 0.0 OID should be encoded like:
02 00 00 00
00 00 00 00
00 00 00 00
and not
00 00 00 00
which
On 14/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
Just a follow up with the answer from Frank Fock:
a 0.0 OID should be encoded like:
02 00 00 00
00 00 00 00
00 00 00 00
and not
00 00 00 00
which is actually a zero length OID
Frank,
how do you interpret the last paragraph of
Hi Dave,
Good point, section 5.1 clearly states that
a null Object Identifier should be encoded
as four 0 bytes. From my point of view,
the term a null Object Identifier refers to
a zero length OID. Given that this is true,
the encoding would be consistent with the
actual value (both have a zero
Dave Shield wrote:
Hmmm, is there a way to block only these types of OID's?
Look in 'agent/mibgroup/agentx/protocol.c' in the
routine agentx_realloc_build_oid(). The first block
of code is special-case handling for the Null OID.
Hurrah, it works!
That should encode .0.0 just as any
On 10/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
Dave Shield wrote:
Can you try turning on packet dumps in the subagent
and issue a GET request for one of the offending instances.
I wasn't quite sure how to do it, but I've got debug output from my master
agent, and an ethereal dump.
Hello
Can you try turning on packet dumps in the subagent
and issue a GET request for one of the offending instances.
I'm not sure whether you're using the normal Net-SNMP agent
running as a subagent, or the simpler subagent-specific framework.
I'm probably using the normal agent. More
On 12/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
Didn't get any output with snmpd -f -X -d but adding -D ALL gave a lot
more information.
Yes - it tends to!
I have extracted the info around the ifSpecific.1 snmpget and put it here:
http://www.navtek.no/~johnny/snmpd/agentxdump.log
Dave Shield wrote:
Didn't get any output with snmpd -f -X -d but adding -D ALL gave a lot
more information.
Yes - it tends to!
:) I couldn't find any information about the different tokens available. I
didn't have access to internet either so I was unable to search for it.
The only thing I
On 12/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
Hmmm, is there a way to block only these types of OID's? It would at least
help through the first deadline I've got.
Try the following.
Look in 'agent/mibgroup/agentx/protocol.c' in the
routine agentx_realloc_build_oid(). The first block
Dave Shield wrote:
On 08/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
I'm pretty sure that the problem lies in the encoding of the OID .0.0,
Can you try turning on packet dumps in the subagent
and issue a GET request for one of the offending instances.
I wasn't quite sure how to do it,
Dave Shield wrote:
I'm pretty sure that the problem lies in the encoding of the OID .0.0,
Can you try turning on packet dumps in the subagent
and issue a GET request for one of the offending instances.
I wasn't quite sure how to do it, but I've got debug output from my master
agent, and an
On 08/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
I'm pretty sure that the problem lies in the encoding of the OID .0.0,
Any progress?
Sorry - paid work got in the way :-(
Can you try turning on packet dumps in the subagent
and issue a GET request for one of the offending instances.
Dave Shield wrote:
I'm pretty sure that the problem lies in the encoding of the OID .0.0,
Any progress?
Sorry - paid work got in the way :-(
No worries. BTW: I'm willing to pay to get this sorted though.
Can you try turning on packet dumps in the subagent
and issue a GET request for one
I'm pretty sure that the problem lies in the encoding of the OID .0.0,
Any progress? I'll try to look myself, but my knowledge of the AgentX
protocol and inner workings of net-snmpd is limited.
A short-time solution for me would be to block all output of .0.0-OID's.
How can I go about doing
Dave Shield wrote:
On 02/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
I've made a master AgentX (using agentpp) that uses net-snmp as subagent
I've done a bit of poking about, and suspect that the Net-SNMP subagent
may
be returning an invalid encoding of .0.0 within the AgentX packet.
On 06/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
Unfortunately the patch didn't seem to help.
Pity :-(
OK - I'll have another look.
One interesting output from this log:
IF-MIB::ifSpecific.1 = Wrong Type (should be OBJECT IDENTIFIER): Variable
has bad type
Yes - I spotted this and got
On 02/02/07, Johnny Ljunggren [EMAIL PROTECTED] wrote:
I've made a master AgentX (using agentpp) that uses net-snmp as subagent
to provide mib-II information. I get a general failure if I try to get
some of the OIDs.
I did some more research and found that only the OIDs defined as OID:
I've made a master AgentX (using agentpp) that uses net-snmp as subagent
to provide mib-II information. I get a general failure if I try to get
some of the OIDs.
I did some more research and found that only the OIDs defined as OID:
SNMPv2-SMI::zeroDotZero will give this error.
ie.
Hello
I've made a master AgentX (using agentpp) that uses net-snmp as subagent
to provide mib-II information. I get a general failure if I try to get
some of the OIDs.
This only occurs when running net-snmp as subagent, because it will return
the whole tree if running standalone.
# snmpwalk -v
23 matches
Mail list logo
