Simulating adverse network conditions with Clumsy

One of the most challenging aspects of working on Online games is handling a wide range of user setups and testing scenarios. As opposed to single player, local games, you're now having to deal with a virtually infinite array of parameters and edge cases, such as slow internet, high ping, unstable networks randomly dropping packets, disconnections and reconnections, players from different countries playing together, firewalls, NAT, VPNs and so on.

Replicating most of those is often very difficult, if not outright impossible. Anyone that worked on a live game experienced receiving bug reports and not being able to reproduce the right setup to debug.

Luckily, there are a few tools that can help simulating some of those adverse conditions. One of them is Clumsy, an open source tool (MIT license) that allows you to simulate Lag, Throttle, tampering with packets, dropping them, sending them out of order and a few more common scenarios.

In their own words:

clumsy makes your network condition on Windows significantly worse, but in a managed and interactive manner.

It can be found on Github: https://github.com/jagt/clumsy
Or downloaded directly from: https://jagt.github.io/clumsy/download.html

Clumsy works on Windows only, and it needs Administrative privileges to run. For this reason, ensure you get prior permission from your company's IT before running it on your machine.

Let's go through some of the features Clumsy offers.

Filtering

The first step before simulating network conditions is to define a filter that will determine what traffic will be affected.

By default you will find a few presets built-in, you can find them in the dropdown next to the Start button. Alternatively, you can build your own filters.

Filters determine whether you want to capture inbound/outbound/loopback traffic, the protocol used, whether it should be IPv4 or IPv6, source/destination IP address and so on.

A few examples of filters:

udp and outbound and ip.DstAddr == x.x.x.x

This will apply on outbound UDP packets going to the address defined. Useful when playing with a dedicated game server.

udp and inbound and ip.SrcAddr >= x.x.x.x

This will instead capture incoming UDP packets. As you can see, we can use >, >=, < and <= to define an IP range from which packets should be intercepted.

Unfortunately there is no way to filter by process or application.

Make sure to check the manual for the full list of operators and modifiers.

Finally, if you'd like to save your filter as a preset, you can add it to the config.txt file right next to the exe.

Functions

Now that we defined a filter, let's see what functions we can toggle on.

The interface is fairly self-explanatory, so here's a quick overview of the options:

Lag: Will delay receipt/delivery of packets to emulate a slow network.
Drop: Will cause packets to be randomly dropped.
Throttle: Will randomly block traffic for the time frame you supply, then send them all at once in batch.
Duplicate: Will randomly cause some packets to be received or sent multiple times, as defined in the Count field.
Out of Order: Will randomly cause packets to be received or sent out of order.
Tamper: Will randomly shift bits of some packets. You can optionally let Clusmy redo the Checksum after tampering with the packet.

For each function, you can determine whether it should be applied to inbound or outbound traffic, or both. In addition, all functions except for Lag (which is applied to all packets) allow you to define a Chance value, which will determine how many packets will be affected by that function.

When you're done setting up your testing environment, go ahead and press Start. You will notice a few green dots next to the functions you enabled, to indicate that they are working as expected.

Keep in mind that, while Clumsy will try to recreate networking conditions that are close to your desired settings, the parameters you set are not meant to be extremely accurate. Clusmy will inherently introduce overhead to your network, regardless of the functions enabled, as packets will need to be captured and reinjected before they reach or leave your application.