[erlang-questions] SNMP app questions: ?StorageType_volatile, Mnesia storage in general

Scott Lystig Fritchie fritchie@REDACTED
Fri Mar 16 08:18:23 CET 2007


Hi, I've been playing quite a bit with the OTP SNMP app.  It's quite a
nifty pice of work.  But I'm still (uncomfortably) a blind man patting
the elephant, trying to discover its shape.  So perhaps my questions
are silly, my apologies in advance.

1. I've been using Unbrowse 1.5(*) to test my SNMP v3 agent
   application.

    a. Create a group with Unbrowse
    b. Stop the SNMP agent application
    c. Start the SNMP agent application

... but after the restart, my new group is gone.  If I capture the
packet SNMP SET datagram, I see that my client is requesting
StorageType...

Hm, I don't really grok how to decode these things ... I have an
annotated "wireshark" output below (see the "SLF" marks) ... it looks
like the Unbrowse client is *not* sending anything for the
"vacmAccessStorageType" attribute.

But diving into the guts of snmpa_vacm.erl, when the agent restarts,
it reads the contents of {db_dir}/snmpa_vacm.db, finds the entry for
my new group, but then ignores it because it's a volatile type,
?'StorageType_volatile'.

Is this a feature?  Perhaps the Unbrowse app is silly/broken for not
specifying a value for "vacmAccessStorageType", but this behavior
really is confusing.  It doesn't appear to be configurable, so I may
have to hack code to change it.

2. Why does the SNMP app use local dets storage so frequently (with no
   config option to use Mnesia?  And why does the snmpa_vacm table use
   ets:tab2file() instead of Mnesia or event dets?

It would seem to me advantageous from a high-availability
point-of-view to have all that stuff in Mnesia.  If Node A fails, how
is the SNMP app on node B going to look at all that dets and tab2file
stuff over on node A?

-Scott

(*) Ask Mr. Google about it.  It's a Windows SNMP app that claims to
manipulate SNMP v3 servers, including adding/modifying/deleting SNMP
v3 users, groups, and views.  I found it because some search engine
told me it might be good for something.  {shrug}

--- snip --- snip --- snip --- snip --- snip --- snip ---

No.     Time        Source                Destination           Protocol Info
      3 0.109612    10.1.1.253            10.1.1.12             SNMP     set-request

Frame 3 (239 bytes on wire, 239 bytes captured)
Linux cooked capture
Internet Protocol, Src: 10.1.1.253 (10.1.1.253), Dst: 10.1.1.12 (10.1.1.12)
User Datagram Protocol, Src Port: 4968 (4968), Dst Port: 4000 (4000)
    Source port: 4968 (4968)
    Destination port: 4000 (4000)
    Length: 203
    Checksum: 0xf844 [correct]
Simple Network Management Protocol
    msgVersion: snmpv3 (3)
    msgGlobalData
    msgAuthoritativeEngineID: 656E67696E656130
    0... .... = Engine ID Conformance: RFC1910 (Non-SNMPv3)
    Engine Enterprise ID: Unknown (1701734249)
    <Data not conforming to RFC1910>
    msgAuthoritativeEngineBoots: 10
    msgAuthoritativeEngineTime: 376
    msgUserName: foouser
    msgAuthenticationParameters: 2546C72089B42A036498DCDC
    msgData: plaintext (0)
        plaintext
            contextEngineID: 656E67696E656130
            data: set-request (3)
                set-request
                    request-id: 28497
                    error-status: noError (0)
                    error-index: 0
                    variable-bindings: 3 items
                        Item
                            name: 1.3.6.1.6.3.16.1.4.1.5 <-- SLF: vacmAccessReadViewName?
                            name: 1.3.6.1.6.3.16.1.4.1.5.9.98.108.97.114.98.108.97.114.51.0.0.1 (SNMPv2-SMI::snmpModules.16.1.4.1.5.9.98.108.97.114.98.108.97.114.51.0.0.1)
                            valueType: value (0)
                                value: simple (4294967295)
                                    simple: string-value (1)
                                        Value: STRING: "blar2view"
                        Item
                            name: 1.3.6.1.6.3.16.1.4.1.4 <-- SLF: vacmAccessContextMatch?
                            name: 1.3.6.1.6.3.16.1.4.1.4.9.98.108.97.114.98.108.97.114.51.0.0.1 (SNMPv2-SMI::snmpModules.16.1.4.1.4.9.98.108.97.114.98.108.97.114.51.0.0.1)
                            valueType: value (0)
                                value: simple (4294967295)
                                    simple: integer-value (0)
                                        Value: INTEGER: 1
                        Item
                            name: 1.3.6.1.6.3.16.1.4.1.9 <-- SLF: vacmAccessStatus?
                            name: 1.3.6.1.6.3.16.1.4.1.9.9.98.108.97.114.98.108.97.114.51.0.0.1 (SNMPv2-SMI::snmpModules.16.1.4.1.9.9.98.108.97.114.98.108.97.114.51.0.0.1)
                            valueType: value (0)
                                value: simple (4294967295)
                                    simple: integer-value (0)
                                        Value: INTEGER: 4



More information about the erlang-questions mailing list