Hi Aaron,
Thanks for your reply.
Since the headers are altered, and not created from scratch, one could
apply a diff to the checksum based on arithmetic on the changed fields,
rather than recalculating the entire checksum from scratch, thereby
avoiding the need to access all fragments. Sure enough, there is even an
RFC describing the process: http://tools.ietf.org/html/rfc1624.html
Perhaps this is also faster in the general, non-fragmented case.
Trust me, I understand that there is limited time in the universe and
perhaps this doesn't make the cut! :-) Also, my particular itch has been
scratched for now.
But I just wanted to illustrate that it does seem possible to maintain
accurate checksums for fragmented packets by looking at the first packet
only. E.g. Routers/NAT need to do it too. Only one must assume that the
checksum was correct to begin with. But that holds true for a captured
.pcap file anyway, doesn't it?
Peter
On Thu, Dec 13, 2012 at 2:38 AM, Aaron Turner <synfina...@gmail.com> wrote:
> As you read in the RFC's, UDP checksums are completely optional and 0
> is valid. TCP requires a valid checksum at all times and so there
> isn't a hack like that available. The semi-good news is that as of
> 3.5.0, tcprewrite won't re-calculate an UDP checksum when it is 0. As
> you figured out though, it was a small change to force all UDP
> checksums to be 0.
>
> Sadly, I doubt tcprewrite will ever support calculating checksums
> spanning fragmented frames (TCP, UDP, etc) because tcprewrite can only
> look at/process one packet at a time.
>
> On Wed, Dec 12, 2012 at 4:28 PM, Peter Valdemar Mørch <pe...@morch.com>
> wrote:
> > Hardcoding 0 for the UDP check sum does work, but isn't really a stable
> > solution! :-)
> >
> > Peter
> >
> >> diff -u tcpreplay_3.4.3.orig/tcpreplay-3.4.3/src/tcpedit/checksum.c
> >> tcpreplay-3.4.3/src/tcpedit/checksum.c
> > --- tcpreplay_3.4.3.orig/tcpreplay-3.4.3/src/tcpedit/checksum.c
> > 2009-06-25 20:45:51.000000000 +0200
> > +++ tcpreplay-3.4.3/src/tcpedit/checksum.c 2012-12-13
> 00:15:51.011434872
> > +0100
> > @@ -116,6 +116,7 @@
> > sum += ntohs(IPPROTO_UDP + len);
> > sum += do_checksum_math((u_int16_t *)udp, len);
> > udp->uh_sum = CHECKSUM_CARRY(sum);
> > + udp->uh_sum = 0;
> > break;
> >
> > case IPPROTO_ICMP:
> >
> >
> > (This is on another server running 3.4.3...)
> >
> >
> >
> > On Wed, Dec 12, 2012 at 11:59 PM, Peter Valdemar Mørch <pe...@morch.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> I have a capture file with two ethernet frames, each containing a
> fragment
> >> of a UDP packet. When I use tcprewrite to change the destination MAC
> and IP
> >> along the lines of:
> >>
> >> tcprewrite --enet-dmac 00:0c:29:c8:56:0c -D
> >> 172.27.189.10/32:172.22.216.102/32 -i input.pcap -o output.pcap -C
> >>
> >> The calculated UDP checksum seems wrong however. The recipient linux
> >> discards the entire UDP packet. (I'm guessing the UDP checksum gets
> >> calculated over the first frame only, not the entire UDP packet - I
> don't
> >> know)
> >>
> >> Now, in http://sourceforge.net/mailarchive/message.php?msg_id=22945996,
> >> Aaron Turner writes:
> >>>
> >>> Yeah, unfortunately, tcprewrite doesn't know how to do IP
> >>> defragmentation to calculate the UDP checksum which spans multiple
> >>> fragments.<snip>
> >>
> >>
> >> Although this is from 2009, it seems to be my problem. Is that right?
> >>
> >> When I set the UDP checksum to 0x0000 with a hex editor the recipient
> >> *does* get it. I didn't quite understand the legaleze, but it seems UDP
> >> checksumming is somewhat optional. See e.g. "4.1.3.4 UDP Checksums" in
> RFC
> >> 1122.
> >>
> >> We would really like to replay our large capture file with some large
> >> fragmented SNMP traps towards another IP address. :-(
> >>
> >> The linux TCP stack delivers UDP SNMP traps with 0x0000 UDP checksums to
> >> snmptrapd, which is all we need. A flag to force 0x0000 UDP checksums
> as a
> >> workaround would save the day for us.
> >>
> >> Is there anything else I can try?
> >>
> >> Alternatively, some mention of this limitation in the man page would be
> >> nice. Does this limitation also apply to TCP checksums (that aren't
> >> optional?)
> >>
> >> Sincerely,
> >>
> >> Peter
> >>
> >> > tcprewrite -V
> >> tcprewrite version: 3.4.4 (build 2450) (debug)
> >> Copyright 2000-2010 by Aaron Turner <aturner at synfin dot net>
> >> Cache file supported: 04
> >> Not compiled with libdnet.
> >> Compiled against libpcap: 1.3.0
> >> 64 bit packet counters: enabled
> >> Verbose printing via tcpdump: enabled
> >> Fragroute engine: disabled
>
> --
> Aaron Turner
> http://synfin.net/ Twitter: @synfinatic
> http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
> Windows
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety.
> -- Benjamin Franklin
> "carpe diem quam minimum credula postero"
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> 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
>
--
Peter Valdemar Mørch
http://www.morch.com
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
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
