pysnmp-users Mailing List for SNMP library for Python (Page 63)
Brought to you by:
elie
Menu
▾
▴
pysnmp-users — PySNMP usage issues
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(3) |
Mar
(16) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(7) |
Aug
(12) |
Sep
(4) |
Oct
(2) |
Nov
(11) |
Dec
(6) |
| 2004 |
Jan
(1) |
Feb
(41) |
Mar
(4) |
Apr
(1) |
May
(6) |
Jun
|
Jul
(8) |
Aug
(5) |
Sep
(8) |
Oct
(10) |
Nov
(3) |
Dec
(1) |
| 2005 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(4) |
May
(10) |
Jun
(5) |
Jul
(10) |
Aug
(6) |
Sep
(6) |
Oct
(39) |
Nov
(20) |
Dec
(21) |
| 2006 |
Jan
(14) |
Feb
(6) |
Mar
(15) |
Apr
|
May
(5) |
Jun
(16) |
Jul
(16) |
Aug
(18) |
Sep
(35) |
Oct
(12) |
Nov
(3) |
Dec
(3) |
| 2007 |
Jan
(12) |
Feb
(19) |
Mar
(27) |
Apr
(14) |
May
(32) |
Jun
|
Jul
(35) |
Aug
(11) |
Sep
(11) |
Oct
(6) |
Nov
(13) |
Dec
(4) |
| 2008 |
Jan
(7) |
Feb
(4) |
Mar
(2) |
Apr
(3) |
May
(3) |
Jun
(5) |
Jul
(5) |
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(19) |
Dec
(7) |
| 2009 |
Jan
(2) |
Feb
(2) |
Mar
(12) |
Apr
(16) |
May
(16) |
Jun
(23) |
Jul
(7) |
Aug
(2) |
Sep
(17) |
Oct
(20) |
Nov
(20) |
Dec
(5) |
| 2010 |
Jan
(11) |
Feb
(17) |
Mar
(20) |
Apr
(7) |
May
(6) |
Jun
(14) |
Jul
(5) |
Aug
(10) |
Sep
(23) |
Oct
(16) |
Nov
(32) |
Dec
(21) |
| 2011 |
Jan
(6) |
Feb
(11) |
Mar
(3) |
Apr
(1) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(20) |
Oct
(9) |
Nov
(29) |
Dec
(25) |
| 2012 |
Jan
(2) |
Feb
(5) |
Mar
(2) |
Apr
(22) |
May
(21) |
Jun
(7) |
Jul
(6) |
Aug
(2) |
Sep
(12) |
Oct
(20) |
Nov
(17) |
Dec
(17) |
| 2013 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(8) |
May
(10) |
Jun
(2) |
Jul
(23) |
Aug
(12) |
Sep
(14) |
Oct
(12) |
Nov
(4) |
Dec
(18) |
| 2014 |
Jan
(2) |
Feb
(7) |
Mar
(3) |
Apr
(8) |
May
(7) |
Jun
(1) |
Jul
(5) |
Aug
(2) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2015 |
Jan
(3) |
Feb
(15) |
Mar
(14) |
Apr
(4) |
May
(6) |
Jun
(3) |
Jul
(1) |
Aug
(6) |
Sep
(5) |
Oct
(21) |
Nov
(43) |
Dec
(10) |
| 2016 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(4) |
May
(6) |
Jun
(2) |
Jul
(6) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
(3) |
Dec
(11) |
| 2017 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(9) |
Oct
(8) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Ilya E. <il...@gl...> - 2004-02-05 15:25:39
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> BTW, I suppose there should be some performance improvement once you upgrade to pysnmp-3.4.1. If you eventually convert to the pysnmp.proto.api.alpha API, this may result in even better performance. Another interesting issue is if my implementation of SNMP tables management (of alpha API) would match your needs. Thanks! -ilya > For those who are interested in such things. I've just put Version > 0.2.0 of TwistedSNMP up on my web-page. This release makes it possible > to write systems that do mass-querying of multiple Agents (similar to > the "bulkrole" example from PySNMP). To do that, there was some fairly > noticeable restructuring of the API, which will require some work to > update in client code. > > http://members.rogers.com/mcfletch/programming/ > > I'm rather pleased with the resulting API. If it weren't for the need > to prevent overloading the network by issuing thousands of simultaneous > queries, the mass-query API would look like "for agent in agents: > agent.getTable( oids )" . > > Night all, and have fun, > Mike |
|
From: Ilya E. <il...@gl...> - 2004-02-05 15:16:15
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Hello fellow Pythoners, I've just released the next version of PySNMP package (3.4.1) along with a newcomer -- PySNMPApps package holds basic SNMP tools written on top of PySNMP. Here are the most important changes to PySNMP: - Components caching implemented at almost all asn1.base.Asn1Object deviratives what aims at significant performance improvement. What is related to this change is that various structured ASN.1 objects might not now return newly created inner components as well as not copying (but borrowing) passed objects on assignment. - Alpha API to pysnmp.proto objects is now the API of choice. Besides other improvements, this package introduces a protocol version-neutral API. Previous Generic API (pysnmp.proto.api.generic) remains for compatibility. - A method for dealing with SNMP tables introduced with the Alpha API. - New examples introduced - Documentation updated The PySNMPApps package contains the improved versions of former example scripts of PySNMP along with relevant machinery. As of this writing, this includes pysnmpget/set, pysnmpwalk/bulkwalk and pysnmptrap/trapd tools. Thanks, ilya |
|
From: Mike C. F. <mcf...@ro...> - 2004-02-05 11:58:55
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> For those who are interested in such things. I've just put Version 0.2.0 of TwistedSNMP up on my web-page. This release makes it possible to write systems that do mass-querying of multiple Agents (similar to the "bulkrole" example from PySNMP). To do that, there was some fairly noticeable restructuring of the API, which will require some work to update in client code. http://members.rogers.com/mcfletch/programming/ I'm rather pleased with the resulting API. If it weren't for the need to prevent overloading the network by issuing thousands of simultaneous queries, the mass-query API would look like "for agent in agents: agent.getTable( oids )" . Night all, and have fun, Mike Change log... Version 0.2.0 * Complete refactoring of the client/manager-side API. Instead of requiring one port per managed agent, is able to manage any number of agents from a single port. Most of the machinery of the old protocol object is now part of an AgentProxy class. You *will* need to modify all client code to work with the new API. Mostly just a matter of a different initialisation pattern and then using the AgentProxy object in the same manner as you used the old SNMPProtocol object. * Crude mass-query mechanism created. As of yet only tested against a local server, and doesn't yet have balancing heuristics to throttle load in response to network response, but does appear to work. * Dropped the snmpports module. It's no longer necessary with the new structure. * Bug was discovered in Python 2.3's BSDDB module which affects the BSDDB storages, bug report submitted to the Python project, but for now, will not pass tests under Python 2.3. _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Mike C. F. <mcf...@ro...> - 2004-02-05 08:28:18
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Ilya Etingof wrote: ... >I've been doing major update at CVS yesterday but I did not remove the >proto.api.alpha package. I've just checked out the version-3-branch so the >package in question is still there. > > On checking out again they do indeed pop back in there. Don't know why CVS decided to delete them on me earlier. Oh well. >Maybe it's an issue of CVS snapshot being taken at a wrong moment? >Could you please try it out again and if it still misses the package, >I'd ask SF people for a fix. > > Seems okay now. >BTW, I've finally fixed the problems of the API you pointed out >last year (along with many other improvements) so I'd really appreciate >if you'd take a look at the version-3-3-x-branch . > > Will try to get time to do so on the weekend. I'm on billable time just now though (restructuring TwistedSNMP to allow for mass-querying of modems) so can't at the moment. Have fun, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Ilya E. <il...@gl...> - 2004-02-05 07:49:25
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> I've been doing major update at CVS yesterday but I did not remove the proto.api.alpha package. I've just checked out the version-3-branch so the package in question is still there. Maybe it's an issue of CVS snapshot being taken at a wrong moment? Could you please try it out again and if it still misses the package, I'd ask SF people for a fix. BTW, I've finally fixed the problems of the API you pointed out last year (along with many other improvements) so I'd really appreciate if you'd take a look at the version-3-3-x-branch . Thanks! -ilya > Checkout of the version-3-branch as of a few minutes ago is missing the > entire proto.api.alpha package, but that package is still being imported > by proto.api.generic.rfc1157 . > > Going to revert to 3.3.5 for my work today, but just wanted to know if > this is a known condition or not. |
|
From: Mike C. F. <mcf...@ro...> - 2004-02-05 06:52:34
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Checkout of the version-3-branch as of a few minutes ago is missing the entire proto.api.alpha package, but that package is still being imported by proto.api.generic.rfc1157 . Going to revert to 3.3.5 for my work today, but just wanted to know if this is a known condition or not. Have fun all, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Antonio B. M. <ant...@li...> - 2004-01-22 14:54:56
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Hi all: I'm trying to get several values from my snmp agents. I want to pass several oid's, several are leafs and the others not. But if I pass this list to pysnmpwalk, something strange happens: A) Walk $ ./snmpwalk.py pierre public .1.3.6.1.4.1.2021.4 .1.3.6.1.4.1.2021.4.1.0 ---> 0 .1.3.6.1.4.1.2021.4.2.0 ---> 'swap' .1.3.6.1.4.1.2021.4.3.0 ---> 0 .1.3.6.1.4.1.2021.4.4.0 ---> 0 .1.3.6.1.4.1.2021.4.5.0 ---> 190960 .1.3.6.1.4.1.2021.4.6.0 ---> 9760 .1.3.6.1.4.1.2021.4.11.0 ---> 9760 .1.3.6.1.4.1.2021.4.12.0 ---> 16000 .1.3.6.1.4.1.2021.4.13.0 ---> 0 .1.3.6.1.4.1.2021.4.14.0 ---> 4280 .1.3.6.1.4.1.2021.4.15.0 ---> 133016 .1.3.6.1.4.1.2021.4.100.0 ---> 1 .1.3.6.1.4.1.2021.4.101.0 ---> 'Running out of swap space (0)' B) a leaf ./snmpwalk.py -C i pierre hada .1.3.6.1.4.1.2021.11.9.0 .1.3.6.1.4.1.2021.11.9.0 ---> 4 C) Both ./snmpwalk.py -C i pierre hada .1.3.6.1.4.1.2021.4 .1.3.6.1.4.1.2021.11.9.0 .1.3.6.1.4.1.2021.4 ---> '' .1.3.6.1.4.1.2021.11.9.0 ---> '' <------------ ??????? .1.3.6.1.4.1.2021.4.1.0 ---> 0 .1.3.6.1.4.1.2021.4.2.0 ---> 'swap' .1.3.6.1.4.1.2021.4.3.0 ---> 0 .1.3.6.1.4.1.2021.4.4.0 ---> 0 .1.3.6.1.4.1.2021.4.5.0 ---> 190960 .1.3.6.1.4.1.2021.4.6.0 ---> 9728 .1.3.6.1.4.1.2021.4.11.0 ---> 9728 .1.3.6.1.4.1.2021.4.12.0 ---> 16000 .1.3.6.1.4.1.2021.4.13.0 ---> 0 .1.3.6.1.4.1.2021.4.14.0 ---> 4280 .1.3.6.1.4.1.2021.4.15.0 ---> 133044 .1.3.6.1.4.1.2021.4.100.0 ---> 1 .1.3.6.1.4.1.2021.4.101.0 ---> 'Running out of swap space (0)' Why now the oid .1.3.6.1.4.1.2021.11.9.0 returns ''. A lot of thanks. -- Antonio Beamud Montero <ant...@li...> |
|
From: Mike C. F. <mcf...@ro...> - 2003-12-08 17:46:01
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Ilya Etingof wrote: >That's cool! > > Thanks. >Would you mind me setting up a href to TwistedSNMP at pysnmp homepage? > > Of course not. I figure once the codebase settles down it'll either migrate to its own SF project page or merge into either Twisted or PySNMP, but linking to my programming page for now is fine. >BTW, I'm working on slight refactoring of pysnmp code that, among >other things, addresses usage problems you recently pointed out. >Hope to end up with this in a few days. > > Cool. I'm not likely going to get time to work on TwistedSNMP until the weekend, btw, so don't rush on my account :) . Enjoy yourselves, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Mike C. F. <mcf...@ro...> - 2003-12-08 17:40:18
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Ilya Etingof wrote: >[ skipped ] > > >>the thing is, if I've reading the spec correctly, the agent is supposed >>to be reducing R if one of the tables is exhausted, rather than filling >>all of the slots with v2c.EndOfMibView or the OIDs following the >>requested tables. I'm gathering my reading is wrong, which suggests >>I'll have to alter the agent code to just produce the extra values (it's >>only a concern at end-of-OID-table conditions, otherwise will continue >>through the tables). >> >> > >I'd a brief look at the rfc1905 but have not found explicit reference to >R's reduction. What makes you think the reduction is needed? > > Well, nothing now :) . My original thinking had been that the bulk-request mechanism was just an encoding of the practice of doing a get-next (where R does reduce over time, as you prune the finished tables) so that X number of iterations would occur on the server and be returned. That was incorrect, as actually reading the RFC told me. I only cracked open the RFC's this weekend, however, so how could I have known that :) ;) :) . >I've tried a BULK walk with cisco box (as5300) so it seems not to reduce >R: > >snmpbulkwalk.py my-as5300-box-fqdn .1.3.6 .1.3.7 >.1.3.6.1.2.1.1.1.0 ---> 'Cisco Internetwork Operating System Software' >.1.3.7 ---> '' >.1.3.6.1.2.1.1.2.0 ---> '.1.3.6.1.4.1.9.1.274' >.1.3.7 ---> '' >.1.3.6.1.2.1.1.3.0 ---> 49878705 >.1.3.7 ---> '' > > Unless .1.3.7 is the very last OID in your cisco box's OID space, that's expected in either case. This is for the special case where the walk goes past the end of the OID-space. Assuming you've got the following 4 MIBs at the end of the OID space and you ask for a get-bulk of each of the 4 MIBs, you're supposed to get back a table of: .1.2.3 .1.2.4 .1.2.5 .1.2.6 1 2 3 4 .1.2.4 .1.2.5 .1.2.6 .1.2.6 2 3 4 EndOfMibView .1.2.5 .1.2.6 .1.2.6 .1.2.6 3 4 EndOfMibView EndOfMibView .1.2.6 .1.2.6 .1.2.6 .1.2.6 4 EndOfMibView EndOfMibView EndOfMibView .1.2.6 .1.2.6 .1.2.6 .1.2.6 EndOfMibView EndOfMibView EndOfMibView EndOfMibView I'd assumed that the protocol would try to reduce the data transmitted, taking each EndOfMibView as a signal to reduce "R", so that further rows wouldn't duplicate the OID + EndOfMibView data. Thing is, the general case is *far* more common, where the trailing tables are included instead of EndOfMibView, so whatever space-savings would occur are basically entirely ignorable (being so rare), and would just complicate the algorithm. I think I've got the code for this properly functioning now, but as always, review appreciated. Code that generates the messages on the Agent side is in agent.py, code that consumes it on the Manager side is in tableretriever.py . Have fun, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Ilya E. <il...@gl...> - 2003-12-08 09:15:56
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> That's cool! Would you mind me setting up a href to TwistedSNMP at pysnmp homepage? BTW, I'm working on slight refactoring of pysnmp code that, among other things, addresses usage problems you recently pointed out. Hope to end up with this in a few days. -ilya |
|
From: Ilya E. <il...@gl...> - 2003-12-08 09:06:40
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> [ skipped ] > the thing is, if I've reading the spec correctly, the agent is supposed > to be reducing R if one of the tables is exhausted, rather than filling > all of the slots with v2c.EndOfMibView or the OIDs following the > requested tables. I'm gathering my reading is wrong, which suggests > I'll have to alter the agent code to just produce the extra values (it's > only a concern at end-of-OID-table conditions, otherwise will continue > through the tables). I'd a brief look at the rfc1905 but have not found explicit reference to R's reduction. What makes you think the reduction is needed? I've tried a BULK walk with cisco box (as5300) so it seems not to reduce R: snmpbulkwalk.py my-as5300-box-fqdn .1.3.6 .1.3.7 .1.3.6.1.2.1.1.1.0 ---> 'Cisco Internetwork Operating System Software' .1.3.7 ---> '' .1.3.6.1.2.1.1.2.0 ---> '.1.3.6.1.4.1.9.1.274' .1.3.7 ---> '' .1.3.6.1.2.1.1.3.0 ---> 49878705 .1.3.7 ---> '' -ilya |
|
From: Mike C. F. <mcf...@ro...> - 2003-12-08 04:40:56
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> What is it: TwistedSNMP is a set of SNMP protocol implementations for Python's Twisted Matrix networking framework using the PySNMP project. It provides the following: * get, set, getnext and getbulk Manager-side queries * get, set, getnext and getbulk Agent-side services Eventual goals of the system: * provide access to all v1 and v2 SNMP functionality for writing Agent and Manager services * provide convenient testing mechanisms for SNMP Agent/Manager development (e.g. mirroring an SNMP Agent's OID tree for local query testing) I did two releases today, so now up to 0.1.4. Here's the change-log for those two versions: Version 0.1.4 * Utilities: o mirroragent -- mirrors an agent to local bsddb shelve for testing (still very rough, just a sketch, really) * BSDOIDStore -- a new OIDStore implementation for use in utilities, stores to a bsddb btree database * Major refactoring of the Agent-side mechanisms: o AgentProtocol -- low-level send and dispatch of messages to the Agent o Agent -- SNMP logic for get/getNext/getTable/set implementation o OIDStore -- interface for storage/retrieval of ordered OID tree o BisectOIDStore -- the demo OIDStore implementation for testing purposes using the bisect module Version 0.1.3 * Agent and Manager-side set protocol implementation * Minimal sample code for Agent-side set code, doesn't yet do the error-negotiation stuff Enjoy all, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Mike C. F. <mcf...@ro...> - 2003-12-07 07:32:16
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Post: <mailto:pys...@li...> List-Help: <mailto:pys...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> I've just popped a new version of TwistedSNMP onto my website. I've been working on the Agent side of things, mostly, as well as some testing to see that things are working correctly. One question I've come up against is this piece of code from the spec, where the purpose is to find those varbind sets that have passed the end of the root-set: N = 0 R = len(request.apiGenGetPdu().apiGenGetVarBind()) - N M = len(response.apiGenGetPdu().apiGenGetVarBind()) / R for i in range(1, M+1): for r in range(1, R+1): idx = N + ((i-1)*R) + r (oid, val) = newOIDs[idx-1] if not self.protocol.getImplementation().ObjectIdentifier(roots[r-1]).isaprefix(oid): the thing is, if I've reading the spec correctly, the agent is supposed to be reducing R if one of the tables is exhausted, rather than filling all of the slots with v2c.EndOfMibView or the OIDs following the requested tables. I'm gathering my reading is wrong, which suggests I'll have to alter the agent code to just produce the extra values (it's only a concern at end-of-OID-table conditions, otherwise will continue through the tables). Anyway, for the curious, the new version is on my programming page here: http://members.rogers.com/mcfletch/programming Enjoy all, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Ilya E. <il...@gl...> - 2003-11-27 08:35:50
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> [ skipped ] > Suppose so. I prefer to work with data-types where possible, rather > than waiting until the last moment to do the conversions. i.e. I'd > rather have a data-type that spits out a ValueError or TypeError as soon > as the developer tries to store the data, rather than having the error > raised when the system tries to encode a value for sending. Coercion > isn't something I love, just a stop-gap to get the Agent code started. Surely. Just to clarify things -- the class-at-module-lookup technique I mentioned above performs the coercion at the moment of ASN1 data type creation, not at the serialization phase. [ skipped ] > v3 API sounds somewhat like what I'm trying to do with the twistedsnmp > stuff, actually. The twisted system can readily handle having multiple > active protocol objects (i.e. roles), and the protocols themselves > handle whichever version (of 1 or 2) they are set to use. I'm assuming > the "engine management" facilities are to allow a standard API for > hooking up Agent back-end code to the SNMP engine? Actually, talking on "engine management", I meant functionality like SNMP party discovery, statistics collection, error message processing and so on. As for backend hooking -- v3 engine provides a standard way for apps for sending PDUs and registering callback funcs for receiption. Applications operate at SNMP PDU level and below whilst SNMP engine works at message level, networking, and its own management stuff. -ilya |
|
From: Mike C. F. <mcf...@ro...> - 2003-11-27 08:08:26
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Ilya Etingof wrote: >Mike, > > > >>AFAIK I do, as specifying an SNMP 1.x compatible type (e.g. v1.Integer) >>will not work if the protocol is using v2c (raises a TypeError if I'm >>recalling correctly). Since I want the developer to be able to specify >>the data-type (e.g. Counter vs Integer) when setting up an agent (or a >>set message for that matter, when it becomes available) I want to allow >>for specifying the data-types in some way. >> >> > >Still, it looks to me that there is no need for 'structured' types >coercion here. According to current SNMP specs, there seems to be only one >'structured' type (rfc1155.NetworkAddress) available at the >VariableBinding (and API) level. > >Automatic coercion between Sequence-based (rfc1155.NetworkAddress) and >OctetString-based (rfc1902.IpAddress) types seems to be next to impossible. >That's why, if you consider NetworkAddress as a special case, it might >be possible to drop all 'structured' types coercions. What do you think? > > Haven't really formed an opinion yet. I've not yet encountered any sequence-based stuff, so have no real experience with it to judge between the approaches. As I get time to work on the AgentProtocol stuff I'll likely start to develop a better understanding. >Another approach to unification may be as follows: > > > >>>># developer specifies className (literally) along with the value >>>>def buildValue(className, value): >>>> return getattr(proto, className)(value) >>>>from pysnmp.proto import rfc1155 >>>>proto = rfc1155 >>>>print buildValue('Integer', 1) >>>> >>>> >Integer: 1 > > >>>>from pysnmp.proto import rfc1902 >>>>proto = rfc1902 >>>>print buildValue('Integer', 1) >>>> >>>> >Integer: 1 > >Here again a special processing for NetworkAddress would be required at the >buildValue() to handle all possible types on input. > > Suppose so. I prefer to work with data-types where possible, rather than waiting until the last moment to do the conversions. i.e. I'd rather have a data-type that spits out a ValueError or TypeError as soon as the developer tries to store the data, rather than having the error raised when the system tries to encode a value for sending. Coercion isn't something I love, just a stop-gap to get the Agent code started. >>It might be more useful to define a set of tertiary "universal" types >>which know how to encode themselves for either (any) protocol, but that >>didn't seem necessary in the short term. I have nothing as-of-yet which >>has sequences encoded, so I hadn't discovered the failure cases. >> >> > >BTW, I've tried to implement certain degree of types transparency at >pysnmp.proto.cli.ucd.* .... > > Will take a look when I get some time to work on the project again. >>Am I missing something with regard to the ASN objects? Is there some >>way to transfer between the v1 and v2c encoding definitions? Is there >>logic somewhere in PySNMP to handle coercions from simple Python types >>that could be hooked into? >> >> > >Coercion from Python types is currently implemented only for 'simple' ASN.1 >types at the class level (see get() & set() at pysnmp.asn1.univ.*). This >is actually what you've used at SimpleConverter. > > Okay. >That sounds good to me. Will attempt to implement smth like that. BTW, in >SNMP v3 spec there's already similar classification of PDU types. > > K. >>Same basic problem as the ASN data-types, I guess; the semantics of the >>*overlap* between the two versions aren't queryable at run-time, so >>there's no way to process the union of the two versions. >> >> > >As for simple ASN1 types, perhaps the simplest way is to try a coercion >with current protocol implementation like I suggested above. > >BTW, I fear that the API to SNMP v3 implementation might not be >backward compatible with the current API. The basic problem is that v3 >spec introduces the concept of "SNMP entity" which is a composition of >transport, message encoding and SNMP engine management facilities. That >is, the high-level API to v3 appears to be an interface to a multi-protocol, >multi-role SNMP engine. > >Although, compatibility might be preserved from the PDU processing level >(apiGenGetPdu()) and below. > > v3 API sounds somewhat like what I'm trying to do with the twistedsnmp stuff, actually. The twisted system can readily handle having multiple active protocol objects (i.e. roles), and the protocols themselves handle whichever version (of 1 or 2) they are set to use. I'm assuming the "engine management" facilities are to allow a standard API for hooking up Agent back-end code to the SNMP engine? Enjoy, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Ilya E. <il...@gl...> - 2003-11-26 12:32:03
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Mike, > AFAIK I do, as specifying an SNMP 1.x compatible type (e.g. v1.Integer) > will not work if the protocol is using v2c (raises a TypeError if I'm > recalling correctly). Since I want the developer to be able to specify > the data-type (e.g. Counter vs Integer) when setting up an agent (or a > set message for that matter, when it becomes available) I want to allow > for specifying the data-types in some way. Still, it looks to me that there is no need for 'structured' types coercion here. According to current SNMP specs, there seems to be only one 'structured' type (rfc1155.NetworkAddress) available at the VariableBinding (and API) level. Automatic coercion between Sequence-based (rfc1155.NetworkAddress) and OctetString-based (rfc1902.IpAddress) types seems to be next to impossible. That's why, if you consider NetworkAddress as a special case, it might be possible to drop all 'structured' types coercions. What do you think? Another approach to unification may be as follows: >>> # developer specifies className (literally) along with the value >>> def buildValue(className, value): >>> return getattr(proto, className)(value) >>> from pysnmp.proto import rfc1155 >>> proto = rfc1155 >>> print buildValue('Integer', 1) Integer: 1 >>> from pysnmp.proto import rfc1902 >>> proto = rfc1902 >>> print buildValue('Integer', 1) Integer: 1 Here again a special processing for NetworkAddress would be required at the buildValue() to handle all possible types on input. > It might be more useful to define a set of tertiary "universal" types > which know how to encode themselves for either (any) protocol, but that > didn't seem necessary in the short term. I have nothing as-of-yet which > has sequences encoded, so I hadn't discovered the failure cases. BTW, I've tried to implement certain degree of types transparency at pysnmp.proto.cli.ucd.* .... > Am I missing something with regard to the ASN objects? Is there some > way to transfer between the v1 and v2c encoding definitions? Is there > logic somewhere in PySNMP to handle coercions from simple Python types > that could be hooked into? Coercion from Python types is currently implemented only for 'simple' ASN.1 types at the class level (see get() & set() at pysnmp.asn1.univ.*). This is actually what you've used at SimpleConverter. [ skipped ] > >>requestPdu = request.apiGenGetPdu() > >>if isinstance(requestPdu, rfc1157.GetRequestPdu) or \ > >> isinstance(requestPdu, rfc1905.GetRequestPdu): > >> > Wouldn't this then break for SNMP v3 whenever it becomes available? > I'll go ahead and switch this, but it seems as though there should be a > way to mark/query each message-type that's not dependent on knowing all > of the versions. e.g. deriving each from the same class (and then doing > isinstance on the base class), or retrieving an int/string/something > specifying the message-type as a simple value (which is what I was > attempting above). That sounds good to me. Will attempt to implement smth like that. BTW, in SNMP v3 spec there's already similar classification of PDU types. > Same basic problem as the ASN data-types, I guess; the semantics of the > *overlap* between the two versions aren't queryable at run-time, so > there's no way to process the union of the two versions. As for simple ASN1 types, perhaps the simplest way is to try a coercion with current protocol implementation like I suggested above. BTW, I fear that the API to SNMP v3 implementation might not be backward compatible with the current API. The basic problem is that v3 spec introduces the concept of "SNMP entity" which is a composition of transport, message encoding and SNMP engine management facilities. That is, the high-level API to v3 appears to be an interface to a multi-protocol, multi-role SNMP engine. Although, compatibility might be preserved from the PDU processing level (apiGenGetPdu()) and below. Thanks, ilya |
|
From: Mike C. F. <mcf...@ro...> - 2003-11-25 18:09:37
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Ilya Etingof wrote: >Yeah, well done! > >At datatypes.py, I suspect there is a coercion problem -- the >SimpleConverter.__call__() would work for "simple" ASN.1 types but would >not for "Structured" ones (such as Sequence). Do you really need to coerce >non-simple types? > > AFAIK I do, as specifying an SNMP 1.x compatible type (e.g. v1.Integer) will not work if the protocol is using v2c (raises a TypeError if I'm recalling correctly). Since I want the developer to be able to specify the data-type (e.g. Counter vs Integer) when setting up an agent (or a set message for that matter, when it becomes available) I want to allow for specifying the data-types in some way. It might be more useful to define a set of tertiary "universal" types which know how to encode themselves for either (any) protocol, but that didn't seem necessary in the short term. I have nothing as-of-yet which has sequences encoded, so I hadn't discovered the failure cases. Am I missing something with regard to the ASN objects? Is there some way to transfer between the v1 and v2c encoding definitions? Is there logic somewhere in PySNMP to handle coercions from simple Python types that could be hooked into? >Just a minor suggestion regarding SNMP objects browsing like (in >agent.py): > > > >>requestType = self.requestType( request ) >>if requestType == 'get_request' >> >> > >This may not be quite portable across SNMP versions. That's why, >a more formal way would be to do: > > > >>requestPdu = request.apiGenGetPdu() >>if isinstance(requestPdu, rfc1157.GetRequestPdu) or \ >> isinstance(requestPdu, rfc1905.GetRequestPdu): >> >> Wouldn't this then break for SNMP v3 whenever it becomes available? I'll go ahead and switch this, but it seems as though there should be a way to mark/query each message-type that's not dependent on knowing all of the versions. e.g. deriving each from the same class (and then doing isinstance on the base class), or retrieving an int/string/something specifying the message-type as a simple value (which is what I was attempting above). Same basic problem as the ASN data-types, I guess; the semantics of the *overlap* between the two versions aren't queryable at run-time, so there's no way to process the union of the two versions. Thank-you very much for the feedback (and PySNMP, of course), Mike |
|
From: Ilya E. <il...@gl...> - 2003-11-25 12:45:14
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Yeah, well done! At datatypes.py, I suspect there is a coercion problem -- the SimpleConverter.__call__() would work for "simple" ASN.1 types but would not for "Structured" ones (such as Sequence). Do you really need to coerce non-simple types? Just a minor suggestion regarding SNMP objects browsing like (in agent.py): >requestType = self.requestType( request ) >if requestType == 'get_request' This may not be quite portable across SNMP versions. That's why, a more formal way would be to do: >requestPdu = request.apiGenGetPdu() >if isinstance(requestPdu, rfc1157.GetRequestPdu) or \ > isinstance(requestPdu, rfc1905.GetRequestPdu): Thanks, ilya > I worked out a simple Twisted-based protocol object for use with PySNMP > 3 a while ago (based on Patrick's work). I've been trying to get more > people to look at the code so I can know if anything's terribly messed > up (all bugs are shallow...). > > Anyway, the package is available here: > http://members.rogers.com/mcfletch/programming/ > > It requires a fairly recent Twisted and PySNMP. At the moment it > handles get, getnext and getbulk queries on the manager/client, with the > rough beginning of an agent/server-side protocol as well (get only ATM). > > Eventual goal is to get all of the networking required for SNMP > implementations available from Twisted with fairly natural interfaces, > and with fairly intelligent handling of query results (e.g. when you > query for tables, giving you back the results as {tableOID: {subkey: > value}, ...} rather than raw OID:value sets). > > Feedback appreciated, > Mike |
|
From: <po...@or...> - 2003-11-24 18:59:28
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> "Mike C. Fletcher" <mcf...@ro...> writes: > I worked out a simple Twisted-based protocol object for use with > PySNMP 3 a while ago (based on Patrick's work). I've been trying to > get more people to look at the code so I can know if anything's > terribly messed up (all bugs are shallow...). And you can assume all of the bugs are my fault. So don't hesitate to let Mike know about them - you won't offend him. ;-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
|
From: Mike C. F. <mcf...@ro...> - 2003-11-24 18:50:00
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> I worked out a simple Twisted-based protocol object for use with PySNMP 3 a while ago (based on Patrick's work). I've been trying to get more people to look at the code so I can know if anything's terribly messed up (all bugs are shallow...). Anyway, the package is available here: http://members.rogers.com/mcfletch/programming/ It requires a fairly recent Twisted and PySNMP. At the moment it handles get, getnext and getbulk queries on the manager/client, with the rough beginning of an agent/server-side protocol as well (get only ATM). Eventual goal is to get all of the networking required for SNMP implementations available from Twisted with fairly natural interfaces, and with fairly intelligent handling of query results (e.g. when you query for tables, giving you back the results as {tableOID: {subkey: value}, ...} rather than raw OID:value sets). Feedback appreciated, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
|
From: Ilya E. <il...@gl...> - 2003-11-24 09:55:28
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> Here is a trivial example of a v1/v2c SNMP agent running over an async socket. Pls, note, this script binds to localhost at a non-priviledged port for security reasons: 8X------------------ import asyncore from pysnmp import asn1, v1, v2c from pysnmp import asynrole, error def cbFun(manager, cbCtx, (reqstr, src),\ (exc_type, exc_value, exc_traceback)): if exc_type is not None: print 'Error: ', exc_type, exc_value, exc_traceback return (req, rest) = v2c.decode(reqstr) oids = map(lambda x: x[0], map(asn1.OBJECTID().decode, \ req['encoded_oids'])) vals = map(lambda x: x[0](), map(asn1.decode, \ req['encoded_vals'])) print 'SNMP message from: ' + str(src) print 'Version: ' + str(req['version']+1) + ', type: ' + str(req['tag']) if req['version'] == 0: print 'Enterprise OID: ' + str(req['enterprise']) print 'Trap agent: ' + str(req['agent_addr']) for t in v1.GENERIC_TRAP_TYPES.keys(): if req['generic_trap'] == v1.GENERIC_TRAP_TYPES[t]: print 'Generic trap: %s (%d)' % (t, req['generic_trap']) break else: print 'Generic trap: ' + str(req['generic_trap']) print 'Specific trap: ' + str(req['specific_trap']) print 'Time stamp (uptime): ' + str(req['time_stamp']) for (oid, val) in map(None, oids, vals): print oid + ' ---> ' + str(val) asynrole.agent(cbFun, None, [('127.0.0.1', 1162)]) asyncore.loop() 8X---------------------- Hope this helps, ilya On Sat, 22 Nov 2003, Jaideep wrote: > Hi, > > I am using PySnmp V 2.0.5. I would like to write an application that listens for traps from agents in non-blocking socket mode (Using the AsynCore I/O engine). Please let me know if this is possible to do and if so, kindly post a small example demonstrating the same. I could not find a suitable example for V2 of PySnmp. > > Thanks, > JAideep. |
|
From: Jaideep <ja...@da...> - 2003-11-23 03:49:37
|
Hi, I am using PySnmp V 2.0.5. I would like to write an application that = listens for traps from agents in non-blocking socket mode (Using the = AsynCore I/O engine). Please let me know if this is possible to do and = if so, kindly post a small example demonstrating the same. I could not = find a suitable example for V2 of PySnmp. Thanks, JAideep. |
|
From: Ilya E. <il...@gl...> - 2003-11-03 15:58:01
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> > The bug : in module rfc1157.py in > \pysnmp-3.3.5\build\lib\pysnmp\proto\cli\ucd > the following line is in error [ skipped ] That's fixed in 3.3.6 release. Please, upgrade. > The usability problem is that the module uses port 161 as a default. I > believe Traps need to be sent to Port 162. Port 161 is the port for getting > and setting SNMP values. That's right. Fixed at CVS. Will take effect in 3.3.7. -ilya |
|
From: robert c. <rch...@ho...> - 2003-11-03 15:45:44
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> I was trying to get the example snmptrap.py working using snmpv1. I found one bug and one "usability problem". The bug : in module rfc1157.py in \pysnmp-3.3.5\build\lib\pysnmp\proto\cli\ucd the following line is in error self.apiSetGenericTrap(int(args[2])) it should be self.apiGenSetGenericTrap(int(args[2])) The usability problem is that the module uses port 161 as a default. I believe Traps need to be sent to Port 162. Port 161 is the port for getting and setting SNMP values. Bob Chancer _________________________________________________________________ Concerned that messages may bounce because your Hotmail account has exceeded its 2MB storage limit? Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es |
|
From: Ilya E. <il...@gl...> - 2003-10-07 13:41:17
|
A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>, <mailto:pys...@li...?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users> The CVS version is currently under a major development (a SNMPv3-style message&pdu dispatcher is being implemented) so the whole thing at CVS may be somewhat inconsistent. I suggest you trying pysnmp-3.3.5 which is smth like stable-beta. ;-) If you have some particular reasons for trying up the CVS version, please, let me know. > Today I checked out the CVS version of pysnmp, and executed 'python > setup.py install'. > > Once complete I notice that distutils copied pysnmpwalk to my > /usr/local/bin directory. I thought that maybe a nice place to start > trying pysnmp. After changing directories and executing the pysnmpwalk > script, I received the following warning: > > Traceback (most recent call last) > File "./pysnmpwalk", line 17, in ? > import pysnmp.mapping.udp.cli.ucd > ImportError: No module named cli.ucd > > Next I inspected the output from distutils and noticed that the > subdirectories "cli" and "ucd" under pysnmp/pysnmp/mapping/udp were not > being copied to /usr/lib/python2.2/site-packages/pysnmp/mapping/udp/ > > To solve the problem, by hand, I made the missing two subdirectories, > copied the appropriate files, and finally byte-compiled the files.. > > This fixes the symptom, but the problem still exists in the CVS.. So > someone who is a developer should see to it that this is addressed.. |
25 messages has been excluded from this view by a project administrator.
