Menu
▾
▴
net-snmp-coders
|
From: <ni...@ba...> - 2000-11-21 22:29:37
|
On 21 Nov 2000 18:19:31 +0100 Frank Strauss <st...@ib...> wrote: >Wes> However (Niels), it doesn't seem to work genericly, which is a >Wes> problem (even if its illegal and doesn't make sense... We shouldn't >Wes> force the requirement of knowledge about the mib in question): > >Wes> 8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\" >Wes> Unknown object identifier: system."blue" That was not intended, I will fix it (although I have difficulty seing the use for it) >Yes. This seems to be my problem. In case of VACM configurations we >would need the generic behavior. Please explain to me why you would need it /Niels -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su |
|
From: <ni...@ba...> - 2000-11-21 22:54:55
|
On 21 Nov 2000 06:44:28 -0800 Wes Hardaker <wjh...@uc...> wrote: >>>>>> On 21 Nov 2000 22:29:34 -0000, ni...@ba... (Niels Baggesen) said: > >Wes> 8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\" >Wes> Unknown object identifier: system."blue" > >Niels> That was not intended, I will fix it (although I have >Niels> difficulty seing the use for it) > >That wasn't a good example. A better example would be a table that I >don't have a mib for (possibly because it hasn't been written to match >the code for yet). I'd certainly want to be able to easily index oids >based on values even though the first half of them were entirely >numeric. Now youre talking buziness. Yes, it should of course not require you to have the mib file. I will investigate that. /Niels -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su |
|
From: <ni...@ba...> - 2000-11-21 23:20:34
|
On 21 Nov 2000 06:44:28 -0800 Wes Hardaker <wjh...@uc...> wrote: >That wasn't a good example. A better example would be a table that I >don't have a mib for (possibly because it hasn't been written to match >the code for yet). I'd certainly want to be able to easily index oids >based on values even though the first half of them were entirely >numeric. Like this? $ apps/snmptranslate 99.13.14.\"guf\".8 .1.3.6.1.2.1.99.13.14.3.103.117.102.8 $ /Niels -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su |
|
From: Frank S. <st...@ib...> - 2000-11-22 09:24:31
|
niels> Like this? niels> $ apps/snmptranslate 99.13.14.\"guf\".8 niels> .1.3.6.1.2.1.99.13.14.3.103.117.102.8 niels> $ Great! ;-) |
|
From: Frank S. <st...@ib...> - 2000-11-22 11:22:52
|
Juergen> So any code which does an automatic conversion based on a best guess Juergen> is just flawed. And this can have more than unpleasant side effects if Juergen> it is being used in a VACM configuration file. So please, don't do it. Does this mean, you'd prefer to use something like DISMAN-SCRIPT-MIB::smScriptObjects.0.0.0.5.103.165.101.115.116 ff:8f:c0 over DISMAN-SCRIPT-MIB::smScriptObjects.0.0.0."guest" ff:8f:c0 ? (This example uses wildcarding to address multiple tables under smScriptObjects. Hence, it is generically impossible for the agent to guess `the' indexing scheme.) |
|
From: Juergen S. <sc...@ib...> - 2000-11-22 12:02:15
|
>>>>> Frank Strauss writes: Juergen> So any code which does an automatic conversion based on a Juergen> best guess is just flawed. And this can have more than Juergen> unpleasant side effects if it is being used in a VACM Juergen> configuration file. So please, don't do it. Frank> Does this mean, you'd prefer to use something like Frank> DISMAN-SCRIPT-MIB::smScriptObjects.0.0.0.5.103.165.101.115.116 Frank> ff:8f:c0 Frank> over Frank> DISMAN-SCRIPT-MIB::smScriptObjects.0.0.0."guest" ff:8f:c0 Frank> ? (This example uses wildcarding to address multiple tables Frank> under smScriptObjects. Hence, it is generically impossible for Frank> the agent to guess `the' indexing scheme.) If you write DISMAN-SCRIPT-MIB::smScriptObjects.0.0.0."guest", then I would expect that a good implementation reports an error since it is ambiguous what it means. On the other hand, if you write something like DISMAN-SCRIPT-MIB::MIB!smScriptDescr."guest", then a good implementation can expand this without ambiguities to 1.3.6.1.2.1.64.1.3.1.1.3.5.103.165.101.115.116. The fact that you want to do wildcarding tricks here (since there are several MIB tables with the same indexing structure) is the subject of the second argument ff:8f:c0. From a VACM perspective, 1.3.6.1.2.1.64.1.3.1.1.3.5.103.165.101.115.116 ff:8f:c0 and 1.3.6.1.2.1.64.1.3.0.0.0.5.103.165.101.115.116 ff:8f:c0 are semantically equivalent. /js -- Juergen Schoenwaelder Technical University Braunschweig <sc...@ib...> Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/> |
|
From: Dave S. <D.T...@cs...> - 2000-11-23 09:25:41
|
Wes> And, anyway, we're *not* coming up with a random number Wes> assignment. We're coming up with the translation that the user Wes> asked for: Wes> ...foo -> unknown object identifier Wes> ..."foo" -> ...3.102.111.111 Wes> ...'foo' -> ...102.111.111 Juergen> OK. I did not know at the beginning of this thread that the 'foo' Juergen> conversion exists in addition to the "foo" conversion. Me neither. I'm currently trawling through the old mailing lists, gathering together candidates for a revision of the FAQ. I'll add this to the list. What happens if the MIB *is* loaded, and specifies implicit encoding (i.e. 'foo') but the user asks for "foo" (or vice versa)? Is this corrected on the fly, or does it generate an error? Dave |
|
From: Juergen S. <sc...@ib...> - 2000-11-23 09:45:44
|
>>>>> Dave Shield writes: Dave> What happens if the MIB *is* loaded, and specifies implicit Dave> encoding (i.e. 'foo') but the user asks for "foo" (or vice Dave> versa)? Is this corrected on the fly, or does it generate an Dave> error? Since you make the user responsible, you just do what the user asked for. You probably need a third syntax, e.g. `foo`, which has the semantics to do the right conversion or to complain if you can't do the right thing. (No, I do not really suggest to introduce these back quotes.) /js |
|
From: <ni...@ba...> - 2000-11-23 11:53:23
|
On Thu, 23 Nov 2000 09:26:58 +0000 Dave Shield <D.T...@cs...> wrote: >Me neither. >I'm currently trawling through the old mailing lists, gathering together >candidates for a revision of the FAQ. I'll add this to the list. > > > What happens if the MIB *is* loaded, and specifies implicit encoding >(i.e. 'foo') but the user asks for "foo" (or vice versa)? >Is this corrected on the fly, or does it generate an error? If the MIB is loaded, it will be done "the MIB way", i.e. it makes no difference what quoting you use. /Niels -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su |
|
From: Juergen S. <sc...@ib...> - 2000-11-23 12:02:49
|
>>>>> niels writes: niels> If the MIB is loaded, it will be done "the MIB way", i.e. it niels> makes no difference what quoting you use. I guess this is what I dislike. The fact that xxx."foo" and xxx.'foo' may mean different things depending on whether MIB information is available or not will confuse people - well it will at last confuse me. ;-) /js -- Juergen Schoenwaelder Technical University Braunschweig <sc...@ib...> Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/> |
|
From: Dave S. <D.T...@cs...> - 2000-11-23 12:16:55
|
niels> If the MIB is loaded, it will be done "the MIB way", i.e. it niels> makes no difference what quoting you use. Juergen> I guess this is what I dislike. The fact that xxx."foo" and xxx.'foo' Juergen> may mean different things depending on whether MIB information is Juergen> available or not will confuse people - well it will at last confuse Juergen> me. ;-) I concur. If the tool can tell from the MIB file that what the user requested is wrong, then it's quite reasonable to issue an error message. At a push, it *might* be justifiable to warn of the error, and use the correct format. But I don't think we should simply silently fix it. Dave |
|
From: <ni...@ba...> - 2000-11-23 14:31:10
|
On Thu, 23 Nov 2000 12:18:04 +0000 Dave Shield <D.T...@cs...> wrote: >If the tool can tell from the MIB file that what the user requested >is wrong, then it's quite reasonable to issue an error message. It is quite easy to do, so I might as well change it. I really also would like to have the possiblity of no-quotes => mib decides, but how do you then know what to do with the index 0 (is it the string "0", or does it mean a zero-length string specified by oid?) >At a push, it *might* be justifiable to warn of the error, and use >the correct format. We really have no "warning ways" out of the library, so it has to be fatal (or not checked) /Niels -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su |
|
From: Wes H. <wjh...@uc...> - 2000-11-27 22:20:16
|
>>>>> On 23 Nov 2000 14:31:05 -0000, ni...@ba... (Niels Baggesen) said: Niels> It is quite easy to do, so I might as well change it. I really Niels> also would like to have the possiblity of no-quotes => mib Niels> decides, but how do you then know what to do with the index 0 Niels> (is it the string "0", or does it mean a zero-length string Niels> specified by oid?) This would be my vote (and in fact I was also going to mention it) for how to do things. I'd like to see it translated without the quote requirements if the mib is present. Only if it isn't present would the user be required to enter quote marks to specify it as a string and not a node. As far as null length strings go, how about .. being equal to a null length string or oid segment? That makes the most sense to me. Now, if I can only get to a network node to send this today... -- Wes Hardaker Please mail all replies to net...@li... |
|
From: Wes H. <wjh...@uc...> - 2000-11-21 22:43:20
|
>>>>> On 21 Nov 2000 22:29:34 -0000, ni...@ba... (Niels Baggesen) said: Wes> 8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\" Wes> Unknown object identifier: system."blue" Niels> That was not intended, I will fix it (although I have Niels> difficulty seing the use for it) That wasn't a good example. A better example would be a table that I don't have a mib for (possibly because it hasn't been written to match the code for yet). I'd certainly want to be able to easily index oids based on values even though the first half of them were entirely numeric. For another example, see the ucd-snmp/proxy module and how its capable of re-locating remote oids into a different section of the local OID tree (since we have no context support currently, this is required to support multiple remote agents serving the same information). -- Wes Hardaker Please mail all replies to net...@li... |
|
From: Juergen S. <sc...@ib...> - 2000-11-22 10:25:05
|
In article <sde...@wa...> you wrote: >>>>>> On 21 Nov 2000 22:29:34 -0000, ni...@ba... (Niels Baggesen) said: > Wes> 8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\" > Wes> Unknown object identifier: system."blue" > Niels> That was not intended, I will fix it (although I have > Niels> difficulty seing the use for it) > That wasn't a good example. A better example would be a table that I > don't have a mib for (possibly because it hasn't been written to match > the code for yet). I'd certainly want to be able to easily index oids > based on values even though the first half of them were entirely > numeric. This is _NOT_ possible. You need to know how a table is indexed to form the instance identifier. In particular, you need to know whether a string is fixed length or not. If it is variable length, then you need to know whether an implied bit applies. So any code which does an automatic conversion based on a best guess is just flawed. And this can have more than unpleasant side effects if it is being used in a VACM configuration file. So please, don't do it. /js -- Juergen Schoenwaelder Technical University Braunschweig <sc...@ib...> Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/> |
|
From: Sergey I. Y. <ev...@na...> - 2000-11-22 14:19:40
|
Hi, I'm porting ucd-snmp to OS/2. During porting process some questions appeared and I'd like to know your opinions about it. First of all I'd like to have this port included with main distribution. How this can be done? Other issues are more technical: 1. I have found that entire package completely ignores possible problems with function calling convention used by different compilers. Although this unlikely a problem in most unixes, this may cause serious problems when parts of package compiled by one compiler while other parts with other. This issue can be resolved by adding to all function prototypes, function pointer members in structures and typedefs some symbol which may be defined to nothing on unix platforms or to something specific on OS/2 and Win32 (it also may suffer from this problem). Something like this: typedef int (*CALL_CONV snmp_callback) (int, struct snmp_session *, int, struct snmp_pdu *, void *); void CALL_CONV snmpv3_authtype_conf(const char *word, char *cptr); 2. Similar issue with alignment of structures. Although there is no standard way to accomplish this, I think that most current compilers recognizes and able to handle correctly #pragma pack() In either case compilers that don't recognize this pragma will just ignore it and nothing bad happens. If to use this approach then each header will have (snmpv3.h used as an example): #ifndef SNMPV3_H #define SNMPV3_H #pragma pack(1) at the beginning and #pragma pack() #endif /* SNMPV3_H */ at the end. Comments and opinions are welcome. Thanks. Regards, Sergey. *-------------------------------------- ES@Home |
|
From: Michael J. S. <msl...@is...> - 2000-11-22 15:54:36
|
Hi, Sergey. The UCD-SNMP project has moved. It is now the net-snmp project. Discussion has moved to net...@li... Please send all replies to net...@li... [Including any patch for OS/2 that you might provide]. Please see the revised home page at http://net-snmp.sourceforge.net/ Current software version is http://download.sourceforge.net/net-snmp/net-snmp-4.2.pre2.tar.gz 4.2 release is imminent -- might be better to wait several weeks and address your patches from that version. Portions of Net-SNMP compile and run under Win32 API and under Cygnus/Windows environments. Any improvements you wish to suggest are welcomed. Best Regards, -Mike Slifcak, Internet Security Systems, Inc. "Sergey I. Yevtushenko" wrote: > > Hi, > > I'm porting ucd-snmp to OS/2. > During porting process some questions appeared and I'd like to know your opinions about it. > > First of all I'd like to have this port included with main distribution. How this can be done? Please provide a context diff patch between the original and modified source trees. For example (from Unix/Linux/Solaris): diff -wur net-snmp-4.2.pre2 net-snmp-os2 | grep -v '^Only' > os2patch.txt If you use or have any copyrighted source materials, please indicate those authors and license restrictions in the patch text. > > Other issues are more technical: > > 1. I have found that entire package completely ignores possible problems with function calling > convention used by different compilers. Although this unlikely a problem in most unixes, this may cause > serious problems when parts of package compiled by one compiler while other parts with other. > This issue can be resolved by adding to all function prototypes, function pointer members in structures > and typedefs some symbol which may be defined to nothing on unix platforms or to something specific > on OS/2 and Win32 (it also may suffer from this problem). Always open to recommendations. With the patch you might provide, a discussion can properly begin. > > Something like this: > > typedef int (*CALL_CONV snmp_callback) (int, struct snmp_session *, int, struct snmp_pdu *, void *); > > void CALL_CONV snmpv3_authtype_conf(const char *word, char *cptr); I think a compiled example from your patch would be appropriate to discuss. > > 2. Similar issue with alignment of structures. Although there is no standard way to accomplish this, > I think that most current compilers recognizes and able to handle correctly #pragma pack() > In either case compilers that don't recognize this pragma will just ignore it and nothing bad happens. > If to use this approach then each header will have (snmpv3.h used as an example): > > #ifndef SNMPV3_H > #define SNMPV3_H > > #pragma pack(1) > > at the beginning and > > #pragma pack() > #endif /* SNMPV3_H */ > > at the end. > > Comments and opinions are welcome. > > Thanks. > > Regards, > Sergey. > |
|
From: Michael J. S. <msl...@is...> - 2000-11-22 16:07:35
|
Correction: Current software version is http://download.sourceforge.net/net-snmp/ucd-snmp-4.2.pre2.tar.gz |
|
From: Sergey I. Y. <ev...@na...> - 2000-11-23 22:45:41
|
Hi,
In the snmp_api.c I've found following code:
--- cut ---
#ifndef SERVER_REQUIRES_CLIENT_SOCKET
if (!(( session->flags & SNMP_FLAGS_STREAM_SOCKET ) &&
#ifdef AF_UNIX
( isp->me.sa_family == AF_UNIX ) &&
#endif /* AF_UNIX */
( session->local_port == 0 ))) {
/* Client Unix-domain stream sockets don't need to 'bind' */
#endif
if (bind(sd, (struct sockaddr *)&isp->me, addr_size) != 0){
in_session->s_snmp_errno = SNMPERR_BAD_LOCPORT;
in_session->s_errno = errno;
snmp_set_detail(strerror(errno));
snmp_sess_close(slp);
return 0;
}
#ifndef SERVER_REQUIRES_CLIENT_SOCKET
}
#endif
--- cut ---
First "if" statement has following results of check depending on the incoming parameters:
1. DATAGRAM AF_INET local_port=0 -> true
2. DATAGRAM AF_INET local_port=1 -> true
3. DATAGRAM AF_UNIX local_port=0 -> true
4. DATAGRAM AF_UNIX local_port=1 -> true
5. STREAM AF_INET local_port=0 -> true
6. STREAM AF_INET local_port=1 -> true
7. STREAM AF_UNIX local_port=0 -> false
8. STREAM AF_UNIX local_port=1 -> true
If SERVER_REQUIRES_CLIENT_SOCKET is defined then bind() is called always
(well, this is what this constant is supposed to do).
Are there any need to call bind() for client connections?
Thanks.
Regards,
Sergey.
*--------------------------------------
ES@Home
|
|
From: Sergey I. Y. <ev...@na...> - 2000-11-22 16:19:50
|
On Wed, 22 Nov 2000 11:03:06 -0500, Michael J. Slifcak wrote: Hi, >Hi, Sergey. The UCD-SNMP project has moved. It is now >the net-snmp project. Thanks, it's fixed now. >4.2 release is imminent -- might be better to wait several weeks >and address your patches from that version. Unfortunately I can't wait. >> First of all I'd like to have this port included with main distribution. How this can be done? > >Please provide a context diff patch between the original >and modified source trees. For example (from Unix/Linux/Solaris): > >diff -wur net-snmp-4.2.pre2 net-snmp-os2 | grep -v '^Only' > >os2patch.txt > >If you use or have any copyrighted source materials, please indicate >those authors and license restrictions in the patch text. Thanks. I'll complete port and will send complete patch. At present only snmplib from 4.1.2 is complete (some things I'd like to change but at present it at least compiles and should work) and now I'm moving my changes to 4.2.pre2. Regards, Sergey. *-------------------------------------- ES@Home |
|
From: Sergey I. Y. <ev...@na...> - 2000-11-22 14:43:29
|
Hi, I'm porting ucd-snmp to OS/2. During porting process some questions appeared and I'd like to know your opinions about it. First of all I'd like to have this port included with main distribution. How this can be done? Other issues are more technical: 1. I have found that entire package completely ignores possible problems with function calling convention used by different compilers. Although this unlikely a problem in most unixes, this may cause serious problems when parts of package compiled by one compiler while other parts with other. This issue can be resolved by adding to all function prototypes, function pointer members in structures and typedefs some symbol which may be defined to nothing on unix platforms or to something specific on OS/2 and Win32 (it also may suffer from this problem). Something like this: typedef int (*CALL_CONV snmp_callback) (int, struct snmp_session *, int, struct snmp_pdu *, void *); void CALL_CONV snmpv3_authtype_conf(const char *word, char *cptr); 2. Similar issue with alignment of structures. Although there is no standard way to accomplish this, I think that most current compilers recognizes and able to handle correctly #pragma pack() In either case compilers that don't recognize this pragma will just ignore it and nothing bad happens. If to use this approach then each header will have (snmpv3.h used as an example): #ifndef SNMPV3_H #define SNMPV3_H #pragma pack(1) at the beginning and #pragma pack() #endif /* SNMPV3_H */ at the end. Comments and opinions are welcome. Thanks. Regards, Sergey. *-------------------------------------- ES@Home |
|
From: Wes H. <wjh...@uc...> - 2000-11-22 22:12:36
|
>>>>> On Wed, 22 Nov 2000 11:24:47 +0100, Juergen Schoenwaelder <sc...@ib...> said: Juergen> This is _NOT_ possible. You need to know how a table is Juergen> indexed to form the instance identifier. In particular, you Juergen> need to know whether a string is fixed length or not. If it Juergen> is variable length, then you need to know whether an implied Juergen> bit applies. I'm not saying it should be common practice, but if you sweep an entire mib tree from remote box for which you don't have internal MIBs for but you have figured out what certain sections do then referencing by name would be difficult. It would also be difficult if you only had the binary and not the mibs on a certain system. I'd still much rather be able to specify strings in an OID for the above 2 cases. Juergen> So any code which does an automatic conversion based on a Juergen> best guess is just flawed. It's the users guess, not the codes. It's entirely his fault. -- Wes Hardaker Please mail all replies to net...@li... |
|
From: Juergen S. <sc...@ib...> - 2000-11-22 22:28:50
|
>>>>> Wes Hardaker writes: Juergen> So any code which does an automatic conversion based on a Juergen> best guess is just flawed. Wes> It's the users guess, not the codes. It's entirely his fault. I strongly disagree. A program which simply converts SNMP-COMMUNITY-MIB::snmpCommunityName."foo" to 1.3.6.1.6.3.18.1.1.1.2.3.102.111.111 is broken. A program which converts 1.3.6.1.6.3.18.1.1.1.2."foo" to either 1.3.6.1.6.3.18.1.1.1.2.3.102.111.111 or 1.3.6.1.6.3.18.1.1.1.2.102.111.111 depending on whether the relevant MIB is loaded or not is IMHO also broken. I think it is not the user's responsibility to take care of "best guess" conversions done in an SNMP utility. /js -- Juergen Schoenwaelder Technical University Braunschweig <sc...@ib...> Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/> |
|
From: Wes H. <wjh...@uc...> - 2000-11-22 22:52:40
|
>>>>> On Wed, 22 Nov 2000 23:28:34 +0100, Juergen Schoenwaelder <sc...@ib...> said:
Juergen> I strongly disagree. A program which simply converts
Juergen> SNMP-COMMUNITY-MIB::snmpCommunityName."foo"
Juergen> to 1.3.6.1.6.3.18.1.1.1.2.3.102.111.111 is broken.
You're obviously not a hacker!
Juergen> A program which converts 1.3.6.1.6.3.18.1.1.1.2."foo" to
Juergen> either
Juergen> 1.3.6.1.6.3.18.1.1.1.2.3.102.111.111
Juergen> or
Juergen> 1.3.6.1.6.3.18.1.1.1.2.102.111.111
It would pick the first. We reserve the other quote marks ('') for
the non-prefixed case.
I'm not saying its a good thing for general practice, but typing
\"foo\" is much easier than typing .102.111.111 since I don't have the
ascii table memorized.
Anyway, would you apply the same strictness to other tools like chown
(picking one at random), not allowing it to accept a number and
forcing the user to have the user name in the password file for
translation?
Anyway, my goal is always to provide the ultimate in flexibility. 99%
of the world won't need the functionality, but the rest of us might.
--
Wes Hardaker
Please mail all replies to net...@li...
|
|
From: David T. P. <dpe...@ds...> - 2000-11-22 23:19:25
|
HI, Adding support for ."foo" to replace .102.111.111 was a great addition. It is true that without MIB knowledge, a program does not know whether or not to prefix the OIDfied string with a prefix length. It seems like the problem can be solved in two ways, which are: 1) the user has to specify the length (if needed). For example, if a length is needed, the user must specify .3."foo" instead of just ."foo". 2) a new symbol can be specified to indicate that a length needs to prefix the OIDfied string. For example, for a length to be inserted, how about the following: .+."foo". Regards, /david t. perkins |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X