Re: not able to receive SNMPv3 traps for SHA, and priv users
Hello, I have got the solution to this problem. The problem was that for configuring SNMPv3 traps, i was adding below in the snmpd.conf file: trapsess -u username -l security level host IP It was working well for MD5, but for SHA auth and priv (both DES AES) it was sending a trap , but it was getting error which receiving at the manager saying that authentication (for SHA) or decryption (for MD5 + DES/AES) failure. If we are configuring the 'trapsess' with the engine-id then it is working well for all these auth (MD5,SHA) and priv (DES, AES), as below: trapsess -e engine-id -u username -l security level host IP thanks and regards S Sarath From: sarath azad saraths...@yahoo.co.in To: net-snmp-us...@lists.sourceforge.net net-snmp-us...@lists.sourceforge.net; net-snmp-coders@lists.sourceforge.net net-snmp-coders@lists.sourceforge.net Sent: Friday, September 27, 2013 10:41 AM Subject: not able to receive SNMPv3 traps for SHA, and priv users Hello, I am using net-snmp version 5.4.2.1. I am able to send traps for SNMPv3 users for authentication with MD5 and receive them properly by the manager software. But while sending traps with authentication SHA or using SNMPv3 users with encryption, I am not able to receive them at the manager. I have tried to capture the traffic from my device, and I could see these traps (SHA and encrypted) being sent from the device, but these are not getting received by the manager software. I have tried with couple of management software, like net-snmp's snmptrapd, and ManageEngine MibBrowser free tool 5.0. In both of them I only able to receive MD5 user's traps only. Though SNMPv2 traps are getting properly received. Also the user config, are done in same way for both MD5 user and SHA user on the snmptrapd.conf file. Please advise how to solve the problem. thanks and regards S Sarath -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fwd: C++ Trouble
I took Magnus' advice and saved the intermediate C files, comparing the one
generated for the C version vs the one for C++. As it turns out, for
whatever reason, the C++ version was missing the call to init_my_OID()
SO I added the call where it should be and produced .o's for the
intermediate and cpp, then used g++ to link them. The resulting sub-agent
would run and get into its handle_xxx()/MODE_GET until a C++ library method
threw an exception and the entire thing crashed. It did not even make it
to its defined handler or the catch(...) which leads me to thing that that
is due to mixed mode linkages (nothing relating to net-snmp). Long story
short: this most probably can be resolved but I can't waste any more time
on getting the net-snmp sub-agents to work in a C++ environment. If
someone has a very quick solution I could put some time aside to try it,
but otherwise I'll just restrict my work to C only (ick).
tack själv! Magnus!
On Thu, Oct 3, 2013 at 9:57 PM, Magnus Fromreide ma...@lysator.liu.sewrote:
On Thu, 2013-10-03 at 14:42 -0400, Frozen Puck wrote:
I have the most basic, simple starter sub-agent which simply outputs a
hard-coded string (for now), which works fine when compiled as a C
module:
# net-snmp-config --compile-subagent Ctest sinIDENT.c
(compiles cleanly)
# ./Ctest
# snmpget -v 1 -c public localhost sinIDENT.0
# SIN-TOP-LEVEL-0::sinIDENT.0 = STRING: ZQXA
(all's well)
(kill Ctest)
HOWEVER, if I rename that same module to sinIDENT.cpp and compile:
# net-snmp-config --compile-subagent CppTest --cflags -lstdc++
sinIDENT.cpp
(compiles cleanly)
# ./CppTest
# snmpget -v 1 -c public localhost sinIDENT.0
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: NAVCAN-CNS-SIN-TOP-LEVEL-0::sinIDENT.0
My first thought was that there was fname mangling going on so I made
sure that the header prevents that:
#ifndef SINIDENT_H
#define SINIDENT_H*/
#ifdef __cplusplus
extern C {
#endif
/* function declarations */
void init_sinIDENT(void);
Netsnmp_Node_Handler handle_sinIDENT;
#ifdef __cplusplus
}
#endif
#endif /* SINIDENT_H */
And double checked the names:
# nm Ctest | grep sin
08049770 T handle_sinIDENT
080497c0 T init_sinIDENT
#
# nm CppTest |grep sin (showing mangled non-C-calling-convention)
08049b80 t _GLOBAL__I_init_sinIDENT
0804b080 r _ZZ13init_sinIDENTE5C.161
0804b060 r _ZZ13init_sinIDENTE8__func__
08049c60 T handle_sinIDENT
08049bb0 T init_sinIDENT
I have NO IDEA why the C++ version returns a failure. Please Help, I
don't want to be restricted to 20 year old C!
The problem is that the generator expects to work with C code.
If you run the generator for both cases with the --norm flag that makes
it leave the temporary file it generates you will see that the actual
difference is that the C version calls init_sinIDENT (and includes the
sinIDENT.h header).
If you try the version that calls the init routine I expect it to work,
does it?
One could imagine an additional flag to --compile-subagent that lists
init_/shutdown_ routines it should look for in addition to the
automatically generated... but I am unsure about that being enough.
/MF
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fwd: C++ Trouble
On Fri, 2013-10-04 at 09:31 -0400, Frozen Puck wrote: I took Magnus' advice and saved the intermediate C files, comparing the one generated for the C version vs the one for C++. As it turns out, for whatever reason, the C++ version was missing the call to init_my_OID() SO I added the call where it should be and produced .o's for the intermediate and cpp, then used g++ to link them. The resulting sub-agent would run and get into its handle_xxx()/MODE_GET until a C++ library method threw an exception and the entire thing crashed. It did not even make it to its defined handler or the catch(...) which leads me to thing that that is due to mixed mode linkages (nothing relating to net-snmp). Long story short: this most probably can be resolved but I can't waste any more time on getting the net-snmp sub-agents to work in a C++ environment. If someone has a very quick solution I could put some time aside to try it, but otherwise I'll just restrict my work to C only (ick). Well, that is one of the bad parts of interfacing C and C++, you can't throw through C code without extra care - in the case of GCC I think the extra care is spelled -fexception but you need to apply it to the build of the Net-SNMP libraries, and you are still likely to trigger resource leaks in the C part. With that said I admit to using the Net-SNMP libraries from C++ myself. I assume that catching everything in your handler functions, and thus not throwing through the C parts, is unfeasible for you? tack själv! Magnus! Lycka till. /MF -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Trouble in converting PhysAdress to OctetString
Your solution resolve my problem partially, I have success to print the
value but my real objective is save the value in a buffer, and when i try
do this, with your method, i don't have success. The printf line is just to
verify the saved value.
About the memory allocated, i think this resolve
size_t test = 64;
int *sp = malloc(test);
memcpy(sp, vars-val.string, vars-val_len);
int *teste = htonl(*sp);
printf(value #%d is a string: %x \n, count++, teste);
free(sp);
2013/10/3 Magnus Fromreide ma...@lysator.liu.se
On Thu, 2013-10-03 at 18:14 +, Rafael Ratacheski wrote:
Hello, I'm having troubles in request and save the value of the
ipNetToMediaPhysAddress OID.
My routine get the MAC Adress, but only a half of the value.
What I'm doing wrong? Can you help me?
if (vars-type == ASN_OCTET_STR) {
u_long *sp = malloc(1+id_len);
What is the value of id_len? I'll guess it is 6 for further analysis.
In that case you have just allocated 7 bytes of memory for a 32-bit
unsigned integer (or a 64-bit one - even worse...)
memcpy(sp, vars-val.string, id_len);
You then copy the six bytes of the mac address to the newly allocated
memory. This is actually correct, but rather odd given the types.
const char *teste = htonl(*sp);
And then you assign the byte swapped value of the first four octets of
the mac address to the pointer variable teste. This is undefined
according to the C standard.
printf(value #%d is a string: %x \n, count++, teste);
Then you print the address that teste refers to,
free(sp);
Finally you frees the allocated memory. Good.
}
So, to answer your questions:
What am I doing wrong?
Just about everything.
Can you help me?
Well...
I would write that snippet as
if (vars-type == ASN_OCTET_STR) {
int i;
printf(value #%d is a string: , count++);
for (i = 0; i vars-val_len; ++i)
printf(%x, vars-val.string[i]);
puts();
}
(Ok, I probably would put it in a char buffer and print it all at once
rather than repeatedly call printf but this is the easy version)
... but that probably isn't what you really wanted to know.
/MF
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Trouble in converting PhysAdress to OctetString
On Fri, 2013-10-04 at 18:13 +, Rafael Ratacheski wrote:
Your solution resolve my problem partially, I have success to print
the value but my real objective is save the value in a buffer, and
when i try do this, with your method, i don't have success. The printf
line is just to verify the saved value.
About the memory allocated, i think this resolve
size_t test = 64;
int *sp = malloc(test);
memcpy(sp, vars-val.string, vars-val_len);
Kind of. You are allocating 64 bytes to store a 6-byte value.
int *teste = htonl(*sp);
Why are you insisting on byteswapping the first four bytes of the value?
Why are you insisting on storing them in a pointer??? (not in the
pointed to value, in the pointer!)
printf(value #%d is a string: %x \n, count++, teste);
Here you are only trying to print the first four bytes of the value. I
suppose that is the reason for the last two bytes to not be visible.
free(sp);
void printbuf(const void* buf, size_t buflen)
{
const unsigned char* bp = (const unsigned char*)buf;
while (buflen--)
printf(%02x, *bp++);
}
...
printfbuf(vars-val.string, vars-val_len);
puts();
char *sp = malloc(vars-val_len);
memcpy(sp, vars-val.string, vars-val_len);
printbuf(sp, vars-val_len);
puts();
free(sp);
/MF
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Trouble in converting PhysAdress to OctetString
It works very well. thank you
2013/10/4 Magnus Fromreide ma...@lysator.liu.se
On Fri, 2013-10-04 at 18:13 +, Rafael Ratacheski wrote:
Your solution resolve my problem partially, I have success to print
the value but my real objective is save the value in a buffer, and
when i try do this, with your method, i don't have success. The printf
line is just to verify the saved value.
About the memory allocated, i think this resolve
size_t test = 64;
int *sp = malloc(test);
memcpy(sp, vars-val.string, vars-val_len);
Kind of. You are allocating 64 bytes to store a 6-byte value.
int *teste = htonl(*sp);
Why are you insisting on byteswapping the first four bytes of the value?
Why are you insisting on storing them in a pointer??? (not in the
pointed to value, in the pointer!)
printf(value #%d is a string: %x \n, count++, teste);
Here you are only trying to print the first four bytes of the value. I
suppose that is the reason for the last two bytes to not be visible.
free(sp);
void printbuf(const void* buf, size_t buflen)
{
const unsigned char* bp = (const unsigned char*)buf;
while (buflen--)
printf(%02x, *bp++);
}
...
printfbuf(vars-val.string, vars-val_len);
puts();
char *sp = malloc(vars-val_len);
memcpy(sp, vars-val.string, vars-val_len);
printbuf(sp, vars-val_len);
puts();
free(sp);
/MF
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
