I am trying to add my own MIB-Module into a snmp agent, following this tutorial: http://www.net-snmp.org/wiki/index.php/TUT:Writing_a_MIB_Module
Now, I followed the tutorial step by step and doubled checked everything, searched a really long time but nothing helped me fixing my problem!
I am using net-snmp version 5.7.3
I implemented the following code into the net-snmp/agent/mibgroup directory:
#include <net-snmp/net-snmp-config.h>
#include <net-snmp/net-snmp-includes.h>
#include <net-snmp/agent/net-snmp-agent-includes.h>
#include "nstAgentModuleObject.h"
/*
* the variable we want to tie an OID to. The agent will handle all
** GET and SET requests to this variable changing it's value as needed.
*/
static long nstAgentModuleObject = 42;
/*
* our initialization routine, automatically called by the agent
* (to get called, the function name must match init_FILENAME())
*/
void
init_nstAgentModuleObject(void)
{
static oid nstAgentModuleObject_oid[] =
{ 1, 3, 6, 1, 4, 1, 8072, 2, 4, 1, 1, 1, 0 };
/*
* a debugging statement. Run the agent with -DnstAgentModuleObject to see
* the output of this debugging statement.
*/
DEBUGMSGTL(("nstAgentModuleObject",
"Initializing the nstAgentModuleObject module\n"));
/*
* the line below registers our variables defined above as
* accessible and makes it writable. A read only version of any
* of these registration would merely call
* register_read_only_int_instance() instead. The functions
* called below should be consistent with your MIB, however.
*/
DEBUGMSGTL(("nstAgentModuleObject",
"Initalizing nstAgentModuleObject scalar integer. Default value = %d\n",
nstAgentModuleObject));
netsnmp_register_long_instance("nstAgentModuleObject",
nstAgentModuleObject_oid,
OID_LENGTH(nstAgentModuleObject_oid),
&nstAgentModuleObject, NULL);
DEBUGMSGTL(("nstAgentModuleObject",
"Done initalizing nstAgentModuleObject module\n"));
}
I ran ./configure --with-mib-modules="nstAgentModuleObject", followed by make and make install. So the nstAgentModuleObject should be integrated in the snmpd agent.
The associated MIB NET-SNMP-TUTORIAL-MIB is saved in /usr/local/snmp/mbis, as well as /~/.snmp/mibs.
I added mibs +ALL in the snmpd.conf to make sure the MIB is loaded correctly. Also I used export MIBS=+all, just in case another .conf is read which should not be the case.
Using following commands I get the results shown below:
snmptranslate -Of NET-SNMP-TUTORIAL-MIB:nstAgentModuleObject
.iso.org.dod.internet.private.enterprises.netSnmp.netSnmpExamples.netSnmpTutorialMIB.nstMIBObjects.nstAgentModulesObject
snmptranslate -On NET-SNMP-TUTORIAL-MIB:nstAgentModuleObject
.1.3.6.1.4.1.8072.2.4.1.1.1
Now, running snmpget with the specified OID gives me this error(appending a 0 on the end since its a scalar. Results in the same error without it as well).
snmpget -v2c -c public localhost .1.3.6.1.4.1.8072.2.4.1.1.1.0
NET-SNMPEXAMPLES-MIB::netSnmpExamples.4.1.1.1.0 = No Such Object availaible on this agent at this OID
It seems like the MIB-module is not properly build-in to the agent, but I can't think of a reason why.
I know the same question has been posted before here, but it didn't receive any answer.(snmpget returns "No Such Object available on this agent at this OID")
So I want to try my luck and hope someone can help me out!
I had the exact same issue,
It didn't work with 5.6.2.
How I solved it:
I've upgraded to 5.7.3 , then it started working.
you need to take care for the following:
configure the package (on build) to support agentx) with --with-mib-modules=agentx
this is my configure:
./configure --prefix=/usr --build=i386-linux --host=arm-linux --target=arm-linux --with-ar=arm-arago-linux-gnueabi-ar --with-cc=arm-arago-linux-gnueabi-gcc --with-ld=arm-arago-linux-gnueabi-ld --with-cflags="-O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp" --with-endianness=big --with-ldflags=-Bstatic --enable-mini-agent --with-mib-modules="mibII ip-mib if-mib tcp-mib udp-mib ucd_snmp target agent_mibs notification-log-mib snmpv3mibs notification agentx" --without-openssl --without-perl-modules --disable-embedded-perl --disable-shared --with-default-snmp-version="2" --with-sys-contact="root" --with-sys-location="unknown" --with-logfile="/var/log/snmpd.log" --with-persistent-directory="/var/net-snmp" --disable-manuals
add agentx to snmpd.conf
This is my snmpd.config
master agentx
rocommunity public rwcommunity private
com2sec readonly default public
com2sec readwrite default private
started snmpd with debug, to give more details:
snmpd -f -Lo: -Dagentx
Then start the agentx application
The following tutorial also helped:
http://net-snmp.sourceforge.net/wiki/index.php/TUT:Writing_a_Subagent
I don't think you need to include the trailing 0 when you create your OID array. I use netsnmp_create_handler_registration in my code base instead of netsnmp_register_long_instance, but this is what I generally do.
static oid nstAgentModuleObject_oid[] = { 1, 3, 6, 1, 4, 1, 8072, 2, 4, 1, 1, 1 };
Related
I am trying to put together and example of coding inline assembly code in a 'C' program. I have not had any success. I am using GCC 4.9.0. As near as I can tell my syntax is correct. However the build blows up with the following errors:
/tmp/ccqC2wtq.s:48: Error: syntax error; found `(', expected `,'
Makefile:51: recipe for target 'all' failed
/tmp/ccqC2wtq.s:48: Error: junk at end of line: `(31)'
/tmp/ccqC2wtq.s:49: Error: syntax error; found `(', expected `,'
/tmp/ccqC2wtq.s:49: Error: junk at end of line: `(9)'
These are related to the input/output/clobbers lines in the code. Anyone have an idea where I went wrong?
asm volatile("li 7, %0\n" // load destination address
"li 8, %1\n" // load source address
"li 9, 100\n" // load count
// save source address for return
"mr 3,7\n"
// prepare for loop
"subi 8,8,1\n"
"subi 9,9,1\n"
// perform copy
"1:\n"
"lbzu 10,2(8)\n"
"stbu 10,2(7)\n"
"subi 9,9,1\n" // Decrement the count
"bne 1b\n" // If zero, we've finished
"blr\n"
: // no outputs
: "m" (array), "m" (stringArray)
: "r7", "r8"
);
It's not clear what you are trying to do with the initial instructions:
li 7, %0
li 8, %1
Do you want to load the address of the variables into those registers? In general, this is not possible because the address is not representable in an immediate operand. The easiest way out is to avoid using r7 and r8, and instead use %0 and %1 directly as the register names. It seems that you want to use these registers as base addresses, so you should use the b constraint:
: "b" (array), "b" (stringArray)
Then GCC will take care of the details of materializing the address in a suitable fashion.
You cannot return using blr from inline assembler because it's not possible to tear down the stack frame GCC created. You also need to double-check the clobbers and make sure that you list all the things you clobber (including condition codes, memory, and overwritten input operands).
I was able to get this working by declaring a pair of pointers and initializing them with the addresses of the arrays. I didn't realize that the addresses wouldn't be available directly. I've used inline assembly very sparsely in the past, usually just
to raise or lower interrupt masks, not to do anything that references variables. I just
had some folks who wanted an example. And the "blr" was leftover when I copied a
snipet of a pure assembly routine to use as a starting point. Thanks for the responses.
The final code piece looks like this:
int main()
{
char * stringArrayPtr;
unsigned char * myArrayPtr;
unsigned char myArray[100];
stringArrayPtr = (char *)&stringArray;
myArrayPtr = myArray;
asm volatile(
"lwz 7,%[myArrayPtr]\n" // load destination address
"lwz 8, %[stringArrayPtr]\n" // load source address
"li 9, 100\n" // load count
"mr 3,7\n" // save source address for return
"subi 8,8,1\n" // prepare for loop
"subi 9,9,1\n"
"1:\n" // perform copy
"lbzu 10,1(8)\n"
"stbu 10,1(7)\n"
"subic. 9,9,1\n" // Decrement the count
"bne 1b\n" // If zero, we've finished
// The outputs / inputs / clobbered list
// No output variables are specified here
// See GCC documentation on extended assembly for details.
:
: [stringArrayPtr] "m" (stringArrayPtr), [myArrayPtr]"m"(myArrayPtr)
: "7","8","9","10"
);
}
I am following the foo example given in the wireshark documentation.
I am able to build the foo code plugin. I am using wireshark 3.0.1 version. In the workroot folder, I have updated the target - PLUGIN_SRC_DIRS - plugins/epan/foo just before gryphon.
I can see that my code builds because I got some compilation error which I was able to fix it.
My foo code lives inside the plugins/epan folder.
I am running custom wireshark - sudo ./run/wireshark
There is a surprise here that I can't see even gryphon protocol field in the running wireshark. So in order to test this, I am typing foo or gryphon in that display filter and it turns red and it say foo is neither a protocol nor a protocol field. I am using Ubuntu 16.04 LTS to build it. The build goes fine.
Here is packet-foo.c
#include "config.h"
#include <epan/packet.h>
#include "packet-foo.h"
static int proto_foo = -1;
static int dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree _U_, void *data _U_);
void
proto_register_foo(void)
{
proto_foo = proto_register_protocol (
"FOO Protocol", /* name */
"FOO", /* short name */
"foo" /* abbrev */
);
}
void
proto_reg_handoff_foo(void)
{
static dissector_handle_t foo_handle;
foo_handle = create_dissector_handle(dissect_foo, proto_foo);
dissector_add_uint("udp.port", FOO_PORT, foo_handle);
}
static int
dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree _U_, void *data _U_)
{
col_set_str(pinfo->cinfo, COL_PROTOCOL, "FOO");
/* Clear out stuff in the info column */
col_clear(pinfo->cinfo,COL_INFO);
return tvb_captured_length(tvb);
}
Here is the packet-foo.h
#define FOO_PORT 1234
The CMakeLists.txt is here, this is actually a copy of gryphon.
So, I am wondering if gryphon wasn't recognised that means foo won't be recognised too. So, this file might be a source of problem.
include(WiresharkPlugin)
# Plugin name and version info (major minor micro extra)
set_module_info(foo 0 0 4 0)
set(DISSECTOR_SRC
packet-foo.c
)
set(PLUGIN_FILES
plugin.c
${DISSECTOR_SRC}
)
set_source_files_properties(
${PLUGIN_FILES}
PROPERTIES
COMPILE_FLAGS "${WERROR_COMMON_FLAGS}"
)
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
register_plugin_files(plugin.c
plugin
${DISSECTOR_SRC}
)
add_plugin_library(foo epan)
target_link_libraries(foo epan)
install_plugin(foo epan)
file(GLOB DISSECTOR_HEADERS RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}" "*.h")
CHECKAPI(
NAME
foo
SWITCHES
-g abort -g termoutput -build
SOURCES
${DISSECTOR_SRC}
${DISSECTOR_HEADERS}
)
Merely changing the plugin isn't sufficient.
You need to modify the top make file so that foo is actually installed.
vim CMakeListsCustom.txt.example
Firstly, uncomment - line number 16
plugins/epan/foo
Since your foo lives inside plugins/epan/foo
Now, rename this example to
mv CMakeListsCustom.txt.example CMakeListsCustom.txt
vim CMakeLists.txt
Insert a line number around 1408-
plugins/epan/foo
After that, do make
and then sudo make install
Here is the working copy -
https://github.com/joshis1/WiresharkDissectorFoo
I am trying to go through the OGRE's tutorial #2.
I successfully went trough the first part.
My problem is when I try to compile I get an error in this method:
void TutorialApplication::createScene(void){
mSceneMgr->setAmbientLight(Ogre::ColourValue(1.0, 1.0, 1.0));
mSceneMgr->setShadowTechnique(Ogre::SHADOWTYPE_STENCIL_ADDITIVE);
Ogre::Entity* entNinja = mSceneMgr->createEntity("Ninja", "ninja.mesh");
entNinja->setCastShadows(true);
Ogre::SceneNode* headNode = mSceneMgr->getRootSceneNode()->createChildSceneNode("HeadNode");
headNode->attachObject(entNinja);
Ogre::Plane plane(Ogre::Vector3::UNIT_Y, 0);
Ogre::MeshManager::getSingleton().createPlane("ground", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME,
plane, 1500, 1500, 20, 20, true, 1, 5, 5, Ogre::Vector3::UNIT_Z);
Ogre::Entity* entGround = mSceneMgr->createEntity("GroundEntity", "ground");
mSceneMgr->getRootSceneNode()->createChildSceneNode()->attachObject(entGround);
entGround->setCastShadows(false);
entGround->setMaterialName("Examples/Rockwall");
}
The error I get is:
error: incomplete type 'Ogre::MeshManager' used in nested name
specifier
Ogre::MeshManager::getSingleton().createPlane("ground", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME,
Which is weird, because apparently anybody is having problems with this tutorial. I am using Ogre 1.9 which I compiled in my machine (Ubuntu 14.04 x64).
If you add the following include into your code, it should work. The reason for your issue might be, that the respective tutorial has not been updated to match Ogre 1.9.
#include <OgreMeshManager.h>
I have written a simple kernel module which allocates objects using the slab layer. This module uses kernel API's (kmem_cache_{create,alloc,free}). The version of the kernel I am working on 3.15.4-200.
Though, my code works as expected with no issues, I am unable to see the new object/slab "my_cache" created using kmem_cache_create() when I grep /proc/slabinfo. The objects created are a simple list of objects, being inserted or removed from the list.
Note: My module works fine with no issues. I can view the slab creating under, /sys/kernel/slab/my_cache, but not in /proc/slabinfo or vmstat -m or slabtop
mycache = kmem_cache_create("my_cache",
sizeof(struct mystruct),
0, SLAB_HWCACHE_ALIGN, NULL);
if (mycache == NULL)
return -ENOMEM;
`
$ sudo cat /sys/kernel/slab/my_cache/objects
49108 N0=49108
$ sudo cat /sys/kernel/slab/my_cache/object_size
64
$ sudo cat /sys/kernel/slab/my_cache/order
0
$ sudo cat /sys/kernel/slab/my_cache/aliases
12
$ sudo cat /sys/kernel/slab/my_cache/cache_dma
0
$ sudo cat /sys/kernel/slab/my_cache/slab_size
64
$ sudo cat /sys/kernel/slab/my_cache/trace
0
$ sudo cat /sys/kernel/slab/my_cache/validate
$ sudo cat /sys/kernel/slab/my_cache/total_objects
49920 N0=49920
`
kmem_cache_create usually tries to merge this cache with other caches. So for example if it found another cache for the same size with the same properties ( slab is going to be poisoned, etc ) it will just use this cache instead of creating a new cache.
If you really want to make sure that it'll definitely create a new cache for you ( = appear in slabinfo ), you can always pass a valid constructor to kmem_cache_create. Something like this:
static void mystruct_constructor(void *addr)
{
memset(addr, 0, sizeof(struct mystruct));
}
mycache = kmem_cache_create("my_cache",
sizeof(struct mystruct),
0, 0, mystruct_constructor);
A constructor is usually called for every object allocation from this cache.
passing the additional flag SLAB_POISON solves the issue.
from link SLAB_POISON - Poison the slab with a known test pattern (a5a5a5a5) to catch references to uninitialised memory.
I am trying to call cudppSort to sort a set of keys/values. I'm using the following code to set up the sort algorithm:
CUDPPConfiguration config;
config.op = CUDPP_ADD;
config.datatype = CUDPP_UINT;
config.algorithm = CUDPP_SORT_RADIX;
config.options = CUDPP_OPTION_KEY_VALUE_PAIRS | CUDPP_OPTION_FORWARD | CUDPP_OPTION_EXCLUSIVE;
CUDPPHandle planHandle;
CUDPPResult result = cudppPlan(&planHandle, config, number_points, 1, 0);
if (CUDPP_SUCCESS != result) {
printf("ERROR creating CUDPPPlan\n");
exit(-1);
}
The program exits, however on the line:
CUDPPResult result = cudppPlan(&planHandle, config, number_points, 1, 0);
and prints to stdout:
Cuda error: allocScanStorage in file 'c:/the/path/to/release1.1/cudpp/src/app/scan_app.cu' in line 279 : invalid configuration argument.
I looked at the line in scan_app.cu. It is,
CUT_CHECK_ERROR("allocScanStorage");
So apparently my configuration has an error that is causing the allocScanStorage to bomb out. There are only two calls to CUDA_SAFE_CALL in the function and I don't see a reason why either has anything to do with the configuration.
What is wrong with my configuration?
So that this doesn't sit around as an unanswered question (I'm not sure if this is the right SO etiquette but it seems like an answered question shouldn't sit around unanswered...), I'm copying the comment I made above here as an answer since it was the solution:
I figured this out (I'm still learning CUDA at the moment.) Because the error checking is asynchronous errors can show up in strange places if you don't check for them from time to time. My code had caused an error before I called cudppPlan but because I didn't check for errors the cudppPlan reported the error as if it was in cudppPlan.