Re: [tkined] [Q] About agent mode coding

Bae Young Ho (yhbae@rcunix.kotel.co.kr)
Thu, 13 Nov 1997 11:00:22 +0900 (KST)

I think my last mail is lost during delivery. So I re-send this mail again.
If this mail is duplicated one, please just ignore it.
Juergen Schoenwaelder wrote:
[snip]
> I need more information about what NMS(TeMIP) is actually sending to
> scotty. Can you run the agent script with after evaluating
>
> snmp watch on
>
> so that you can capture contents of the packets? And can you tell us
> which version of Tcl/Tk/scotty you are using on which system?

I use Tcl 7.6,Tk 4.2, and Scotty 2.1.7 on Digital Unix 3.2G

Followings are the packet dumps of my program using snmp watch on.

I initialized all string objects in my program to "DisplayString" and
all integer objects(TimeTicks, Unsigned32, Counter32, etc.) to 100,
and OBJECT IDENTIFIER to "1.1.1.1.1.1.1"

In the first step, I send setRequest sysLocation.0 = "over the rainbow"
-------------------------------------------------------------------------------
recv 62 bytes [147.6.13.191:2521]:
3082 003a 0201 0004 0670 7562 6c69 63a3
8200 2b02 0101 0201 0002 0100 3020 3082
001c 0608 2b06 0102 0101 0600 0410 6f76
6572 2074 6865 2072 6169 6e62 6f77
set-request 1 noError
1. 1.3.6.1.2.1.1.6.0 {OCTET STRING} {over the rainbow}
begin -> set-request noError 0 {1.3.6.1.2.1.1.6.0 {OCTET STRING} {over the rainbow}}
sysLocation.0
a(sysLocation.0) = over the rainbow
end -> response noError 0 {1.3.6.1.2.1.1.6.0 {OCTET STRING} {over the rainbow}}
response 1 noError
1. 1.3.6.1.2.1.1.6.0 {OCTET STRING} {over the rainbow}
send 56 bytes [147.6.13.191:2521]:
3036 0201 0004 0670 7562 6c69 63a2 2902
0101 0201 0002 0100 301e 301c 0608 2b06
0102 0101 0600 0410 6f76 6572 2074 6865
2072 6169 6e62 6f77
-------------------------------------------------------------------------------

And in the 2nd step, I sent a getRequest for all objects for system group
-------------------------------------------------------------------------------
recv 142 bytes [147.6.13.191:2530]:
3082 008a 0201 0004 0670 7562 6c69 63a0
8200 7b02 0102 0201 0002 0100 3070 3082
000c 0608 2b06 0102 0101 0100 0500 3082
000c 0608 2b06 0102 0101 0200 0500 3082
000c 0608 2b06 0102 0102 0100 0500 3082
000c 0608 2b06 0102 0101 0400 0500 3082
000c 0608 2b06 0102 0101 0500 0500 3082
000c 0608 2b06 0102 0101 0600 0500 3082
000c 0608 2b06 0102 0101 0700 0500
get-request 2 noError
1. 1.3.6.1.2.1.1.1.0 NULL {}
2. 1.3.6.1.2.1.1.2.0 NULL {}
3. 1.3.6.1.2.1.2.1.0 NULL {}
4. 1.3.6.1.2.1.1.4.0 NULL {}
5. 1.3.6.1.2.1.1.5.0 NULL {}
6. 1.3.6.1.2.1.1.6.0 NULL {}
7. 1.3.6.1.2.1.1.7.0 NULL {}
begin -> get-request noError 0 {1.3.6.1.2.1.1.1.0 NULL {}} {1.3.6.1.2.1.1.2.0 NULL {}} {1.3.6.1.2.1.2.1.0 NULL {}} {1.3.6.1.2.1.1.4.0 NULL {}} {1.3.6.1.2.1.1.5.0 NULL {}} {1.3.6.1.2.1.1.6.0 NULL {}} {1.3.6.1.2.1.1.7.0 NULL {}}
get-request from 147.6.13.191:2530
get-request from 147.6.13.191:2530
get-request from 147.6.13.191:2530
get-request from 147.6.13.191:2530
get-request from 147.6.13.191:2530
get-request from 147.6.13.191:2530
get-request from 147.6.13.191:2530
end -> response noError 0 {1.3.6.1.2.1.1.1.0 {OCTET STRING} DisplayString} {1.3.6.1.2.1.1.2.0 {OBJECT IDENTIFIER} 1.1.1.1.1.1.1} {1.3.6.1.2.1.2.1.0 INTEGER 100} {1.3.6.1.2.1.1.4.0 {OCTET STRING} DisplayString} {1.3.6.1.2.1.1.5.0 {OCTET STRING} DisplayString} {1.3.6.1.2.1.1.6.0 {OCTET STRING} {over the rainbow}} {1.3.6.1.2.1.1.7.0 INTEGER 100}
response 2 noError
1. 1.3.6.1.2.1.1.1.0 {OCTET STRING} DisplayString
2. 1.3.6.1.2.1.1.2.0 {OBJECT IDENTIFIER} 1.1.1.1.1.1.1
3. 1.3.6.1.2.1.2.1.0 INTEGER 100
4. 1.3.6.1.2.1.1.4.0 {OCTET STRING} DisplayString
5. 1.3.6.1.2.1.1.5.0 {OCTET STRING} DisplayString
6. 1.3.6.1.2.1.1.6.0 {OCTET STRING} {over the rainbow}
7. 1.3.6.1.2.1.1.7.0 INTEGER 100
send 190 bytes [147.6.13.191:2530]:
3081 bb02 0100 0406 7075 626c 6963 a281
ad02 0102 0201 0002 0100 3081 a130 1906
082b 0601 0201 0101 0004 0d44 6973 706c
6179 5374 7269 6e67 3012 0608 2b06 0102
0101 0200 0606 2901 0101 0101 300d 0608
2b06 0102 0102 0100 0201 6430 1906 082b
0601 0201 0104 0004 0d44 6973 706c 6179
5374 7269 6e67 3019 0608 2b06 0102 0101
0500 040d 4469 7370 6c61 7953 7472 696e
6730 1c06 082b 0601 0201 0106 0004 106f
7665 7220 7468 6520 7261 696e 626f 7730
0d06 082b 0601 0201 0107 0002 0164
-------------------------------------------------------------------------------

In 3rd step, I changed the value of sysLocation.0 to "under the sea"
-------------------------------------------------------------------------------
recv 59 bytes [147.6.13.191:2531]:
3082 0037 0201 0004 0670 7562 6c69 63a3
8200 2802 0101 0201 0002 0100 301d 3082
0019 0608 2b06 0102 0101 0600 040d 756e
6465 7220 7468 6520 7365 61
set-request 1 noError
1. 1.3.6.1.2.1.1.6.0 {OCTET STRING} {under the sea}
begin -> set-request noError 0 {1.3.6.1.2.1.1.6.0 {OCTET STRING} {under the sea}}
sysLocation.0
a(sysLocation.0) = under the sea
end -> response noError 0 {1.3.6.1.2.1.1.6.0 {OCTET STRING} {under the sea}}
response 1 noError
1. 1.3.6.1.2.1.1.6.0 {OCTET STRING} {under the sea}
send 53 bytes [147.6.13.191:2531]:
3033 0201 0004 0670 7562 6c69 63a2 2602
0101 0201 0002 0100 301b 3019 0608 2b06
0102 0101 0600 040d 756e 6465 7220 7468
6520 7365 61
-------------------------------------------------------------------------------

Yes, I worked fine till now.
But, when I sent getRequest again for all objects in systems group, there are
some bizarre result.
Yes, sysLocation.0 is not changed to "under the sea", but it remains to
"over the rainbow".
-------------------------------------------------------------------------------
recv 142 bytes [147.6.13.191:2533]:
3082 008a 0201 0004 0670 7562 6c69 63a0
8200 7b02 0102 0201 0002 0100 3070 3082
000c 0608 2b06 0102 0101 0100 0500 3082
000c 0608 2b06 0102 0101 0200 0500 3082
000c 0608 2b06 0102 0102 0100 0500 3082
000c 0608 2b06 0102 0101 0400 0500 3082
000c 0608 2b06 0102 0101 0500 0500 3082
000c 0608 2b06 0102 0101 0600 0500 3082
000c 0608 2b06 0102 0101 0700 0500
get-request 2 noError
1. 1.3.6.1.2.1.1.1.0 NULL {}
2. 1.3.6.1.2.1.1.2.0 NULL {}
3. 1.3.6.1.2.1.2.1.0 NULL {}
4. 1.3.6.1.2.1.1.4.0 NULL {}
5. 1.3.6.1.2.1.1.5.0 NULL {}
6. 1.3.6.1.2.1.1.6.0 NULL {}
7. 1.3.6.1.2.1.1.7.0 NULL {}
response 2 noError
1. 1.3.6.1.2.1.1.1.0 {OCTET STRING} DisplayString
2. 1.3.6.1.2.1.1.2.0 {OBJECT IDENTIFIER} 1.1.1.1.1.1.1
3. 1.3.6.1.2.1.2.1.0 INTEGER 100
4. 1.3.6.1.2.1.1.4.0 {OCTET STRING} DisplayString
5. 1.3.6.1.2.1.1.5.0 {OCTET STRING} DisplayString
6. 1.3.6.1.2.1.1.6.0 {OCTET STRING} {over the rainbow}
7. 1.3.6.1.2.1.1.7.0 INTEGER 100
send 190 bytes [147.6.13.191:2533]:
3081 bb02 0100 0406 7075 626c 6963 a281
ad02 0102 0201 0002 0100 3081 a130 1906
082b 0601 0201 0101 0004 0d44 6973 706c
6179 5374 7269 6e67 3012 0608 2b06 0102
0101 0200 0606 2901 0101 0101 300d 0608
2b06 0102 0102 0100 0201 6430 1906 082b
0601 0201 0104 0004 0d44 6973 706c 6179
5374 7269 6e67 3019 0608 2b06 0102 0101
0500 040d 4469 7370 6c61 7953 7472 696e
6730 1c06 082b 0601 0201 0106 0004 106f
7665 7220 7468 6520 7261 696e 626f 7730
0d06 082b 0601 0201 0107 0002 0164
-------------------------------------------------------------------------------
Is there any solution for this problem ?

Thanks in advance.

--
mail: yhbae@rcunix.kotel.co.kr | Bae, Young-Ho
voice: +82-2-526-5214          | Wireless Communications Research Laboratory
fax:   +82-2-526-5568          | KTRL, 17 Woomyun-Dong, Suhcho-Ku, Seoul, ROK
--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.