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....@gmail.com>: > 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 >
___________________________________________________________________________ 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
