Comment # 7
on bug 8313
from Anders Broman
(In reply to comment #6)
> (In reply to comment #5)
>
> > After a very brief look a the specification I think extracting the ASN1 code
> > from the specification (if a complete asn1 description is missing) and
> > making it
> > an asn2wrs generated dissector is a better choice. It might require a bit of
> > .cnf magic though.
> > Regards
> > Anders
>
> hi,
> The SML specification is written in asn1, but it has some difference.
> Each element has a type-length field (TL), likely BER, but it's not the same.
> An TL-Field is one octet, the first 4 bits are the type and the last 4 bits
> are used for the length. Additional to that, if the MSB is set, the next
> octet is used for the length too and so on.
> I'm not an expert in asn1, but i think ans1 has no list type? But SML does
> heavily based on lists.
>
> That code works great and has the exact graphical presentation for the
> analysis of the data. It's part of an bachelor thesis and i missed the point
> at the beginning, that an asn1 convertation is possible.
>
> So why discard the whole code, to generate a new one, that does the exact
> same thing and needed to be customized?
>
> Regards
> Alex
As I said I haven't analysed the dissector nor the ASN1 specification and are
not discarding the dissector. just responding to Evans comments. If it's
possible to use the ASN1 spec it would be easier to adopt protocol updates
though.
You are receiving this mail because:
- You are watching all bug changes.
