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 _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
