Wireshark-dev: [Wireshark-dev] MPEG2-TS, DVB-SI, and DVB-GSE Dissectors
From: Alexander Adolf <alexander.adolf@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 14 Mar 2017 15:08:41 +0100
Dear Wireshark MPEG/DVB Developers,

My name is Alexander Adolf, and I have just newly subscribed to wireshark-dev. I
am the maintainer of EN300468, TS101211, all three documents of the TS102606 suite, and TS102771. This is of course part of my work as a member of the DVB Project. Today I am however not writing to you in this official capacity, but as a member of the broadcast community at large.

For many, many years I have been a most happy user of Wireshark for tracking down network problems. It is an indispensable tool to me, and IMO better than the vast majority of commercial low-level protocol analysers. And the manyfold of supported application layer protocols is simply unparalleled. Full stop.

Many thanks for making this project the great tool it is!

In this light, I thought I should try to also contribute something by sharing my expertise in DVB protocols. Apparently this is not entirely unselfish, as it could make Wireshark an even more indispensable tool in my day to day hacking.
;-)

My interest would be to contribute in two areas:

(1) A little bit of streamlining of how DVB PSI/SI is presented when analysing MPEG2-TS. I could e.g. imagine it to help readability if the PID were shown in the source and/or destination address field. Also, when interpreting DVB PSI/SI tables, some interpretations of identifiers doesn't seem to be quite accurate. 

(2) The DVB-GSE specification TS102606 has been split to become a three-part document. This added a logical link control protocol (LLC) and support for robust header compression for IP (ROHC-U / RFC 5795, RFC 3095, RFC 4815). I'd thus volunteer to help add support for both new features to the DVB-GSE implementation so that those PLPs/ISIs that carry GSE with IP payload can be presented as IP traffic in Wireshark. Test streams? Yes, that'll inevitably have to be part of the game.


For both topics, I would expect one likely guidance I'll be receiving to be "submit a patch". This is of course the most productive and easiest to manage way from the point of view of the regular contributors who are familiar with the code - i.e. you. To help me in making useful contributions, it would be great if someone familiar with the code in the mentioned "corners" of the code base could give me a short list of hints where to start looking.


Many thanks in advance and looking forward to your thoughts,

  --alexander