Hi.
Den 6. feb. 2007 kl. 09.10 skrev Graeme Lunt:
This must be the case where there is nothing else in the ASN.1 file
that can give you a hint as to how to decode the OCTETSTRING I guess.
This is correct. I have alot of client-server traffic with
proprietary ASN.1 definitions which uses this constructions.
But this functionality is also convenient when dissecting ASN.1
protocols with errors (wrong constructions). Wireshark will right
now present the data as single-ASN1-type, or just dump one or more
"BER Error: " strings. It would be really nice to be able to dump
part of the ASN.1 structure as unknown BER, much easier to pinpoint
what's wrong.
A couple of things spring to mind:
1) as a preference, "auto-detect" ASN.1 when decoding BER OCTETSTRINGs
and dissect as unknown BER.
This would be an easy approach, and probably easy to implement.
2) Add a menu item - "Decode Bytes in New Window" - which would bring
up something like "Show Packet in New Window" - but just decoding the
selected bytes as BER.
This would probably be the best solution as it's possible to use for
more than just ASN.1 protocols?
Is it possible to add another entry to the Packet List after such a
dissection?
I guess it is possible, but it would need some communication between
the dissector and the BER wtap.
What about an option to dissect as both known and unknown BER in the
same tree?
I think the option "Show internal BER encapsulation tokens" destroys
the overall overview, and it does not always show the ASN.1 structure
when errors in the protocol.
--
Stig Bjørlykke
