0

I have a packet trace that I forge with scapy and resend with tcpreplay. I recompute IP and transport-layer checksums with Scapy, save the packets to disk on pcap file and call tcpreplay on it.

By running tcpdump in parallel I noticed that all IP checksums of those outgoing packets have no value at all. It seems that tcpreplay is removing it each time.

Now, does this happen on purpose? Am I missing something?

Checksums should be correct, so I don't think tcpreplay removes them because a check on it failed.

Ricky Robinson
  • 21,798
  • 42
  • 129
  • 185
  • does those packets are received by the receipt with the correct checksums? – Davide Berra Feb 14 '13 at 12:03
  • I didn't get your question. The packets were correctly received at the receiver, so I'm not /too/ worried. It's just that tcpreplay, when applied to a packet trace where each packet has a correct Ip checksums, seems to be removing such checksums. – Ricky Robinson Feb 14 '13 at 13:16
  • if you use sendfast in scapy it uses tcpreplay out of the box. Usually if you have checksum issues the best thing to do is just delete them. Scapy should fix it automagically when sending. – dc5553 Feb 21 '13 at 21:15
  • Scapy, when it comes to sending and receiving, is a source of all sorts of problems. I'm so happy now that I'm using my own implementation of `sr`. No more delays of the order of tens of seconds, no more *negative* round trip times, matching of packets is now correct even for duplicate packets, etc. – Ricky Robinson Feb 22 '13 at 16:42

3 Answers3

1

I'm not really sure about what's going on but i suspect that tcpreplay detect that the interface is going to use to send out the packet has the Offload Checksum active and let the NIC to calculate the right checksum.

Try to disactivate the offload checksum with 

ethtool -K eth0 rx off tx off

then retry and let us know

Davide Berra
  • 6,387
  • 2
  • 29
  • 50
  • Thank you for the answer. I wouldn't want to mess up anything in my system. Since I'm not familiar with `offloading`, how would the above command affect the usability of my machine? Also, I can't seem to find the difference between `rx-checksumming` and `tx-checksumming`. Any idea? In any case, here's what my options are when I run `ethtool`: `rx-checksumming: off [fixed] tx-checksumming: on tx-checksum-ipv4: off [fixed] tx-checksum-ip-generic: on [fixed] tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] ` – Ricky Robinson Feb 14 '13 at 14:04
  • 1
    It seems like you have the Checksum Offloading activated for the outgoing packets. It means that IP checksum will be calculated by the NIC hardware instead of by the software. Since tcpdump capture the packets BEFORE they're sent out by the NIC, then the checksum is not already been calculated. If you have the chance to dump the data from the receipt point of view, you can discover what's going on. – Davide Berra Feb 14 '13 at 14:13
  • All packets given to `tcpreplay` already have a correct checksum, so it seems that it is indeed `tcpreplay` that removes it and lets the NIC handle it. I can't dump packets at the receiver, but since my packets have a low ttl value, I inspected the payload of the ICMP packets I get back and they all contain a correct checksum value. So yeah, something was indeed working behind the scenes, otherwise I wouldn't have gotten anything back.One more thing I couldn't understand from `ethtool`: is there any difference between `rx-checksumming` and `tx-checksumming`? What do `rx` and `tx` stand for? – Ricky Robinson Feb 14 '13 at 14:42
  • In any case here's what I got when I ran the command above: `$ sudo ethtool -K eth0 rx off tx off Cannot change rx-checksumming Cannot change tx-checksumming Could not change any device features ` I guess my NIC doesn't allow many changes. – Ricky Robinson Feb 14 '13 at 14:47
  • 1
    in rx case, the NIC **verify** the checksum, in tx case the NIC **calculate** the checksum. Look at this infos by Intel: [Intel NIC infos](http://www.intel.com/support/network/adapter/pro100/sb/CS-029402.htm#ico) – Davide Berra Feb 14 '13 at 14:53
1

You didn't specify the actual tcpreplay command you are using, but tcpreplay never edits packets. You can use tcpreplay-edit or tcprewrite to edit packets, but not tcpreplay. And even then tcpreplay-edit/tcprewrite will calculate/fix your checksums; not zero them out.

Have you opened up the original pcap generated by scapy in Wireshark and verified there are actually checksums there? Honestly, this sounds like a simple case of garbage in, garbage out.

FWIW, I'm not aware of anything that would zero out your checksums... at least I can't imagine why the kernel would do that for packets sent via the PF_PACKET interface- that would be a bug IMHO.

If you figure it out, let me know.

Aaron Turner
  • 319
  • 1
  • 3
  • Thank you for your answer. As for the tcpreplay command I use, I simply do `tcpreplay --pps=$myPacketRate --intf1=0 $dumpedTrafficLocation`. In the exchange of messages I had with Davide Berra in the other answer I got, we worked out that, due to `offloading`, something for sure happens between the moment I launch `tcpreplay` and the instant in which `tcpdump` captures my outgoing traffic. So, if it's not `tcpreplay` that removes the checksums, could it be the kernel itself? Or the network card? – Ricky Robinson Feb 25 '13 at 13:35
  • OK, I'll inspect the pcap file with wireshark and will get back to you. – Ricky Robinson Feb 25 '13 at 13:36
  • 2
    I think the traffic dumped in $dumpedTrafficLocation was captured before the NIC updated the checksum. – Davide Berra Feb 25 '13 at 13:37
  • Yes, if you captured the traffic on a system which has checksum offloading enabled, then the outgoing packets sent by the operating system won't have the checksums- they'll just be zero. Hence tcpdump/wireshark capturing the traffic will capture traffic w/o a checksum. – Aaron Turner Feb 27 '13 at 22:59
1

You can solve this issue using the tcpreplay-edit which is included in the same package that tcpreplay, in particular this option:

-C, --fixcsum              Force recalculation of IPv4/TCP/UDP header checksums

Desactivating the offload checksum of the interface is a non sense: when the packet goes out it would be rejected by the next machine having checksum checking enabled (+99%)

NeDark
  • 1,212
  • 7
  • 23
  • 36