Hi Dave,
The set up is as following. (Please note : below mentioned worked fine
when configured to sue snmpv2. The issue surfaced only for v3)
ON a given host we have 2 agents running.
Agent 1 (port 161) with following config file
createUser public MD5 public123
rwuser public auth -V all
com2sec public default public
group public v1 public
group public v2c public
group public usm public
view all included <internal_oid>
access public "" any noauth exact all none none
Agent 2 is the snmpd we use to poll UCD-SNMP stats particularly
dskEntry and memory etc. Following example is for
UCD-SNMP-MIB::dskEntry oid (port 1161)
rwuser public auth -V all
createUser public MD5 public123
com2sec public default public
group mygroup v1 public
group mygroup v2c public
group mygroup usm public
view all included .1.3.6.1.4.1.2021
access public "" any noauth exact all all all
disk /
Like I've mentioned before we have an application that polls both
these agents for mib's they support.
Case1)
When in the application we walk a table on agent:1161 followed by walk
on agent:161. Agent on 161 (snmpd) does not respond with a result ,
we timeout and retry few times and give up. Following is the tcpdump
showing the Get-Next-Request and a Report response a few times.
NOT WORKING case :
-----------------------------------
$ sudo /usr/sbin/tcpdump -l port 1161 -vvv -s 1500 -X -i lo -T snmp
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 1500 bytes
16:07:47.648543 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 159) localhost.localdomain.49714 >
localhost.localdomain.health-polling: { SNMPv3 { F=ar } { USM B=35
T=6685 U=public } { ScopedPDU E=
0x800x000x1F0x880x040x310x300x780x380x780x320x330x780x310x350x38 C= {
GetNextRequest(29) R=1177622206 E:2021.9.1 } } }
0x0000: 4500 009f 0000 4000 4011 3c4c 7f00 0001 e.....@.@.<L....
0x0010: 7f00 0001 c232 0489 008b fe9e 3081 8002 .....2......0...
0x0020: 0103 3011 0204 10c0 36af 0203 00ff e304 ..0.....6.......
0x0030: 0105 0201 0304 3330 3104 1080 001f 8804 ......301.......
0x0040: 3130 7838 7832 3378 3135 3802 0123 0202 10x8x23x158..#..
0x0050: 1a1d 0406 7075 626c 6963 040c 1547 9276 ....public...G.v
0x0060: 9a89 761c 47e0 b7e1 0400 3033 0410 8000 ..v.G.....03....
0x0070: 1f88 0431 3078 3878 3233 7831 3538 0400 ...10x8x23x158..
0x0080: a11d 0204 4631 16be 0201 0002 0100 300f ....F1........0.
0x0090: 300d 0609 2b06 0104 018f 6509 0105 00 0...+.....e....
16:07:47.648860 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 161) localhost.localdomain.health-polling >
localhost.localdomain.49714: { SNMPv3 { F=a } { USM B=26 T=248
U=public } { ScopedPDU E=
0x800x000x1F0x880x040x310x300x780x380x780x320x330x780x310x350x38 C= {
Report(31) R=1177622206
S:snmpUsmMIB.usmMIBObjects.usmStats.usmStatsNotInTimeWindows.0=19 } }
}
0x0000: 4500 00a1 0000 4000 4011 3c4a 7f00 0001 e.....@.@.<J....
0x0010: 7f00 0001 0489 c232 008d fea0 3081 8202 .......2....0...
0x0020: 0103 3011 0204 10c0 36af 0203 00ff e304 ..0.....6.......
0x0030: 0101 0201 0304 3330 3104 1080 001f 8804 ......301.......
0x0040: 3130 7838 7832 3378 3135 3802 011a 0202 10x8x23x158.....
0x0050: 00f8 0406 7075 626c 6963 040c c58e df03 ....public......
0x0060: b699 0a3d bcc0 d4b6 0400 3035 0410 8000 ...=......05....
0x0070: 1f88 0431 3078 3878 3233 7831 3538 0400 ...10x8x23x158..
0x0080: a81f 0204 4631 16be 0201 0002 0100 3011 ....F1........0.
0x0090: 300f 060a 2b06 0106 030f 0101 0200 4101 0...+.........A.
0x00a0: 13 .
case 2). When from the application we try to walk just the
UCD-SNMP-MIB::dskEntry we get the following output , with
Get-Next_Request, Report, Request, Response , Request, Response ....
WORKING CASE
--------------------------------
$ sudo /usr/sbin/tcpdump -l port 1161 -vvv -s 1500 -X -i lo -T snmp
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 1500 bytes
16:10:24.089543 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 157) localhost.localdomain.60512 >
localhost.localdomain.health-polling: { SNMPv3 { F=ar } { USM B=0 T=0
U=public } { ScopedPDU E=
0x800x000x1F0x880x040x310x300x780x380x780x320x330x780x310x350x38 C= {
GetNextRequest(29) R=2002330370 E:2021.9.1 } } }
0x0000: 4500 009d 0000 4000 4011 3c4e 7f00 0001 e.....@.@.<N....
0x0010: 7f00 0001 ec60 0489 0089 fe9c 307f 0201 .....`......0...
0x0020: 0330 1102 0453 dd45 e602 0300 ffe3 0401 .0...S.E........
0x0030: 0502 0103 0432 3030 0410 8000 1f88 0431 .....200.......1
0x0040: 3078 3878 3233 7831 3538 0201 0002 0100 0x8x23x158......
0x0050: 0406 7075 626c 6963 040c 98c3 6802 4c29 ..public....h.L)
0x0060: b757 8bc0 5680 0400 3033 0410 8000 1f88 .W..V...03......
0x0070: 0431 3078 3878 3233 7831 3538 0400 a11d .10x8x23x158....
0x0080: 0204 7759 2302 0201 0002 0100 300f 300d ..wY#.......0.0.
0x0090: 0609 2b06 0104 018f 6509 0105 00 ..+.....e....
16:10:24.089949 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 161) localhost.localdomain.health-polling >
localhost.localdomain.60512: { SNMPv3 { F=a } { USM B=26 T=405
U=public } { ScopedPDU E=
0x800x000x1F0x880x040x310x300x780x380x780x320x330x780x310x350x38 C= {
Report(31) R=2002330370
S:snmpUsmMIB.usmMIBObjects.usmStats.usmStatsNotInTimeWindows.0=31 } }
}
0x0000: 4500 00a1 0000 4000 4011 3c4a 7f00 0001 e.....@.@.<J....
0x0010: 7f00 0001 0489 ec60 008d fea0 3081 8202 .......`....0...
0x0020: 0103 3011 0204 53dd 45e6 0203 00ff e304 ..0...S.E.......
0x0030: 0101 0201 0304 3330 3104 1080 001f 8804 ......301.......
0x0040: 3130 7838 7832 3378 3135 3802 011a 0202 10x8x23x158.....
0x0050: 0195 0406 7075 626c 6963 040c dee7 1ccc ....public......
0x0060: 7d55 1c51 f12d da58 0400 3035 0410 8000 }U.Q.-.X..05....
0x0070: 1f88 0431 3078 3878 3233 7831 3538 0400 ...10x8x23x158..
0x0080: a81f 0204 7759 2302 0201 0002 0100 3011 ....wY#.......0.
0x0090: 300f 060a 2b06 0106 030f 0101 0200 4101 0...+.........A.
0x00a0: 1f .
16:10:24.090758 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 159) localhost.localdomain.60512 >
localhost.localdomain.health-polling: { SNMPv3 { F=ar } { USM B=26
T=405 U=public } { ScopedPDU E=
0x800x000x1F0x880x040x310x300x780x380x780x320x330x780x310x350x38 C= {
GetNextRequest(29) R=2002330370 E:2021.9.1 } } }
0x0000: 4500 009f 0000 4000 4011 3c4c 7f00 0001 e.....@.@.<L....
0x0010: 7f00 0001 ec60 0489 008b fe9e 3081 8002 .....`......0...
0x0020: 0103 3011 0204 53dd 45e7 0203 00ff e304 ..0...S.E.......
0x0030: 0105 0201 0304 3330 3104 1080 001f 8804 ......301.......
0x0040: 3130 7838 7832 3378 3135 3802 011a 0202 10x8x23x158.....
0x0050: 0195 0406 7075 626c 6963 040c d0eb cc90 ....public......
0x0060: ceb4 4712 e4aa 02a6 0400 3033 0410 8000 ..G.......03....
0x0070: 1f88 0431 3078 3878 3233 7831 3538 0400 ...10x8x23x158..
0x0080: a11d 0204 7759 2302 0201 0002 0100 300f ....wY#.......0.
0x0090: 300d 0609 2b06 0104 018f 6509 0105 00 0...+.....e....
16:10:24.091299 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 162) localhost.localdomain.health-polling >
localhost.localdomain.60512: { SNMPv3 { F=a } { USM B=26 T=405
U=public } { ScopedPDU E=
0x800x000x1F0x880x040x310x300x780x380x780x320x330x780x310x350x38 C= {
GetResponse(32) R=2002330370 E:2021.9.1.1.1=1 } } }
0x0000: 4500 00a2 0000 4000 4011 3c49 7f00 0001 e.....@.@.<I....
0x0010: 7f00 0001 0489 ec60 008e fea1 3081 8302 .......`....0...
0x0020: 0103 3011 0204 53dd 45e7 0203 00ff e304 ..0...S.E.......
0x0030: 0101 0201 0304 3330 3104 1080 001f 8804 ......301.......
0x0040: 3130 7838 7832 3378 3135 3802 011a 0202 10x8x23x158.....
0x0050: 0195 0406 7075 626c 6963 040c 152b 35ea ....public...+5.
0x0060: 19c1 c5c9 a6d0 3efe 0400 3036 0410 8000 ......>...06....
0x0070: 1f88 0431 3078 3878 3233 7831 3538 0400 ...10x8x23x158..
0x0080: a220 0204 7759 2302 0201 0002 0100 3012 ....wY#.......0.
0x0090: 3010 060b 2b06 0104 018f 6509 0101 0102 0...+.....e.....
0x00a0: 0101 ..
Not sure why snmpd does not respond in the failure case? Or is the
session not set up right by the application when talking to 2 agents?
Is there anything i could check in the application? The credentials
are all identical for working and not working case. The issue is
observed when the communication is using v3 and not using v2. I dint
see specific error messages in /var/log/messages. Just that snmpd
received connection and messages.
Thanks
Aravind
On Thu, Dec 23, 2010 at 12:36 AM, Dave Shield
<d.t.shi...@liverpool.ac.uk> wrote:
> On 23 December 2010 07:06, aravind narasimhan <aravin...@gmail.com> wrote:
>> I sure will try this suggestion. However, from debugging the problem
>> i've found that the snmp v3 requests make it to the correct agent
>> (tcpdump on the respective ports) The response is not sent in the
>> failure case resulting in a timeout. Hence my supposition that
>> something in the pdu is incorrect. Any thoughts?
>
> A bit more detail about exactly how things are configured,
> what request you are sending where, and exactly how far things
> get might be useful.
> ("snmpv3 requests make it to the correct agent" is a bit vague)
>
> Also, is there anything logged by either agent which might
> give a clue as to the problem?
>
> Dave
>
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
