Some time ago I wrote a program that reads Microsoft IIS web log files and converts them into PCAP-NG format. I then wrote a matching dissector to produce nice neat output. I want to rewrite it because:
- The field names and data types are defined in the first record of the PCAP-NG file – this is how the dissector knows the layout of the file
- Each data record is encapsulated in a dummy Ethernet frame and I want to eliminate this
- I’d like to make it more general so that it can also deal with CSV, TSV and, later, variable format log records
My plan is to:
- Insert the field name and data type information into a new IDB option block
- Write a plugin_if function to enable a dissector to get a pointer to the IDB information and hence get my hands on the field names and data types
- Define a new link type for the IDB; working name is Text Data Format (TDF)
- I understand that I have to ask for this (a value for DLT_TDF) from the
tcpdump-workers@xxxxxxxxxxxxxxxxx
- This means that the TDF records would be below (within) the Frame
- Add a new WTAP_ENCAP_TDF definition in wtap.h
- Add an appropriate entry to the pcap_to_wtap_map[] array in pcap-common.c
- Write a dissector for the TDF records (dissect_tdf)
- Use dissector_add_uint("wtap_encap", WTAP_ENCAP_TDF, tdf_handle) to hook the dissector into the correct point in the table
Does this look like a reasonable plan?
Have a missed an existing feature that I should be using? I remember seeing Graham Bloises presentation on three ways to write dissectors; C, LUA and something else. Wasn’t the something else about using a high-level description of the
packets. I’d look it up but I’m on a plane at the moment.
Thanks and regards…Paul
PS: Bit of an update. Just made the changes to eliminate the Ethernet headers (with dummy DLT_TDF value), modified my dissector and it works! Wow - that was a lot simpler than I thought.
