Wireshark dissector bug fix and PcapNG writer implementation

[mdernovoi]

Change 1 (commit 73d8b): Bug fix

I fixed a small bug in the Wireshark dissector plugin.
Due to the gsmtapv3 specification requiring a start of data tag instead of padding to hdr_len, the following case is not handled properly.

If the packet content after the gsmtapv3 header is very short (e.g. an RRC Connection Reconfiguration Complete is only 2 bytes long) gsmtapv3_parse_metadata(t, tvbuffer(8, 4 * hdr_len - 8), 4 * hdr_len - 8) tries to access the nothing byte from the table below and causes an index out of bounds error.

byte	...	...	...	hdr_len*4 - 4	hdr_len*4 - 3	hdr_len*4 - 2	hdr_len*4 - 1	hdr_len*4
content	...	...	...	0xff	0xfe	RRC packet	RRC packet	nothing

The introduced check math.min(tvbuffer:len() - 8, 4 * hdr_len - 8) handles this situation.

Change 2 (commits bb402 ... ): Feature

I implemented a very simple PcapNG writer.

Basically, it works exactly the same as the existing pcapwriter.py and, thus, can be used as a drop-in replacement for the existing pcapwriter, since it also implements the AbstractWriter interface.

However, compared to pcap, the pcapng format has many new features (a nice overview). I was especially interested in the ability to add comments to packets via options fields. Therefore, this feature is also implemented. In addition, the code can easily be extended with other options generators.

Limitations of the current implementation:

• While the gsmtapv3 header also has a comment field, I think that using the standardized comments from pcapng is a more idiomatic solution. As a bonus, the current implementation supports all kinds of option fields (not just comments).
• The processing of idb and shb options in the constructor of the Pcapng writer could not be extensively tested. However, even if the current implementation might be flawed, the interface of the Writer should not require major changes in the future, since most parameters in pcapng are configured via option fields.

[lynxis]

A small comment about the comment: I would use the comment in GSMTAPv3 (either only or together with the pcapng comment).
GSMTAPv3 can be used also over network in difference to the pcapng.
Additional tooling which parses again the pcap & GSMTAPv3 data might want to use the comment of GSMTAPv3. Especially if the the generator of GSMTAPv3 writes additional data into it.
I usually use the packet comment of pcapng for my private notes.

[mdernovoi]

GSMTAPv3 can be used also over network in difference to the pcapng.

You mean for just sending cellular data wrapped in gsmtapv3 over the network as payload? That would be a cool use case. Haven't thought about it.

Additional tooling which parses again the pcap & GSMTAPv3 data might want to use the comment of GSMTAPv3. Especially if the the generator of GSMTAPv3 writes additional data into it.
I usually use the packet comment of pcapng for my private notes.

I am not advocating for removing the comment field from GSMTAPv3. Since pcapng comments can be edited in Wireshark, it might make more sense to use them for "private stuff" (e.g., some analysis notes) and the gsmtapv3 comments for generator metadata. Though, in this case, this argument would hold for almost any other protocol as well...

Fortunately, adding comments isn't the only feature of pcapng. "Options" fields can be used to specify all sorts of additional metadata and combining several pcapng files with cat without worrying about headers and stuff is also very useful (at least to me).