I had totally forgotten about that trick. I've opened a ticket with a feature enhancement for that.
http://tcpreplay.synfin.net/ticket/535 On Thu, Dec 13, 2012 at 12:41 AM, Peter Valdemar Mørch <pe...@morch.com> wrote: > 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 -- 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
