Aim at one app, not the machine
Without a target, every connection on the computer is affected - including the remote desktop you are using and the download of the fix. With a target, one process gets the bad network and everything else carries on.
By process
Type a name into Process, or pass --target. A bare name
matches as a fragment, so chrome covers chrome.exe:
BeanNetworkTester.exe --loss 10 --target chrome.exeIt follows the process tree, which matters for anything that spawns children: a browser opens a process per tab, and those are hit too.
The field takes more than one name, and more than one kind of thing at once:
| What you type | What it means |
|---|---|
chrome.exe,firefox.exe | Two applications. |
chrome,!chromedriver | Chrome, but never the driver. Exclusions win. |
my*.exe | Everything starting with "my". |
re:^node\.exe$ | A regular expression, when a wildcard is not enough. |
4812 | A single process id. |
>1000 | Every process id above 1000. |
By address or port
Sometimes the app is not the unit of interest - one server is. These take the same list, range and exclusion syntax, and understand CIDR and IPv6:
BeanNetworkTester.exe --latency 300 --dst-ip 10.0.0.0/24 --dst-port 443BeanNetworkTester.exe --loss 20 --dst-port "!53"The second one is worth knowing: everything except DNS. Aiming away from a port is often easier than listing the ones you want.
Targeting a process by name survives its restart
Restart the application while a session is running and a target by name picks the new process up again. A target by process id cannot - the id belonged to the process that exited. If your test restarts the thing under test, target it by name.
The warning you should not ignore
Start with impairment on, nothing to aim at and no time limit, and both the window and the
command line say so: this affects every connection on this machine. It is a warning, not a
refusal - sometimes that is what you want. If it is not, set a target or a
--duration, and STOP always puts everything back.