[erlang-questions] snmpc: Compiling LLDP-MIB failled
fxmy wang
Hi guys,
So recently I’m toying with SNMP Development Toolkit and having trouble compiling standard LLDP-MIB. Errors shown below
2> snmpc:compile("LLDP-MIB.mib").
LLDP-MIB.mib: 655: Cannot AUGMENT the non-existing table entry lldpLocManAddrEntry
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpPortConfigTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpConfigManAddrTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpStatsTxPortTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpStatsRxPortTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpLocPortTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpLocManAddrTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpRemTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpRemManAddrTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpRemUnknownTLVTable => The default functions won't work properly
[LLDP-MIB.mib][WAR]: No RowStatus column in table lldpRemOrgDefInfoTable => The default functions won't work properly
{error,compilation_failed}
3>
The LLDP-MIB file is hosted on ieee802.org.
How should I deal with this?
Cheers,
Raimo Niskanen
it is this problem it fixes; it allows refinements of enum usertypes.
See https://bugs.erlang.org/browse/ERL-325
It will be released in OTP-19.3 shortly.
> <http://www.ieee802.org/1/files/public/MIBs/LLDP-MIB-200505060000Z.txt>.
>
> How should I deal with this?
>
> Cheers,
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
fxmy wang
fxmy wang
Hi guys,I've checked out [7f52af8](https://github.com/erlang/otp/tree/7f52af8875a1ab1ba96c6cb2403211bfc876639c) and tried again but the compilation still fails. =(Below attaches the log file when compiling LLDP-MIB (also uploaded to [gits](https://gist.github.com/fxmy/0c84243d387f972a725c68004cc02933)).Hope this log holds some useful information for the SNMP experts.Cheers,
2017-03-09 21:28 GMT+08:00 fxmy wang <fxm...@gmail.com>:
Good to know that Raimo.Thanks, I'm gonna wait for 19.3 and see what happens.Cheers,
Raimo Niskanen
We have debugged your issue, and the problem seems to be that
lldpLocManAddrEntry is used before defined, so if you move lines 640
through 698 down to before line 1296 in LLDP-MIB the compilation succedes.
Now we are trying to figure out if that MIB is valid or not.
On Sat, Mar 11, 2017 at 05:23:07PM +0800, fxmy wang wrote:
> Hi guys,
> I’ve checked out 7f52af8
> <https://github.com/erlang/otp/tree/7f52af8875a1ab1ba96c6cb2403211bfc876639c>
> and tried again but the compilation still fails. =(
>
> I’v updated the mib-compiling log to gist
> <https://gist.github.com/fxmy/0c84243d387f972a725c68004cc02933> in case
Raimo Niskanen
so this is probably a legitimate way to write a MIB.
If so our MIB compiler needs to be rewritten to do two passes; one handling
anything not augmented, and one handling augmentation.
Please write a Jira ticket at bugs.erlang.org so we get a case to
prioritize, if the workaround below to restructure the LLDP-MIB is not good
enough for you...
Best regards
/ Raimo Niskanen, Erlang/OTP
fxmy wang
Martin Bjorklund
fxmy wang <fxm...@gmail.com> wrote:
> 2017-03-14 22:53 GMT+08:00 Raimo Niskanen <
> raimo+erlan...@erix.ericsson.se>:
>
> > I have now tried with the 'smilint' tool and it does not find any errors,
> > so this is probably a legitimate way to write a MIB.
> >
> > If so our MIB compiler needs to be rewritten to do two passes; one handling
> > anything not augmented, and one handling augmentation.
patch is included if you're interested. The idea is that the
definitions are sorted so that any augment ends up after the augment
target; then the processing can be left as-is.
Unfortunately the code is not 100% correct; specifically it puts the
definition after the MODULE-COMPLIANCE so the compiler later complains
that the compliance reference is invalid (which is not correct (but it
works for us)).
In order to be really correct, the code needs to be completely
order-independent...
/martin
fxmy wang
That was indeed fast Martin. =）
For now I could live with restructuring LLDP-MIB though.
And bug reported here: ERL-375.
Cheers,
Hi,
fxmy wang <fxm...@gmail.com> wrote:
> 2017-03-14 22:53 GMT+08:00 Raimo Niskanen <
>
> > I have now tried with the 'smilint' tool and it does not find any errors,
> > so this is probably a legitimate way to write a MIB.
> >
> > If so our MIB compiler needs to be rewritten to do two passes; one handling
> > anything not augmented, and one handling augmentation.