#30 Enhancement request: Ability to send random data + checksums, enabling iperf to be used for testing "on the wire" corruption

[Stilez]

This request is a result of this discussion on Stack Exchange.

As previous background, this thread on the FreeNAS forum may help ("Files copied to server being corrupted?!"). It's not long and is a good example.

The feature request is that iperf is enhanced to allow a "test transmission integrity" mode, in which the aim is to test not only the bandwidth between client and server instances, but also to verify whether (and to what extent) data is faithfully transmitted or corrupted "in flight", as it does so. It would involve two parts:

• At present, the data sent by the client is arbitrary; it could pretty much be all zeros and would do its job. In this enhancement, the client acts as it currently does, with the exception that it sends meaningful data instead of arbitrary data. The data is made up of "chunks" of a specified number of bytes, with each "chunk" made up of random data + a checksum.

• The server acts as it currently does, with the exception that in this mode, it re-checksums the chunks before discarding the incoming data, and keeps a count of how often the checksum received from the client matches/doesn't match the checksum calculated by the server.

CLI options

The existing CLI options cover most of what's needed already - TCP/UDP, multiple client traffic, rates and amounts, and so on. Probably someone who knows iperf better would have their own ideas what would be needed. My tenattive thoughts would be:

• A CLI option that signals to the client, to send checksummed data, and to the server, to expect and verify checksummed data (but the server might autodetect this so it might be unnecessary on the server side, see below)

• A CLI option to preload some amount of random data in memory before starting (the default being to get it from /dev/random as needed). The data needs to be random, because if there's corruption it might easily be affected by the data content itself, for example a dodgy logic gate somewhere on an NIC card or in the offload logic on an ASIC; static data won't exercise this aspect or trap it very well compared to random. Usually /dev/random is going to be fine, but in some cases the data rate to stress-test the networking might be such that /dev/random is too slow, or might unpredictably affect network speed+jitter measurement, in which case it might be worth preloading say 256K ~ 10MB of random data into RAM first (depending on situation and client-side memory), and simply cycling that as a static random buffer of data. The bit pattern could be randomised by some simple logic such as XORing or shifting the data each time the buffer cycles, so it's effectively "random enough to test the network as well as real random data would", without needing to pull data from /dev/random during actual testing.

• An integer option on the server side that, if present, directs the server to continue after a checksum error is detected (a value >0 meaning "exit after N errors" and a value=0 meaning "don't exit on checksum errors at all"). The default action would be "exit on first checksum error".

Chunk structure

"Chunks" should start with some kind of (magic byte pattern) + (chunk size in bytes). This simplifies it a lot:

• The server can be sure it's correctly matching start of each chunk, and intelligently check integrity
• If there is corruption, the server can resync to the stream and continue with testing, and determine how frequent the corruption is, by watching for the next "magic pattern" and treating it as a beginning of a new chunk. This also means that the server doesn't need to be told the chunk size, because it's carried in the data stream. (Technically the server wouldn't need to be told it was a checksum-testing datastream either, because the magic pattern in the incoming data would convey that information anyway)
• Obviously the client would have to ensure that the random data (whether from /dev/random or a preloaded buffer) didn't itself contain the magic pattern.

Checksum

I don't think an option is needed for the choice of checksum, nor that anything more than MD5/CRC32 would be needed. Initially I thought the checksum would have to be strong and futureproof, perhaps as a user option, in order to guarantee no collisions, I now think it can be very weak and should emphasise being very inexpensive/quick to calculate - even MD5 or CRC32 might easily suffice. My rationale is: As it's only being used for testing and not security, it doesn't need to be long-term non-vulnerable. Also while iperf across a fibre might involve 10^(very large number) of chunks of data, if a checksum were to be corrupted in a way that it still matched the corrupted data, the odds are virtually certain that there would be many other packets which would be corrupted in ways that didn't match, as well (even with a weak hash like MD5/CRC32), and the user would detect the in-flight issue via other data that was corrupted instead. So perhaps a hash that's optimised for very quick calculation would be "good enough"? Might need to check with an infosec specialist, but that's my thoughts on the checksum.

Thanks again for the kind suggestion to elaborate here!

• Stilez

[Robert McMahon]

yes, I'll try to get to this soon. There is a pdf pull to get the byte count. I'll probably add some md5 hashing to that.

[Robert McMahon]

Not enough demand for this.