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>
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?
--
Aaron Turner
https://synfin.net/ Twitter: @synfinatic
Syn Fin dot Net | Streaming Thoughts from Syn to Fin<https://synfin.net/>
synfin.net
So my initial testing of an ESP-12E showed that it couldn’t reliably keep up
with two 10K PPR encoders (40K count). I discussed this project a great deal
with my ...
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 Sat, Jul 29, 2017 at 2:56 AM, Hendra Gunadi
<hendra.gun...@murdoch.edu.au> wrote:
> Hi there,
>
>
> I have a (big) trace file which content packets are snapped from WAND. I
> want to analyze the trace through Bro which unfortunately drops malformed
> packets, e.g. if the IP total length is not equal to the actual packet size.
> I stumbled upon this tool and the definition in --fixlen fits my requirement
> perfectly, where I can pad zero bits to match the IP total length. The only
> problem was, as of tcprewrite 4.2.6, this does not seem to pad the packets
> in the trace correctly, it only pads to the actual bits field, i.e. it just
> match the value of bytes on wire and the value of captured bytes as opposed
> to the IP total length. The command I used is
>
>
> tcprewrite --fixlen=pad --infile=<file> --outfile=<file>
>
>
> Please advise
>
>
> Thanks,
>
> Hendra
>
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
