On Mar 4, 2013, at 2:47 PM, Ariel Burbaickij <ariel.burbaickij@xxxxxxxxx> wrote:
>> And can tcpreplay replay MTP2 files? Are there any links to which it can write?
>
> I re-read the article here
> http://tcpreplay.synfin.net/wiki/tcpeditDeveloper#DLTPlugins
>
> and I think I understand what you hint at. There is no DLT Plugin for MTP2 yet, so one still needs to be written here.
> is this what you mean?
That's part of what I mean.
I also mean that whatever mechanism tcpreplay needs to *send* packets has to be able to open something to allow it to send MTP2 packets over whatever type of link is necessary (E1?). I don't know what mechanism it uses, or whether it has a plugin facility for mechanisms; as of libpcap 0.9, libpcap has the ability to transmit packets on some platforms, using the same mechanism used to capture packets, but none of those mechanisms support transmitting MTP2 packets with libpcap.
However, looking at that page again, it appears to talk about plugins for tcpedit, not tcpreplay. The tcpreplay page:
http://tcpreplay.synfin.net/wiki/tcpreplay
says
tcpreplay has evolved quite a bit over the years. In the 1.x days, it merely read packets and sent then back on the wire. In 2.x, tcpreplay was enhanced significantly to add various rewriting functionality but at the cost of complexity, performance and bloat. Now in 3.x, tcpreplay has returned to its roots to be a lean packet sending machine and the editing functions have moved to tcprewrite and a powerful tcpreplay-edit which combines the two.
so it might be that tcpreplay itself doesn't care about the DLT_ type of what it's replaying, it might just check to make sure that the DLT_ values are the same for the interface/file from which it's getting the packets to send and the interface on which it's sending them. That *still* means that, if it's using libpcap to send the packets, it can't send MTP2 packets, and that would require either that the underlying mechanism libpcap would be using to send the packets would need to support sending MTP2 packets on the desired interface or that something be added either to libpcap or tcpreplay to allow sending them via some additional mechanism.
> Then again, I have right now in front of me file with WTAP_ENCAP 42, i.e. MTP2
> so, could you, please, explain how all of it happens? Does it mean that the development of wireshark/wiretap
> and tcpreplay happens in totally independent way?
Yes, it does.
There is some overlap between the Wireshark/wiretap developers and the libpcap developers (I'm a member of the intersection of {Wireshark core developers} and {libpcap core developers}), but they're not developed jointly. I don't know whether there's any overlap between the Wireshark/wiretap developers and the tcpreplay developers; there may well not be any.
Wiretap is a library that reads a number of capture file formats, including but not limited to pcap and pcap-ng, and supplies packets to its caller, and that writes a (smaller) number of capture file formats, again including but not limited to pcap and pcap-ng. The encapsulation values it uses are defined by it and are maintained solely by the Wireshark developers; encapsulation values are added as necessary to support various file types, their numerical values are subject to change from major release to major release and do not correspond to anything that is stored in a file (the actual encapsulation type values in files get mapped to WTAP_ENCAP_ values) and not all encapsulation types are supported by all file formats.
If the file you have in front of you is "with WTAP_ENCAP 42", then it's either:
1) a pcap file with a link-layer encapsulation type of 140 (LINKTYPE_MTP2/DLT_MTP2)
or
2) a pcap-ng file all the interfaces of which have a link-layer encapsulation type of 140 (LINKTYPE_MTP2/DLT_MTP2).
It's definitely not an rf5 file, as they all are given a WTAP_ENCAP_ value of WTAP_ENCAP_K12 by Wireshark.
> Why I am asking -- taking a look at how these encapsulation types are defined in wiretap, it should not be all that different to define DLT plugin which basically reads the same packet's headers as they are defined in wiretap,
You would first have to have a pcap/pcap-ng link-layer header type value for that layout, as a DLT plugin reads a pcap file. You could either ask for one, or, if this is just for your own purposes, use one of the DLT_USERn values.
Once you've done that, *and* have tweaked wiretap in your personal version of Wireshark to support writing rf5 files in pcap format using that DLT_/LINKTYPE_ value, a DLT plugin could probably be written to read that DLT_ value and transform it to DLT_MTP2.