--- Begin Message ---
> Ideally, you would have a document somewhere that would describe your capture
> format. We might want to review the format.
I would be able to
> I would note that if you are just adding logging, and you just want to use
> pcapng, that you might store your ethernet captures as normal EN10B, and your
> logging in a new LINKTYPE_, which was specific to your log format.
> In pcapng, you can mix different LINKTYPEs, in a single file.
> (But, not in pcap, which is/was a major reason pcapng was designed)
This is exactly what we do, beside of one exception.
Our log format does contain a "content ID" to allow for future updates and
different structures to be transportet within the same format.
One of the content types we have specified is SIP packages. Since SIP is
frequently encrypted and we do not want to break the encryption of the customer
we insert decrypted SIP messages as a separate element to allow for better
debugging of encrypted connections. Since we did not find a suitable LINKTYPE_
for the information we have available when logging, we decided to include these
as a internal content ID which however is mapped to SIP
> Then you can ideally follow:
>
> https://github.com/the-tcpdump-group/libpcap/blob/master/doc/DLT_ALLOCATE_HOWTO.md
> send a pull request.
We are happy to do so as soon as the dissector is uploaded to github as well.
We plan to release the dissector on github as soon as we have the ID to update
the code with the proper ID. The dissector contains some documentation already,
beside that we can release the C structs that define the format elements.
Since we plan to potentially include more elements in the future, we decided to
use a format where we can just assign a new internal content ID for each update
to the structures.
Best regards
Frank Gorgas-Waller
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
