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
