forked from osmocom/wireshark
![]() Remove mostly obsolete aclocal macros. Make GTK build flags a strict superset of GLib flags. Use GTK build variables for GTK GUI and GLib elsewhere. Add dependency flags explicitly instead of using WS_CPPFLAGS. Some minor improvements and fixes for missing/unnecessary variables (no impact on our test builds). Change-Id: I3e1f067a875f79d6516c1fa7af986f17a7a6b671 Reviewed-on: https://code.wireshark.org/review/14005 Reviewed-by: João Valverde <j@v6e.pt> |
||
---|---|---|
.. | ||
AUTHORS | ||
ChangeLog | ||
CMakeLists.txt | ||
COPYING | ||
Doxyfile | ||
Makefile.am | ||
Makefile.common | ||
Makefile.nmake | ||
moduleinfo.h | ||
moduleinfo.nmake | ||
opcua.c | ||
opcua_application_layer.c | ||
opcua_application_layer.h | ||
opcua_complextypeparser.c | ||
opcua_complextypeparser.h | ||
opcua_enumparser.c | ||
opcua_enumparser.h | ||
opcua_extensionobjectids.h | ||
opcua_extensionobjecttable.c | ||
opcua_hfindeces.c | ||
opcua_hfindeces.h | ||
opcua_identifiers.h | ||
opcua_security_layer.c | ||
opcua_security_layer.h | ||
opcua_serviceids.h | ||
opcua_serviceparser.c | ||
opcua_serviceparser.h | ||
opcua_servicetable.c | ||
opcua_servicetable.h | ||
opcua_simpletypes.c | ||
opcua_simpletypes.h | ||
opcua_statuscode.c | ||
opcua_statuscode.h | ||
opcua_transport_layer.c | ||
opcua_transport_layer.h | ||
plugin.rc.in | ||
README |
OpcUa Plugin: ============= This plugin implements the dissection of the OpcUa Binary Protocol. Authors: Gerhard Gappmeier & Hannes Mezger ascolab GmbH http://www.ascolab.com Overview: ========= OpcUa (OPC Unified Architecture) is a vendor and platform independent protocol for automation technology. It is the successor of the COM/DCOM based specifications OPC DA, OPC Alarm & Events, OPC HDA, etc. It unifies all this technologies into a single protocol. The specification describes abstract services that are independent of the underlying protocol. For now there exist protocol mappings to a Binary TCP based protocol and a SOAP based Webservice. Also a hybrid version will be available where the Binary messages are transported by a single webservice command called "Invoke". More information about the technology you can find on http://www.ascolab.com/index.php?file=ua&lang=en. Protocol Mappings: ================== Binary (TCP): The fastest and most flexible version (small footprint, no XML and SOAP necessary) can easily be tunneled (SSH, IPSEC, etc.), redirected, ... SOAP version: Easy to implement with verious tools like .Net, JAVA, gSOAP, etc. Better to communicate through firewalls via HTTP. SOAP with Binary Attchment: Combines the advantages of both. The messages are encoded as Binary, and transported via SOAP as binary attachment. The OPC Foundation offers a free Opc Ua stack implementation in ANSI C for all members. This stack implements the binary protocol as well as the SOAP version. It's easily portable to different kinds of operating systems from embedded devices to servers. This makes it easy to implement Opc Ua applications based on this stack and it is expected that the binary protocol will be the most used protocol. Nevertheless it's free to everbody to implement an own stack according to the specification. An own implementation of the SOAP version should be easy with the various SOAP toolkits. For more information see http://www.opcfoundation.org Known limitations: ================== * Only the security policy http://opcfoundation.org/UA/SecurityPolicy#None is supported, which means the encryption and signing is turned off. Machine-generated dissector: ============================ Parts of the OpcUa dissector are machine generated. Several of the files are marked "DON'T MODIFY THIS FILE!" for this reason. However, the code to create this dissector is not part of the Wireshark source source code distribution. This was discussed prior to the plugin's inclusion. From http://www.wireshark.org/lists/wireshark-dev/200704/msg00025.html : ~~~ > a lot of the code seems to be autogenerated (as the comments suggest) > It might make sense to include the sources and the build process instead > of the intermediate files (if the amount of code/tools to build the > files seems reasonable). The reason: When people start to hack your code > (e.g. to remove warnings on a compiler you don't even think about), > you'll might get into annoying trouble with merging code the next time > you've update the upcua files. > > I'm sorry, but I cannot give you the sources of the code generator, because they are owned by the OPC Foundation. I only extended the existing code generator to produce also wireshark code. It's .Net based so I guess you don't want to have it anyway ;-) ~~~ So, if changes must be made to the machine-generated files, it just means the upstream source will have to be modified before pushing any updates back to Wireshark. Of course it also means that care must be taken when applying patches from upstream to ensure local changes aren't reversed.