On Mar 4, 2013, at 10:46 AM, Ariel Burbaickij <ariel.burbaickij@xxxxxxxxx> wrote:
> Thank you for fast response, Guy.
>
>> not all link-layer header types that Wireshark can handle have corresponding pcap/pcap-ng link-layer header types - in particular, neither Tektronix rf5 nor HP nettl X.25 do
>
> So, is it something like work in progress and pcap/pcap-ng headers are going to be added or is it frozen for now?
Neither.
The list of link-layer header types is not frozen, but there is not, and probably never will be, an official tcpdump.org project or Wireshark to add particular link-layer header types; new types are added when somebody sends a request for a type to tcpdump-workers@xxxxxxxxxxxxxxxxx and the request is accepted.
The current list, and instructions on how to add values, are at
http://www.tcpdump.org/linktypes.html
>> So why isn't that good enough?
>
> Because we would like to replay (using tcpreplay) files in pcap format, among other things.
Adding a new link-layer header type won't be sufficient; you'll also have to write a DLT plugin for the new type:
http://tcpreplay.synfin.net/wiki/tcpeditDeveloper
What's the underlying link-layer type for the packets in your rf5 file?
What might be called for here is an *export* option to strip off metadata that's neither needed nor wanted by particular programs, converting encapsulations with no corresponding pcap/pcap-ng link-layer header type to one of those link-layer header types.
>> "Open packet hex dump text file",
>
> Let us try to work backwards here -- what is it actually supposed to do?
Let the user read a text file containing raw packet data in hex-dump form without requiring them to go to the command line and run text2pcap.
