What Does "No More Variables Left in This Mib View" Mean (Linux)

What does No more variables left in this MIB View mean (Linux)?

There's a bit more going on here than you might suspect. I encounter this on every new Ubuntu box that I build, and I do consider it a problem (not an error, but a problem--more on this down further).

Here's the technically-correct explanation (why this is not an "error"):

"No more variables left in this MIB View" is not particularly an error; rather, it is a statement about your request. The request started at something simple, say ".1.3" and continued to ask for the "next" lexicographic OID. It got "next" OIDs until that last one, at which point the agent has informed you that there's nothing more to see; don't bother asking.

Now, here's why I consider it a problem (in the context of this question):

The point of installing "snmpd" and running it is to gather meaningful information about the box; typically, this information is performance-oriented. For example, the three general things that I need to know about are network-interface information (IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets), disk information (UCD-SNMP-MIB::dskUsed and UCD-SNMP-MIB::dskTotal), and CPU information (UCD-SNMP-MIB::ssCpuRawIdle, UCD-SNMP-MIB::ssCpuRawWait, and so on).

The default Ubuntu "snmpd" configuration specifically denies just about everything useful with this configuration (limiting access to just enough information to tell you that the box is a Linux box):

view systemonly included .1.3.6.1.2.1.1
view systemonly included .1.3.6.1.2.1.25.1
rocommunity public default -V systemonly

This configuration locks the box down, which may be "safe" if it will be on an insecure network with little SNMP administration knowledge available.

However, the first thing that I do is remove the "-V systemonly" portion of the "rocommunity" setting; this will allow all available SNMP information to be accessed (read-only) via the community string of "public".

If you do that, then you'll probably see what you're expecting, which is pages and pages of SNMP information that you can use to gauge the performance of your box.

Snmpwalk randomly returns less variables (ending with SNMPv2-MIB::snmpSetSerialNo.0)

I managed to fix the problem using only one default public community, one user and one group. The group has to have access to only one view with mutiple definitions of OID subtrees:

com2sec notConfigUser    default          public

The community is only defined on com2sec line, but nowhere else.

view    all           included   .1.3.6.1.4.1.x.y
view    all           included   .1.3.6.1.4.1.2021
view    all           included   .1                         80
view    systemview    included   .1.3.6.1.2.1.1
view    systemview    included   .1.3.6.1.2.1.25.1.1
view    systemview    included   .1.3.6.1.4.1

One view to multiple subtrees are defined, but there are not more views than "all" and "systemview".

access  notConfigGroup ""      any       noauth    exact  all none none

notConfigGroup has access to "all" view.

SNMPv3 endOfMibView

Actually, no... endOfMibView is an exception added to the varbind value itself when it's hit. This is done so that an endOfMibView can occur along side a real variable as well. In the SNMPv2 PDU structure, documented in RFC3416, you'll find the definition.

If it set the error-status you'd have to refetch the rest of the variables since it would be a true error and would stop the entire processing sequence. Having it as an in-line exception means that the other variable fetches can proceed still.

How to add the variables in MIB files in the linux?

Whatever MIB files we will make the same we need to add them to the MIB browser by using the load mib browser option normally we can find the same in the file option from the menu bar.

After adding the same we can use all the SNMP commands from any device which consists of the MIB Browser.

Error - (noSuchName) There is no such variable name in this MIB - netSnmp?

There's an small bug in the node definition. It should be ::= { raspScalar 1 }

freeSpaceAvailable OBJECT-TYPE
    SYNTAX      Integer32
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION "The free space available in the system in MB"
DEFVAL { 2 }
::= { raspScalar 1 }

I used tkmib (linux) to troubleshoot the issue.
Following this tutorial, I was able to get good responses

c code fragment:

int fSpace;

// inside init_freeSpaceAvailable
    fSpace = (int) random();

// inside switch statement
        case MODE_GET:
            snmp_set_var_typed_value(requests->requestvb, ASN_INTEGER,
                                    (u_char *)&fSpace,
                                    sizeof(fSpace));
            break;

on /etc/snmp/snmpd.conf add

master agentx

start snmpd as

sudo snmpd -f -Lo -C --rwcommunity=public --master=agentx --agentXSocket=tcp:localhost:1705

start agent as

./mysubagent -f -Lo -x tcp:localhost:1705

Test as

snmpget -v 1 -c public localhost RASP-MIB::freeSpaceAvailable.0

RASP-MIB::freeSpaceAvailable.0 = INTEGER: 924855091

or by OID

snmpget -v 1 -c public -m "+RASP-MIB" localhost 1.3.6.1.4.1.9100.1.1.0
RASP-MIB::freeSpaceAvailable.0 = INTEGER: 924855091

How to access the meaning of a OID variable (Linux)?

You can use the snmptranslate command:

$ snmptranslate iso.3.6.1.2.1.25.1.5.0
HOST-RESOURCES-MIB::hrSystemNumUsers.0

Or you can do the lookup in reverse with -On:

$ snmptranslate -On HOST-RESOURCES-MIB::hrSystemNumUsers.0
.1.3.6.1.2.1.25.1.5.0

(Note that the iso. in the first look-up means the same as the .1. that the reverse translate shows)

As noted in the comments, yes, you need the MIB installed in order to do these lookups, see your device vendor for the MIB file download. From what I've seen with a generic install of net-snmp, you get most of what you already are looking for.

Is the stack pre-allocated in a process?

Is the stack pre-allocated in a process?

On a stack-based architecture, a process will have stack space available to it from the beginning of its execution. That could be described as "pre-allocated". However, do note that in some contexts, it may be possible for a process's stack to be extended during the lifetime of the process. Perhaps that changes how you would view it?

In any case, that has little to do with whether the process of assigning storage space for automatic variables should be described as "allocation". Although it has technical implications, it is of little account linguistically that such space may be carved out of the stack, as opposed to out of some other area of memory controlled by the process. The lifetimes of such objects do obey different rules than the lifetimes of mallocated objects, but so what?

if I have a C program for example, that I only allocate two variables on the stack, it is right to say that I allocated or is it better to say that I just reused that space?

People are likely to understand you just fine either way. Although I'm sure there are some who would quibble over whether "allocate" is technically correct for automatic variables, it is nevertheless widely used for them. If you are conversing with people, as opposed to writing technical documentation to which the distinction is important, then I would not hesitate to use "allocate" to describe assigning storage space to automatic variables.

---

Related Topics