Menu
▾
▴
opensnmp-bugs — This list is populated by bugs added to the opensnmp projects.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2003-03-03 18:22:14
|
Bugs item #496015, was opened at 2001-12-21 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111101&aid=496015&group_id=11101 Category: General Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Baer (baerm) Summary: Test Scripts for CR and CG Initial Comment: When I try to run the CG script cg_auth_cr the CR segment faults. I am using your newest code from the CVS tree and I run the CR with the cr script in the test directory. Actually when I try to run any of the scripts, except cg_noAuth_cr, I get a segment fault in the CR. The cg_noAuth_cr gets the correct information, but then the CG (not the CR) segment faults. Any ideas?? Is there something I need to set up for the CR to recieve encrypted messages? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111101&aid=496015&group_id=11101 |
|
From: SourceForge.net <no...@so...> - 2003-03-03 18:22:14
|
Bugs item #454788, was opened at 2001-08-23 17:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111101&aid=454788&group_id=11101 Category: General Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Baer (baerm) Summary: GCC cant find DIRS Initial Comment: When useing make I encounter these errors: From GCC 3.0: OctetString *, OID *, OctetString *, OID *, OctetString *)': snmpUSMData.C:100: Internal compiler error in find_function_data, at function.c:326 Please submit a full bug report. I get a ton of these errors: make[2]: *** No rule to make target `../../base/libsnmpbase.a', needed by `snmp-db-dump'. Stop. ---------------------------------------------------------------------- Comment By: Michael Baer (baerm) Date: 2001-08-24 08:21 Message: Logged In: YES user_id=70433 hmmm, gcc should be compatible. I know earlier (say <= 2.95.3) versions have worked because I've used them and gcc is the compiler that all the developers use. I just don't have any experience using 3.0 (although, usually when I think the compiler is at fault, I'm wrong and there is something else going on :{) So can I get more information on the problem? Which version of OpenSNMP are you using? 0.3 (newest), 0.2, cvs, etc... Which version of openssl?, berkeley db?, and libsmi? What platform are you using? (intel redhat 7.1, linuxppc,...) And maybe the output of make, up to the 'no rule to make' errors. Unless you prefer the bug-list webpage, you could also send the info directly to me, ba...@us... or to the users list, ope...@li... . (I tend to find the bug-list webpage awkward to use for long messages) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-23 18:17 Message: Logged In: NO Well I also tried it with my older version of GCC, what should I be useing? I dident know GCC wasent compatable. ---------------------------------------------------------------------- Comment By: Michael Baer (baerm) Date: 2001-08-23 17:40 Message: Logged In: YES user_id=70433 At first glance it looks like a problem with GCC 3.0 (I don't think anyone else has tried OpenSNMP with GCC 3.0, and functions.c is not in the OpenSNMP code base). That piece of code compiles fine with gcc 2.95.3 and is only a parameter in a function call? (at least with the 0.3 version). The 'no rule to make... libxxx.a' errors are due to the required libraries not being created because of the previous error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111101&aid=454788&group_id=11101 |
|
From: SourceForge.net <no...@so...> - 2003-03-03 18:21:01
|
Bugs item #695959, was opened at 2003-03-02 03:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111101&aid=695959&group_id=11101 >Category: General Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: jeremie banier (opposummerbeach) >Assigned to: Michael Baer (baerm) Summary: IpAddress encoding is wrong Initial Comment: when I try to encode the following IP "10.4.16.106" you will the following result 10.4.4.4 that is not the expected result ;-) here is a fix for the constructor methods that takes a char* <snip> EraseData(); string data_string; char *tmp_string = new char[4]; int index, oldindex; index = ns.find("."); oldindex = 0; for(int i=0; i < 4; i++) { tmp_string[i] = (char) atoi(ns.substr(oldindex, index - oldindex).data()); oldindex = index +1; index = ns.find(".", oldindex +1); } data_string.assign(tmp_string,4); <snip> this one behave as expected. Ps: I've seen another "bug" there is no trap-pdu (yet?) I'll send the fix as soon as it's working and clean ;-) Cheers, Oppo. ---------------------------------------------------------------------- >Comment By: Michael Baer (baerm) Date: 2003-03-03 10:31 Message: Logged In: YES user_id=70433 Thanks, a fix has been added. It should be noted though that IpAddress generally shouldn't be used, e.g. for an old MIB that has it. (if I can remember which rfc it is in), rfc2578: "Note that the IpAddress type is a tagged type for historical reasons. Network addresses should be represented using an invocation of the TEXTUAL-CONVENTION macro" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111101&aid=695959&group_id=11101 |
|
From: SourceForge.net <no...@so...> - 2003-03-02 11:45:43
|
Bugs item #695959, was opened at 2003-03-02 12:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111101&aid=695959&group_id=11101 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: jeremie banier (opposummerbeach) Assigned to: Nobody/Anonymous (nobody) Summary: IpAddress encoding is wrong Initial Comment: when I try to encode the following IP "10.4.16.106" you will the following result 10.4.4.4 that is not the expected result ;-) here is a fix for the constructor methods that takes a char* <snip> EraseData(); string data_string; char *tmp_string = new char[4]; int index, oldindex; index = ns.find("."); oldindex = 0; for(int i=0; i < 4; i++) { tmp_string[i] = (char) atoi(ns.substr(oldindex, index - oldindex).data()); oldindex = index +1; index = ns.find(".", oldindex +1); } data_string.assign(tmp_string,4); <snip> this one behave as expected. Ps: I've seen another "bug" there is no trap-pdu (yet?) I'll send the fix as soon as it's working and clean ;-) Cheers, Oppo. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111101&aid=695959&group_id=11101 |
|
From: <no...@so...> - 2001-12-22 01:02:50
|
Bugs item #496015, was opened at 2001-12-21 17:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=111101&aid=496015&group_id=11101 Category: General Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Test Scripts for CR and CG Initial Comment: When I try to run the CG script cg_auth_cr the CR segment faults. I am using your newest code from the CVS tree and I run the CR with the cr script in the test directory. Actually when I try to run any of the scripts, except cg_noAuth_cr, I get a segment fault in the CR. The cg_noAuth_cr gets the correct information, but then the CG (not the CR) segment faults. Any ideas?? Is there something I need to set up for the CR to recieve encrypted messages? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=111101&aid=496015&group_id=11101 |
