Wireshark-bugs: [Wireshark-bugs] [Bug 11754] Add JSON as an output format

Date: Mon, 13 Jun 2016 18:10:00 +0000

Comment # 11 on bug 11754 from
(In reply to Guy Harris from comment #7)
> If you can't construct the raw binary data of packets (and necessary
> metadata) from it, it's not a capture file format.
> 
> You can't construct the raw binary data of packets from a dump of the
> protocol tree; there might be missing pad fields, there might not be the raw
> binary data for a particular field, etc., etc., etc.
> 
> So, no, PDML and JSON aren't capture file formats, any more than PDF is a
> document revisable form.
> 
> You could have a tool that does its best to construct, say, a
> ${WORD_PROCESSOR} document from a PDF file, and the tool might often succeed
> in giving you something to start with, but you might still have to finish
> the job manually, e.g. de-hyphenating words hyphenated in the process of
> building a PDF.
> 
> Similarly, somebody could try to write a program that takes the PDML or JSON
> dissection of packets and tries to reconstruct the raw packet data - it
> might have to have as significant knowledge of how the protocol is
> dissected, making it *not* a candidate for libwiretap - but it might leave
> you with something that needs more manual work.

I was thinking of a sort of abstraction of PCAP in json. I mean

  {
    magic_number: ...,
    version_major:...,
    ...
    packets: [
        {  ts_sec:..., ts_usec:..., packet_data:"<the entire packet payload>"
},
        {  ts_sec:..., ts_usec:..., packet_data:"<the entire packet payload>"
},
        ...
    ]
  }

The packets object could contain the dissection or not, but, if it contains the
payload, the translation to pcap is reversible. I'm talking about pcap because
it's the format I know better, but the abstraction could come from other
formats as well.


You are receiving this mail because:
  • You are watching all bug changes.