Convert::ASN1 just doesn't seem to handle MIBs at all

[SineSwiper]

use Convert::ASN1;
use Data::Dump;

my $asn = Convert::ASN1->new;
$asn->prepare_file('snmpv2.mib');
dd $asn->error;
$asn->prepare_file('snmpv2-tc.mib');
dd $asn->error;
$asn->prepare_file('snmpv2-smi.mib');
dd $asn->error;
$asn->prepare('
org            OBJECT IDENTIFIER ::= { iso 3 }  --  "iso" = 1
dod            OBJECT IDENTIFIER ::= { org 6 }
internet       OBJECT IDENTIFIER ::= { dod 1 }
');
dd $asn->error;
$asn->prepare('
ExtUTCTime ::= OCTET STRING(SIZE(11 | 13))
');
dd $asn->error;

# Outputs...
"syntax error ::= BEGIN\n\nIMPORTS\n    MODULE-IDENTITY, \n"
"syntax error ::= BEGIN\n\nIMPORTS\n    TimeTicks        \n"
"syntax error ::= BEGIN\n\n-- the path to the root\n\norg \n"
"syntax error ::= { iso 3 }  --  \"iso\" = 1\ndod        \n"
"Parse error before (SIZE(11 | 13))\n\n"

I can't seem to make any progress in getting C:A to parse a full or partial MIB, even with the basic, low-level SNMPv2 standards.

[SineSwiper]

It looks like the gaps in the parser are:

• Length/size restrictions (Net::LDAP::ASN's C:A parsing suffers from this gap, too)
• Enum support (INTEGER { values })
• MACRO support
• DEFINITIONS support (you already have this in another Issue)
• IMPORTS support (maybe as a config option to auto-read other files)

SNMP::MIB::Compiler has some ideas, though it's more geared SNMP specifically. I think Convert::ASN1, with some tweaks and parser additions, can parse an entire MIB, load all of the IMPORTS needed, and be able to read an ASN.1 packet in that format.

A good test would be SNMPv2-MIB, which references SNMPv2-SMI / TC / CONF. If it can parse those, it can parse anything, including other standards like LDAP.

[gbarr]

Actually to parse a MIB the Convert::ASN1 parser would need a complete re-write. It took too many short cuts to support the part of ASN.1 that it currently does

[SineSwiper]

I noticed that the parser itself was in E?yapp. It might be worth translating that into a more modern language like Pegex. (Disclaimer: I'm pretty active in Pegex's development...)

I guess the trickiest part with supporting the later three bullets would be dynamically creating "tokens" as they are defined. Recursive parsing, piecemeal parsing; not sure how that would be done off of the top of my head.

Also, asn1c's code might have some ideas on how to re-engineer it.

Let me know when you want to tackle this. I'd be interested in helping out.

[SineSwiper]

The core of Convert::ASN1 seems to be a parser that creates a tree and "replays" the tree with a parser and receiver. This is also, in essence, what Pegex does with its own parsing language:

1. Parse the Pegex file and compile into a tree.
2. Write the grammar tree as a module.
3. Feed input using Pegex::Parser, using the tree as the grammar, and a potentially custom Receiver to mold the output.
4. Use the output tree any want you wish.

This basically means that Convert::ASN1 can (using Pegex) parse ASN.1 language into a Pegex "grammar tree". This can be saved as a module or created on-the-fly. From there, decoding ASN.1 input into a hash tree would involve using that grammar tree, running it through a special Parser/Receiver pair (subclasses of Pegex::Parser/Tree), and spitting out a result tree. Encoding would require something special from us (like a Refkind parser of some sort), but is doable, and would ultimately help out in Pegex development.

This wouldn't immediately give us support for the above, but it would enable us to modify how the grammar tree get created to support those. I'll give some more serious thought on how this would work and try to produce a prototype.