Wireshark-dev: Re: [Wireshark-dev] Advice on how to integra IEC-61850 protocol mapping onto the

From: Anders Broman <a.broman58@xxxxxxxxx>
Date: Wed, 3 Apr 2024 11:56:36 +0200
Hi,
Yes you can contact me privately for further discussions if you want.
Best regards
Anders

Den tis 2 apr. 2024 kl 23:57 skrev R Massink <robin.dev@xxxxxxxxx>:
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.broman58@xxxxxxxxx> 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.dev@xxxxxxxxx>:
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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe