Hi Anders, That is awesome! I must admit I was not familiar enough with the .asn and asn2wrs decoder to see how much I could do there. Therefore most of my code was outside of that part, but your approach is much cleaner.
If it's ok, I'd like to discuss directly how I can help to get more of the mapping integrated and to collaborate to get a more mature version of what I produced that might be eligible for merging as well. Thanks again Best regards, Robin On Tue, Apr 2, 2024 at 11:28 PM Anders Broman <a.broma...@gmail.com> wrote: > Hi, > I took a stab at integrating some of it into the MMS dissector > https://gitlab.com/wireshark/wireshark/-/merge_requests/15113. As far as > I understand it,this will only decode "proper IEC 61850" fields. > > Best regards > Anders > > Den sön 24 mars 2024 kl 19:41 skrev R Massink <robin....@gmail.com>: > >> Hello, >> >> I've created an initial version of an IEC-61850 dissector for wireshark. >> It is available here: https://github.com/robidev/iec61850-dissector. >> IEC-61850 is a mapping on top of MMS that uses a subset of MMS PDU's for >> its purpose; substation communication. >> >> While an MMS dissector, which IEC-61850 maps onto already exists, this >> MMS dissector lacks a lot of IEC-61850 specific context. For example, an >> unconfirmed-PDU in MMS, may in IEC-61850 be a Report, CommandTermination or >> Addcause. Each of these messages in turn may contain fields with specific >> meaning in the context of the protocol-mapping(e.g. first entry shall be >> ReportID, second field defines included optional fields that in turn define >> the field-names of subsequent entries). This type of information is quite >> hard to decode from the pure MMS packet, and therefore I created this >> dissector to assist with the IEC-61850 context-specific encoding. >> >> However, I am wondering if I did the integration right. As I need >> additional information during the MMS parsing to properly identify the >> correct IEC-61850 field, I have copied the MMS parser code, and included >> extra hooks to provide this information in a private structure during the >> BER decoding. Then during the actual mapping routines, I try to identify if >> it is a valid IEC-61850 packet, and if so, I add an additional IEC-61850 >> layer below the MMS entry in the dissector tree and replace the INFO column >> with IEC-61850 related information (e.g. an MMS 'read' request/response is, >> based on context a GetDataValue, or GetRCBValue, or ..). When the packet is >> not recognised as a known IEC-61850 service, the original (wireshark >> native) MMS dissector is called via call_dissector(), and no further >> processing happens. Also a setting(via prefs_register_bool_preference) is >> provided to stop any attempt to decode IEC-61850, and hand off the packet >> to the MMS dissector early if desired. >> >> Does anyone have suggestions on how this integration may be handled more >> elegantly?(i.e. not first calling my MMS function, before handing it back >> to the original one?) As I now replace the MMS dissector, and hand >> processing back if I conclude the packet was not IEC-61850. I had a look at >> heuristics, PINO's and the decode-as functionality. But these did not match >> for various technical reasons. The heuristic function is not an option, as >> the hook for the dissector is via >> register_ber_oid_dissector("1.0.9506.2.3",....), and it seems to me "decode >> as" does not allow to replace the MMS dissector. PINO seem to solve a >> different issue(as far as I understood). >> >> Or would my current solution be an acceptable approach to allow for a >> pull request in the future for merging this into the main wireshark branch? >> (assuming other conditions are met) >> >> Best regards, >> >> Robin >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
