QUESTION:
I am writing my own SNMP query manager by sending the proper UDP
datagram to the snmp agent (port 161) of another RS6K. The
remote RS6K is not responding to my PDU-GET. His /etc/snmpd.conf
has not changed from the default, so any SNMP manager is allowed
RW access.
Using "iptrace", I see that there are no differences in my SNMP
packet from another NV/6000 SNMP packet, except that the access control
field is "10" in the NV packet and "00" in my packet (header). 802.5
token ring) MAC headers are used.
Is the access control field the reason I do not get a response?
If yes, how can I set this to "10"?
---------- ---------- ---------- --------- ---------- ----------
The 0x10 represents the Token bit being on but since this is not
accessible from this level, I do not think that this is actually
the problem.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
The PDU-GET is a protocol data unit with a get-request. It is part of
a UDP packet sent to port 161 of an SNMP agent.
It is an ASN.1 sequence consisting of a version identifier in ASN.1
integer format, a community name in ASN.1 octect format, a PDU get
request which consists of a:
a get operation code
a unique ID in ASN.1 integer format
error status in ASN.1 integer format
another ASN.1 sequence consisting of:
object ID in ASN.1 object format
null terminator in ASN.1 NULL format
The packet is sent as seen in an iptrace, and the bytes look correct.
There is no response from the SNMP agent the packet is directed to as
evidenced again by the iptrace.
One possible problem is that there is a password file called
/etc/snmpd.pw created by mksnmppw command, using a source file like
smpl.pwinput.
This password file does not exist on my system, yet
iptrace shows another system in our network running NETVIEW/6000 to
have queried my SNMP agent. I concluded that it was not required.
The mksnmppw and the smpl.pwinput files are not on any of my systems,
even though InfoExplorer says they are part of the BOS (Network
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
Upon further comparison of my packet with the valid SNMP packet, I found tha
there was an additional sequence around the Object and Value (VarBindList).
After adding this additional sequence, I began to receive responses. Please
forgive my error.
My final question concerns the Object ID I saw in the packet captured. The
Object ID was "43.6.1.2.1.1.3.0" rather than "1.3.6.1.2.1.1.3.0". What
does the "43" represent? ("1" means "iso").
---------- ---------- ---------- --------- ---------- ----------
The object id '43.6.1.2.1.1.3.0' is the ASN.1 representation of
'1.3.6.1.2.1.1.3.0'. According to ASN.1 encoding standards, the
first 2 numeric labels of an object identifier are encoded in a single
octet. The ASN.1 encodes these first 2 subidentifiers 'a' and 'b' as
a*40 + b. For the above object id a=1, b=3, 1*40 + 3 = 43 = 0x2b.
This formula is provided in "Internetworking with TCP/IP" by Douglas
Comer and David L. Stevens, Volume II, Chapter 18, page 397.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q600373 BQNTM
Additional search words:
BQNTM IX LPPS OCT92 OZNEW QUESTION RISCO RISCSYSTEM SNMP SOFTWARE
SUPT
WWQA: ITEM: RTA000025636 ITEM: RTA000025636
Dated: 01/1995 Category: RISCO
This HTML file was generated 99/06/24~12:43:09
Comments or suggestions?
Contact us