I'm learning about and experimenting with some of the "extensible"
features included in net-snmp. There's a lot of power available which
most of us ignore. But I'm having a problem with one feature and hoping
someone here might know what I'm missing.

The feature I'm trying to use is called "pass-through". Basically, the
SNMP agent, when it receives a request for any OID below a specific
point in the tree, passes the request to an external program and then
serves up whatever answer that program provides. The program should
answer with three lines on its stdout, the full OID, the type of data,
and the value. For example,

  .1.3.6.1.4.1.2021.203.101.1
  integer
  14

I have a program which does exactly that. It behaves correctly when
called from the command line and, based on having it log results to a
temporary file, it also behaves correctly when called by the SNMP agent.
But the agent does not provide the answer expected. Here are two lines
from a tcpdump of the problem.

16:50:26.018721 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], 
proto: UDP (17), length: 73) PDL.47649 > 172.17.22.151.snmp: [bad udp 
cksum bb06!]  { SNMPv1 C=comname { GetNextRequest(29) R=1129621682  
E:2021.203 } } 
    0x0000:  0006 cf03 035d 001c 23e2 c83c 0800 4500  .....]..#..<..E.
    0x0010:  0049 0000 4000 4011 c96a ac11 0280 ac11  [EMAIL 
PROTECTED]@..j......
    0x0020:  1697 ba21 00a1 0035 7180 302b 0201 0004  ...!...5q.0+....
    0x0030:  0769 7365 7269 6573 a11d 0204 4354 a8b2  .comname....CT..
    0x0040:  0201 0002 0100 300f 300d 0609 2b06 0104  ......0.0...+...
    0x0050:  018f 6581 4b05 00                        ..e.K..
16:50:26.106369 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], 
proto: UDP (17), length: 80) 172.17.22.151.snmp > PDL.47649: [udp sum
ok]  
{ SNMPv1 C=comname { GetResponse(36) R=1129621682
E:8072.1.2.1.1.4.0.1.0.0="" } } 
    0x0000:  001c 23e2 c83c 0006 cf03 035d 0800 4500  ..#..<.....]..E.
    0x0010:  0050 0000 4000 3f11 ca63 ac11 1697 ac11  [EMAIL PROTECTED]
    0x0020:  0280 00a1 ba21 003c 185a 3032 0201 0004  .....!.<.Z02....
    0x0030:  0769 7365 7269 6573 a224 0204 4354 a8b2  .comname.$..CT..
    0x0040:  0201 0002 0100 3016 3014 0610 2b06 0104  ......0.0...+...
    0x0050:  01bf 0801 0201 0104 0001 0000 0400       ..............

It appears to me that, having received a getnext request for
.1.3.6.1.4.1.2021.203, the agent replied with a value for
.1.3.6.1.4.1.8072.1.2.1.1.4.0.1.0.0. I have no idea where it got that
OID or why. That is my puzzle at the moment. Any ideas?

I did notice that tcpdump claims the request has a bad checksum. But
dumping valid traffic shows that all requests seem to have that issue
and all other requests get the expected answers. This is using net-snmp
5.4.17 on Fedora 7 for the requestor and 5.3.4 on an embedded Linux
system for the agent.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
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

Reply via email to