Fwd: Re: [PATCH] sturcture name change.
HI,
FYI...in case you missed seeing this.
X-Mailer: exmh version 2.0.2 To: Harrie Hazewinkel harrie@covalent.net Cc: net-snmp-coders@lists.sourceforge.net Subject: Re: [PATCH] sturcture name change. From: Dave Shield D.T.Shield@csc.liv.ac.uk Sender: net-snmp-coders-admin@lists.sourceforge.net X-BeenThere: net-snmp-coders@lists.sourceforge.net X-Mailman-Version: 2.0.5 List-Help: mailto:net-snmp-coders-request@lists.sourceforge.net?subject=help List-Post: mailto:net-snmp-coders@lists.sourceforge.net List-Subscribe: http://lists.sourceforge.net/lists/listinfo/net-snmp-coders, mailto:net-snmp-coders-request@lists.sourceforge.net?subject=subscribe List-Id: A list for net-snmp developers to converse over <net-snmp-coders.lists.sourceforge.net> List-Unsubscribe: http://lists.sourceforge.net/lists/listinfo/net-snmp-coders, mailto:net-snmp-coders-request@lists.sourceforge.net?subject=unsubscribe List-Archive: http://lists.sourceforge.net/archives//net-snmp-coders/ Date: Thu, 12 Jul 2001 11:29:31 +0100
I've occasionally had some problems with libSMI objecting tosome of the UCD-provided MIB files. The effect of this being that the MIB initialisation fails, and the UCD tools refuse to run (without saying anything, of course).
I've just been bitten by this again, and investigated in more detail. The problem appears to lie with the severely cut-down version of SNMPv2-SMI that we've traditionally shipped. This is missing a number of core definitions, that were built into our parser, but libSMI is expecting to find here. If you copy the 'normal' version of SNMPv2-SMI into place, then the library seems happy.
As a placeholder, in case anyone wants to investigate *exactly* what's going wrong - the problem bites at line 645 of SNMPv2-TC. This is where the Textual Convention "TimeStamp" is being defined, using the base type "TimeTicks" from SNMPv2-SMI (which is missing from our version). libSMI recognises this error, and calls 'printError' to display unknown type `TimeTicks'
But shortly after this, it calls 'printError' again, with a (fatal) 'internal error' - at which point it bombs out.
This appears to correspond to
typeDeclarationRHS: TEXTUAL_CONVENTIONblock (lines 1719ff of parser-smi.y in my version) which includes:
if (($10) && !($10->export.name)) { /* * If the Type we found has just been * defined, we don't have to allocate * a new one. */ $$ = $10; } else { if (!($10)) smiPrintError(thisParserPtr, ERR_INTERNAL); /* * Otherwise, we have to allocate a * new Type struct, inherited from $10. */ $$ = duplicateType($10, 0, thisParserPtr); }It's that ERR_INTERNAL that seems to be the trigger.
I'm not familiar enough with either libSMI, or yacc/bison, to offer any suggestions of how this abort could be avoided.
But a clean copy of the SMI file seems to solve the problem, so personally, I'm happy to leave it like that (for now, at least).
Dave
Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/net-snmp-coders
-- !! 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@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi!
David> FYI...in case you missed seeing this.
David, thank you for forwarding this. -- Yes, libsmi is not really tolerant to incorrect MIB modules. This could be a problem with some applications. However, if you feed only MIBs to it, that smilint does not complain about, everything should be fine. So, I agree to Dave's proposal to simply use the complete and correct modules that come with libsmi.
-frank -- !! 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@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Yes, libsmi is not reallytolerant to incorrect MIB modules. This could be a problem with some applications. However, if you feed only MIBs to it, that smilint does not complain about, everything should be fine.
That the line that I thought you'd take :-) Which is partly why I haven't been too bothered about reporting this yet. (Thanks for forwarding it though, David).
The problem we'll have with using libSMI in the Net-SNMP suite, is that there's an existing base of "broken" MIBs out there from old UCD-SNMP installations. Sure, we'll plaster the new release with warnings about "you *MUST* install the new (fixed) MIB files" but you know as well as I do, that there are plenty of people who won't bother reading such warnings, and end up bombarding us with complaints that it doesn't work.
Long term, the right approach is definitely to eradicate the old broken MIB files completely. But it would be desirable (from our point of view at least) if we could handle this situation in some less drastic manner than simply exiting. Even if it's just the 'exit hook' mentioned in the comment in 'printError()' - so we could get the application to spit out the message about installing the fixed MIB files.
There's no urgency about this yet, since the use of libSMI is still only within development code (and I think it's only me and Harrie that are looking at this). But I'm trying to think ahead (for once), and tackle user support problems before they bite us!
Dave
-- !! 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@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi!
Dave Shield writes:
Dave> The problem we'll have with using libSMI in the Net-SNMP suite, Dave> is that there's an existing base of "broken" MIBs out there from Dave> old UCD-SNMP installations. Dave> Sure, we'll plaster the new release with warnings about Dave> "you *MUST* install the new (fixed) MIB files" Dave> but you know as well as I do, that there are plenty of people who won't Dave> bother reading such warnings, and end up bombarding us with complaints Dave> that it doesn't work.
Are you talking about all modules including Standard MIB modules or just UCD-SNMP/NET-SNMP specific modules? I think, a libsmi-based NET-SNMP installation should get rid of all Standard modules and put the specific modules to /usr/local/share/mibs/site or to a new directory /usr/local/share/mibs/net-snmp and add this directory to the smi search path.
Dave> Long term, the right approach is definitely to eradicate the old Dave> broken MIB files completely. But it would be desirable (from our Dave> point of view at least) if we could handle this situation in some Dave> less drastic manner than simply exiting. Dave> Even if it's just the 'exit hook' mentioned in the comment in Dave> 'printError()' - so we could get the application to spit out the Dave> message about installing the fixed MIB files.
Unfortunately, the data structures can get really broken in these cases, so that you really should not just continue. It could be even more harmful. :-/
However, I agree: For a long time, I wish to have the possibility to get back to the state before starting to parse a broken MIB. But this is not easy to achieve.
Dave> There's no urgency about this yet, since the use of libSMI is Dave> still only within development code (and I think it's only me and Dave> Harrie that are looking at this). But I'm trying to think ahead Dave> (for once), and tackle user support problems before they bite us!
I suggest to send out a clear statement to people who expect that broken MIBs should be `somehow usable':
BROKEN MIBS ARE BROKEN! DON'T USE THEM! Get the current MIBs that come with the current NET-SNMP release. In case of your private MIBs, fix them! smilint helps you to do so. ;-)
-frank -- !! 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@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
I think, a libsmi-basedNET-SNMP installation should get rid of all Standard modules and put the specific modules to /usr/local/share/mibs/site or to a new directory /usr/local/share/mibs/net-snmp and add this directory to the smi search path.
Yes - that sounds like a sensible basic approach. (Though obviously, the Net-SNMP developers will have to have their input before I plough ahead regardless :-))
But if we retain compatability with the current configuration mechanisms (environment variables and/or .conf file settings), then pre-existing settings might point the new library back to the old UCD-provided files.
But this is fundamentally a Net-SNMP headache - rather than a problem with libSMI. Though that error-hook would be useful.
I suggest to send out a clear statement to people who expect that broken MIBs should be `somehow usable':
BROKEN MIBS ARE BROKEN! DON'T USE THEM! Get the current MIBs that come with the current NET-SNMP release.
In this particular situation, it's not the user's fault that the MIBs are broken.
<shuffles feet and looks embarrassed>
The SMI MIB file (that's now taking down the libSMI parser) was deliberated emasculated to fit in with the UCD MIB parser. Yes, I *know* this was the Wrong Thing To Do (though I suspect it might date back to the underlying CMU code). But we've got to deal with life as it is, not as we'd like it to be!
We haven't really discussed how we're going to go about shipping the net-snmp/libSMI combination - and I suppose one approach might be to ship the two code trees together, and hack in an explicit warning message, just before that exit. But I can't say that strikes me as a particularly clean or acceptable way of dealing with this! Harrie and I are OK for the moment (now we know what to avoid), so we can think about this problem at leisure, rather than trying to fix it on the fly.
Dave
-- !! 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@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Dave Shield wrote:
BROKEN MIBS ARE BROKEN! DON'T USE THEM! Get the current MIBs that come with the current NET-SNMP release.
In this particular situation, it's not the user's fault that the MIBs are broken.
Not always. The problem is also that many people have written MIB modules themselves as well which are not part of net-snmp or libsmi. Those people use for instance the PERL extension, they suddenly cannot work any more.
I indeed agree with the fact "BROKEN MIBS ARE BROKEN!", but those MIBs are used. I also beleive it would be good practise of them to fix their MIB modules, but will they really do?? I have seen MIB modules around for a long time which were even half SMIv1 and half SMIv2. When I mentioned this to them they did not care about it. It worked for them and probably there customers.
I believe we need to build in some flexibility that things will work regardless if the MIB module is broken (in the full sense). Of course it should recover those errors which it can and obvious mistakes. This is not so much a requirement for libsmi itself as used stand-alone, but it is (IMHO) a requirement for applications that embed libsmi. It brings the use of libsmi to another level, of not just checking the correctness of the MIB module.
Unfortenately, the disadvantage is that people can continue to make broken MIB modules, but the world is not perfect either.
Harrie
Harrie Hazewinkel writes:
Harrie> I indeed agree with the fact "BROKEN MIBS ARE BROKEN!", but Harrie> those MIBs are used. I also beleive it would be good practise Harrie> of them to fix their MIB modules, but will they really do?? I Harrie> have seen MIB modules around for a long time which were even Harrie> half SMIv1 and half SMIv2. When I mentioned this to them they Harrie> did not care about it. It worked for them and probably there Harrie> customers.
Harrie> I believe we need to build in some flexibility that things Harrie> will work regardless if the MIB module is broken (in the full Harrie> sense). Of course it should recover those errors which it can Harrie> and obvious mistakes. This is not so much a requirement for Harrie> libsmi itself as used stand-alone, but it is (IMHO) a Harrie> requirement for applications that embed libsmi. It brings the Harrie> use of libsmi to another level, of not just checking the Harrie> correctness of the MIB module.
I have a strong opinion about this: Broken MIBs should be rejected.
I agree that libsmi could be improved to recover more gracefully in some cases. And this is what I heard Frank saying as well. But adding code to accept modules that for example mix SMI versions is definitely not the direction I want to go.
We are facing the following situation:
(a) There are so many broken MIB because so many lenient parsers do accept them. (b) There are so many lenient parsers that accept broken MIBs because there are so many broken MIBs.
This circular logic needs to be broken up. And the way to do this is to provide people with good parsers that help them to fix the broken modules. Yes, it will not be without pain for everyone. But in the longer term, there will be clear benefits.
/js -- !! 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@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Juergen Schoenwaelder wrote: [snip]
I have a strong opinion about this: Broken MIBs should be rejected.
I think this is more an academic/perfect world view. NET-SNMP will be used in conjunction of MIB modules shipped by vendors. These vendors are not using NET-SNMP and their customers are using UCD-SNMP without their knowledgde. Now these customers upgrade to NET_SNMP and everything breaks, because of the broken MIB module. Yes, I agree the vendors need to improve their MIB modules. But in real life the customer has a problem directly.
I agree that libsmi could be improved to recover more gracefully in some cases. And this is what I heard Frank saying as well. But adding code to accept modules that for example mix SMI versions is definitely not the direction I want to go.
I agree, that is just an example. Even though, my own MIB compiler is flexible with this.
We are facing the following situation:
(a) There are so many broken MIB because so many lenient parsers do accept them. (b) There are so many lenient parsers that accept broken MIBs because there are so many broken MIBs.
This circular logic needs to be broken up. And the way to do this is to provide people with good parsers that help them to fix the broken modules. Yes, it will not be without pain for everyone. But in the longer term, there will be clear benefits.
I am sure all vendors will agree, but that they fix the problem. The bigger problem is taht sometimes MIB modules are already shipped.
There is also another view of this. Libsmi as such is currently focussed on parsing and testing MIB modules for there syntactical and semantical correctness. Usage of libsmi inside NET-SNMP is I beleive different. It is there focussed on getting more knowledge of the managed objects at the manager side. I beleive that the resulting libsmi need to be that when used as parser/tester it should reject broken MIB modules and when used inside applications it should attempt as much error recovery as possible. After the error recovery it still may provide all problems of the MIB module, but the application may start using it.
Correct me if I am wrong Dave, but I beleive you are looking for something like this too.
Harrie
Hi!
I suggest to send out a clear statement to people who expect that broken MIBs should be `somehow usable':
BROKEN MIBS ARE BROKEN! DON'T USE THEM! Get the current MIBs that come with the current NET-SNMP release.
Dave> In this particular situation, it's not the user's fault Dave> that the MIBs are broken.
Ok. But it's the user's fault to upgrade the NET-SNMP release without upgrading the configuration.
Dave> The SMI MIB file (that's now taking down the libSMI parser) was Dave> deliberated emasculated to fit in with the UCD MIB parser. Dave> Yes, I *know* this was the Wrong Thing To Do (though I suspect Dave> it might date back to the underlying CMU code). But we've got Dave> to deal with life as it is, not as we'd like it to be!
Let me give a general blabla statement...
I think, it's for any large and long standing project like NET-SNMP to evolve and to make progress, even if it causes some changes that cause incompatibilties in the first place. If a number of changes go to a new release, it's reasonable to say to the users: ``If you really need compatibility with the old stuff, then keep with the old stuff. If you would like to take advantage of the new stuff, then you have to adapt some things.'' Otherwise, you add another dimension of nasty compatibility overhead with every improvement. Let's put the developers' energy in improvements instead of compatibility.
Dave> We haven't really discussed how we're going to go about shipping Dave> the net-snmp/libSMI combination - and I suppose one approach might Dave> be to ship the two code trees together, and hack in an explicit Dave> warning message, just before that exit. Dave> But I can't say that strikes me as a particularly clean or Dave> acceptable way of dealing with this! Harrie and I are OK for Dave> the moment (now we know what to avoid), so we can think about Dave> this problem at leisure, rather than trying to fix it on the fly.
Sure, I agree shiping NET-SNMP with a patched libsmi wouldn't be what like to have.
I just tried to track down the problem that causes the termination. Can you please send me the module in question?
-frank -- !! 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@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
[ Sorry for the delay in replying - I've been off for a weekend's choral singing!]
Dave> In this particular situation, it's not the user's fault Dave> that the MIBs are broken.
Frank> Ok. But it's the user's fault to upgrade the NET-SNMP release without Frank> upgrading the configuration.
Sort of. But the user *using* the system might not be the same as the person who did the upgrade, so might not have realised that their personal configuration settings needed to be changed.
Frank> I think, it's for any large and long standing project like NET-SNMP to Frank> evolve and to make progress, even if it causes some changes that cause Frank> incompatibilties in the first place.
I'd go along with that.
My attitude towards the {UCD->Net}-SNMP transition is that backwards compatability is in general _desirable_, but is secondary to having a clean, maintainable, shiny new system with go-faster stripes. If (for any particular feature) we can have both, then well and good. But if we can only keep backwards compatability by constraining the new stuff, then we look forward rather than back (documenting the changes, of course!)
As far as the MIB parsing is concerned - I'm not too unhappy about rejecting broken MIBs. What I *am* worried about is just dropping out without any word of explanation. Partly this may well be down to how we use 'smiSetFlags' - I need to investigate this further. But the application exit within libSMI itself does rather hamper us somewhat.
I just tried to track down the problem that causes the termination. Can you please send me the module in question?
OK - appended. [Warning - not to be viewed by those of a nervous disposition!]
Further checking seems to indicate that the current UCD distribution *does* actually come with a copy of SNMPv2-SMI that libSMI's happy with. So it's only lazy gits (like me!) who haven't installed the recent UCD-provided MIBs that will get bitten. But that's basically the same argument as above - just shifted back a bit further.
Dave
participants (5)
-
Dave Shield -
David T. Perkins -
Frank Strauss -
Harrie Hazewinkel -
Juergen Schoenwaelder