search

real-logic / simple-binary-encoding

Simple Binary Encoding (SBE) - High Performance Message Codec
Apache License 2.0
3.12k stars 523 forks source link

Wireshark generator #504

Open skizzay opened 7 years ago

skizzay commented 7 years ago

Since the encoded data is typically transferred some network or another, it makes sense to create a Wireshark dissector to view the live data transmitted on the network.

da4089 commented 7 years ago

SBE is not self-describing: in order for Wireshark to decode an SBE stream, it would need the schema file. I guess your proposal is to generate a dissector module as an alternative output from sbe-tool?

Wireshark can dynamically load dissectors. It would need to deal with different platforms, but I guess it would be possible to generate the source code, cmakefile, and perhaps the Visual Studio project file.

The basic decoding work would likely not be too difficult, but it would be quite complex to actually emit a working .so/.dll/.dylib.

mjpt777 commented 7 years ago

This type of requirements was the driver for the On-The-Fly (OTF) decoding ability for SBE from serialised IR.

tmontgomery commented 7 years ago

It is quite possible to make a plugin for Wireshark that used the OTF decoder when supplied with an SBE IR file.

da4089 commented 7 years ago

Similar things for Wireshark would be ASN.1, DCE/MS-RPC IDL, CORBA IDL, GPB, etc. I don't recall it having the option to load those at runtime. Looking at the Wireshark source code, it appears the existing ASN.1 and DCE-RPC dissectors are generated, compiled, and linked at build time. The set of supported protocols doesn't appear to be extensible either in the UI or via a configuration file.

It does support loading modules at startup from shared objects however. So ... presumably the internal structures can be extended, at least during initialisation. Given that, I guess a manually-written dissector that processed one or more IR (or even raw XML) schema files at initialisation time could probably create a matching set of dissectors.

tmontgomery commented 7 years ago

Dissectors can be configured. So, it should be relatively straight forward to use that config to hold SBE IR file location or even a list of them. @dameiss might know more in this regard.

da4089 commented 7 years ago

I figure a directory into which SBE IR files can be copied, each of which would then create an entry in the dissectors table at startup, would be good?

tmontgomery commented 7 years ago

Perhaps. Knowing which dissector to call in a chain can be a little tricky, though.

da4089 commented 7 years ago

I've written a few Wireshark dissectors. I'd be happy to write one for SBE, if someone is willing to pay for the work.

tmontgomery commented 7 years ago

I've written a few as well. Same. Too much other stuff to do.

omi-dev-one commented 7 years ago

Sorry for the late comment. Just saw this. I have already written a wireshark dissector generator for Sbe as part of a larger source generation project. I posted some recent cme sbe protocols here:

https://github.com/Open-Markets-Initiative/wireshark-lua

zamhassam commented 3 years ago

Apologies also for the necrobump, but I too came across this thread looking for something similar to help diagnose a network issue. In the end I implemented a code generator. The source is available here for public consumption: https://github.com/TransFICC/sbe-wiresharker

The project currently spits out a Lua dissector but it has a pretty extensive integration test suite and I split the code generator into a front end parser and back end generator so it could be extended with an alternative back end if a C dissector was ever required.