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
>
> --
> Peter Valdemar Mørch
> http://www.morch.com
>
--
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
