Libsmi October 2000

libsmi@ibr.cs.tu-bs.de

6 participants
9 discussions

Re: [libsmi] MIB - VoiP phones
by Frank Strauss 27 Oct '00

27 Oct '00

Karsten> we are a company which develop and produce VoiP phones. Karsten> We want to control and monitoring our phone by using snmp. Karsten> Is there a MIB for devices like this? Karsten> Can anyone help us? This is a mailing list for libsmi, a software for parsing, accessing and compiling MIB modules. I would not expect that you reach the relevant people on this mailing list. You might consider to ask your question on the comp.protocols.snmp newsgroup. I don't know of any VoIP related MIB on the IETF standards track. -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

MIB - VoiP phones
by Karsten Wernicke 27 Oct '00

27 Oct '00

Hello, we are a company which develop and produce VoiP phones. We want to control and monitoring our phone by using snmp. Is there a MIB for devices like this? Can anyone help us? Thank you. Karsten Wernicke snom technology AG Karsten Wernicke Helmholtzstraße 2-9, Gebäude 6 10587 Berlin tel +49 30 39907830 fax +49 30 39907839 wernicke(a)snom.de www.snom.de -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

Re: [libsmi] lib/check.c in CVS doesn't compile
by Frank Strauss 26 Oct '00

26 Oct '00

Andrew Hood writes: > Subject: lib/check.c in CVS doesn't compile Oops. A few days ago, I forgot to submit the latest changes to the anoncvs repository. -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

lib/check.c in CVS doesn't compile
by Andrew Hood 26 Oct '00

26 Oct '00

/usr/src/misc/SNMP/libsmi/lib: cvs diff check.c Index: check.c =================================================================== RCS file: /anoncvs/libsmi/lib/check.c,v retrieving revision 1.6 diff -r1.6 check.c 601c601 < for (list2Ptr = rtypePtr->listPtr; --- > for (list2Ptr = rTypePtr->listPtr; -- Politicians are the same all over. They promise to build a bridge even where there is no river. -- Nikita Khrushchev -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

Re: [libsmi] Question on SMIv1/SMIv2 syntax
by Frank Strauss 17 Oct '00

17 Oct '00

BTW. What about your new python dump driver and dump-xml patch? -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

Question on SMIv1/SMIv2 syntax
by Pat Knight 17 Oct '00

17 Oct '00

I'm trying to understand the lexical structure allowed for descriptors (RFC 2578) in the following: descriptor OBJECT IDENTIFIER ::= { ... } Is RFC 2578 the correct reference for SMIv2 syntax? RFC 2578 allows mixed case descriptors in this place in the syntax, provided they start with a lower case letter. As I would expect from my limited use of your fine product, libsmi supports this correctly :-) However, we're seeing various vendor MIBs that have the initial letter in upper case. Did SMIv1 allow this or are the vendors just wrong? I can't find an RFC that seems to document the SMIv1 syntax with the clarity of RFC 2578 for SMIv2. As you'll appreciate, users object to having to modify the vendor MIBs to get them to compile. As a developer, I prefer the strict approach (if the source is wrong, fix it, don't accept it). However, I'm under some pressure from our customer support team to deliver what they term "a usability fix." We're not aiming at a technically sophisticated market. Can anyone offer advice as to the consequences if I were to modify the SMI lexer/parser to allow these descriptors to start with an uppercase letter? Would it break valid MIBs? Cheers, Pat -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

3 3

Re: [libsmi] Question on SMIv1/SMIv2 syntax
by Frank Strauss 17 Oct '00

17 Oct '00

Pat> I'm trying to understand the lexical structure allowed for Pat> descriptors (RFC 2578) in the following: Pat> descriptor OBJECT IDENTIFIER ::= { ... } Pat> Is RFC 2578 the correct reference for SMIv2 syntax? Yes. Along with RFCs 2579 and 2580. Pat> RFC 2578 allows mixed case descriptors in this place in the Pat> syntax, provided they start with a lower case letter. As I would Pat> expect from my limited use of your fine product, libsmi supports Pat> this correctly :-) Pat> However, we're seeing various vendor MIBs that have the initial Pat> letter in upper case. Did SMIv1 allow this or are the vendors Pat> just wrong? I can't find an RFC that seems to document the SMIv1 Pat> syntax with the clarity of RFC 2578 for SMIv2. I don't know MIBs that try to define OID names with an upper case first letter. Can you send me an example to find out whether there is some misunderstanding? In SMIv1 uppercase OID names are forbidden as well. Pat> As you'll appreciate, users object to having to modify the vendor Pat> MIBs to get them to compile. I would say: MIBs must be correct wrt the SMI language. Otherwise libsmi cannot guarantee to work correctly (or it's not defined what `working correctly' means). Pat> As a developer, I prefer the strict approach (if the source is Pat> wrong, fix it, don't accept it). I agree. Pat> However, I'm under some pressure from our customer support Pat> team to deliver what they term "a usability fix." We're not Pat> aiming at a technically sophisticated market. Pat> Can anyone offer advice as to the consequences if I were to Pat> modify the SMI lexer/parser to allow these descriptors to start Pat> with an uppercase letter? Would it break valid MIBs? It could. E.g., it could slashes with type definitions that differ only in the case of the first letter). There are some areas where the libsmi parser could be less pedantic. But uppercase OID names are definitely illegal. -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

Re: Libsmi patches and comments
by Frank Strauss 12 Oct '00

12 Oct '00

Pat> I've managed to build libsmi now on Solaris 2.6, Redhat Linux Pat> 6.2, HP-UX 10.20 and Windows NT 4. Great! Pat> The HP-UX build was interesting :-). Do you know of anyone else Pat> who's done it? No. Pat> I had to build with GNU make, gcc and configure --disable-shared Pat> to get things to work. HP's ANSI C compiler and make system just Pat> don't cope. Even with GNU make, there seems to be a problem with Pat> some of the automatically generated dependency files. I have to Pat> clear these out before each make. Pat> I've also added a new dump format, Python source, to smidump. Are Pat> you interested in this? Yes. Pat> It produces nested Python dictionaries containing the MIB Pat> information. I'm using this in some Python code that processes Pat> incoming SNMP traps. Pat> I based the code on dump-xml.c. While working on this, I noticed Pat> that the XML end tags for rows and tables aren't generated after Pat> the last column when the table's at the end of the MIB (or Pat> something like that). Thanks. I expect Juergen will look at this bug. ;-) Pat> I have a patch that fixes this. How do I submit patches? Please send me an email containing a patch in unified or context diff format. I'd also like to (look at and) integrate your Python dump module, if this would be ok with you. -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

Libsmi patches and comments
by Pat Knight 12 Oct '00

12 Oct '00

I've managed to build libsmi now on Solaris 2.6, Redhat Linux 6.2, HP-UX 10.20 and Windows NT 4. The HP-UX build was interesting :-). Do you know of anyone else who's done it? I had to build with GNU make, gcc and configure --disable-shared to get things to work. HP's ANSI C compiler and make system just don't cope. Even with GNU make, there seems to be a problem with some of the automatically generated dependency files. I have to clear these out before each make. I've also added a new dump format, Python source, to smidump. Are you interested in this? It produces nested Python dictionaries containing the MIB information. I'm using this in some Python code that processes incoming SNMP traps. I based the code on dump-xml.c. While working on this, I noticed that the XML end tags for rows and tables aren't generated after the last column when the table's at the end of the MIB (or something like that). I have a patch that fixes this. How do I submit patches? Cheers, Pat -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Libsmi October 2000