November 2002 - Scli - lists.ibr.cs.tu-bs.de

scli moving to glib-2.0 and modularization
by Juergen Schoenwaelder 31 Jan '03

31 Jan '03

I changed my scli sources yesterday to use the glib-2.0. Since glib-2.0 has some nice new features, it might be possible to simplify some of the internals by reusing more glib stuff. If someone sees a problem with moving to glib-2.0, please let me know. I also played some time with the idea to separate out the SNMP implementation. I did just that yesterday by creating a package tentatively called gsnmp. The idea here would be that others can reuse the glib-based SNMP library easily. Now, making this split would imply that scli has another dependency. If you think this is a problem, please let me know. There is another open question: Should the scli stubs also become a reusable separate package? It would make sense if there are people who are interested to develop other applications that make use of the stubs. One could package this as gsnmpietf (stubs for the IETF MIBs), gsnmpnortel, gsnmpcisco, ... Having stub packages would allow to write simple programs such as the one below without having to deal with all the nasty SNMP/MIB things. But perhaps I am starting to overdo modularization? Comments are welcome. /js #include <gsnmp.h> #include <ietf/snmpv2-mib.h> static void ping(GSnmpSession *s) { snmpv2_mib_system_t *system; snmpv2_mib_get_system(s, &system, SNMPV2_MIB_SYSDESCR); if (! s->error_status && system) { g_print("%.*s\n", system->_sysDescrLength, system->sysDescr); } if (system) snmpv2_mib_free_system(system); } int main(int argc, char **argv) { GSnmpSession *s; if (! g_snmp_init(FALSE)) { exit(1); } s = g_snmp_session_new(G_SNMP_TDOMAIN_UDP_IPV4, "localhost", 161); if (! s) { exit(1); } s->rcomm = "public"; s->version = G_SNMP_V1; ping(s); g_snmp_session_destroy(s); return 0; }

2 2

Feature Request: Cisco VLAN bridging information
by Dirk Janssens 30 Nov '02

30 Nov '02

Hello, Is it possible to add support for getting VLAN and Trunking info for cisco equipment? I'm not very experienced at SNMP, but I believe the MIBS are: CISCO-VLAN-BRIDGING-MIB and CISCO-VTP-MIB IF there are some guidelines or howto's about adding such features to scli, i'm willing to try it myself (but absolutely no guarantees I will succeed :-) Kind regards, Dirk -- --------------------------------------------------------- KULeuvenNet --

2 1

gsnmp test package
by Juergen Schoenwaelder 27 Nov '02

27 Nov '02

I just wrapped together a gsnmp test package: ftp://ftp.ibr.cs.tu-bs.de/pub/local/gsnmp/gsnmp-0.1.0.tar.gz This package requires glib2 and compilation generates three libraries: libgsnmp snmp protocol engine libgsnmpiana stubs for all IANA maintained MIB modules libgsnmpietf stubs for all published IETF MIB modules There are some very simple test programs in the tools directory. It would be nice to get feedback about this. There are many things that could be done, such as: - support for SNMP version 3 and perhaps TCP transport - more compatibility with the glib way of doing things - more intensive usage of new glib2 features - stubs for notifications and such - reduce size of the stubs At the moment, libgsnmpietf.a offers 7674 stub entry points with a total size of 3521906 bytes (gcc compiled with -O2), which means an average stub size of roughly 460 bytes. I have some ideas on how to cut this down a bit, but probably nothing really dramatic. The point really is that the number of functions that fall out of all the MIBs is so huge. What really is needed are MIB annotations which help to produce fewer but more meaningful stubs. I am working on an scli version which uses these libraries. I am not sure how I deal with the vendor specific stubs or unpublished stubs that scli needs. Ideally, there would be libgsnmpcisco or libgsnmpnortel but since it is difficult to get an overview of the vendor MIBs, the approach is probably to add them slowly when needed (and if the copyright allows to do so). Anyway, it would be nice if people can check this out. Feedback on this is more than welcome. /js -- Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/>

1 0

scli feature list
by Iain McAleer 15 Nov '02

15 Nov '02

Hello, I'm looking for a complete list of all scli's features, if anyone has this information and could please forward it to me it would be greatly appreciated. Regards, Iain McAleer

2 1

Re: [Fwd: [scli] scli moving to glib-2.0 and modularization]
by Michael Goffioul 13 Nov '02

13 Nov '02

> I also played some time with the idea to separate out the SNMP > implementation. I did just that yesterday by creating a package > tentatively called gsnmp. The idea here would be that others > can reuse the glib-based SNMP library easily. Now, making this > split would imply that scli has another dependency. If you think > this is a problem, please let me know. > > There is another open question: Should the scli stubs also become a > reusable separate package? It would make sense if there are people > who are interested to develop other applications that make use of > the stubs. One could package this as gsnmpietf (stubs for the > IETF MIBs), gsnmpnortel, gsnmpcisco, ... >From my point of view (short intro: Michael Goffioul, KDEPrint and sKli developer), having access to separate libraries to perform all the SNMP dirty work is a plus. Having access to the internal data is much faster and more reliable than parsing the scli standard output (whose format can change from one version to the other). So I'm pretty much in favor of such a development direction. For the dependency problem, you can still package the whole source code into one package, containing the various libraries and the scli executable, and leave the splitting into separate binary packages to the distro packagers. As final note, I'll add that having access to the stubs is (at least for me) as important as for the gsnmp alone. So yes, putting stubs accessible in separate package/libs is pretty useful. Bye. Michael. -- ------------------------------------------------------------------ Michael Goffioul IMEC-DESICS-MIRA e-mail: goffioul(a)imec.be (Mixed-Signal and RF Applications) Tel: +32/16/28-8510 Kapeldreef, 75 Fax: +32/16/28-1515 3001 HEVERLEE, BELGIUM ------------------------------------------------------------------ This e-mail and/or its attachments may contain confidential information. It is intended solely for the intended addressee(s). Any use of the information contained herein by other persons is prohibited. IMEC vzw does not accept any liability for the contents of this e-mail and/or its attachments. ------------------------------------------------------------------

2 3