Shoot, sorry not tcpconvert, traceconvert which is a part of libtrace tool.
https://wand.net.nz/trac/libtrace/wiki/TraceConvert
<https://wand.net.nz/trac/libtrace/wiki/TraceConvert>
I think we narrowed down the problem further to the program (CCHEF) we used to
select
some flows. Apparently there are some problems when we tried to rewrite the pcap
metadata resulting in the packets with incorrect capture length and actual
length.
So the issue is not with traceconvert either.
Thanks a lot Aaron, now that we know how tcprewrite works we can pinpoint the
issue better.
________________________________
From: Aaron Turner <synfina...@gmail.com>
Sent: Monday, 31 July 2017 10:05:39 PM
To: Main forum for tcpreplay
Subject: Re: [Tcpreplay-users] Bug with tcprewrite --fixlen ??
I don't know tcpconvert and neither does google from the looks of it. Sounds
like a bug in that software if it doesn't generate a valid pcap file. As they
say, garbage in, garbage out which sadly is far too common with public network
trace files.
--
Aaron Turner
https://synfin.net/ Twitter: @synfinatic
My father once told me that respect for the truth comes close to being the
basis for all morality. "Something cannot emerge from nothing," he said. This
is profound thinking if you understand how unstable "the truth" can be. --
Frank Herbert, Dune
On Sun, Jul 30, 2017 at 8:33 PM, Hendra Gunadi
<hendra.gun...@murdoch.edu.au<mailto:hendra.gun...@murdoch.edu.au>> wrote:
Hi Aaron,
thanks for the reply. Now that clearly explain what the problem was.
I'm not sure myself whether the original frame length in the pcap
header is properly captured because I take the trace from a public
dataset, in particular this is the one I'm talking about. I can't upload
it here because it is a big trace file.
ftp://wits.cs.waikato.ac.nz/ispdsl/2/20100107-153000-0.dsl.erf.gz
I converted the erf capture into pcap using tcpconvert before
applying tcprewrite. I suspect that this conversion is what causing the
problem.
Thanks,
Hendra
________________________________
From: Aaron Turner <synfina...@gmail.com<mailto:synfina...@gmail.com>>
Sent: Saturday, 29 July 2017 11:25:31 PM
To: Main forum for tcpreplay
Subject: Re: [Tcpreplay-users] Bug with tcprewrite --fixlen ??
This is actually "as designed" and somewhat of a relic because
tcpreplay's roots are in operating at Layer2 and not 3 and because not
every frame captured has an IP header. This also avoids the problem
when your IP packet is too small for the minimum MTU length for
ethernet and requires padding at the L2 layer.
I assume you've got some pcap's from a device which has a bug and
doesn't properly fill out the original frame length in the pcap packet
header? Or is there another issue? Do you have some packets you can
share?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcpreplay-users mailing list
Tcpreplay-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
Support Information: http://tcpreplay.synfin.net/trac/wiki/Support