Break connections on purpose
Slow is one kind of bad. Gone is another, and it is the one that finds the code path nobody wrote: the reconnect, the retry, the message that tells the user what happened.
This is also how you test an application offline without unplugging anything: LAN mode leaves the local network working and takes the internet away, and blocking one address makes a single service unreachable while the rest of the connection is fine.
Five different ways to be gone
| Setting | What the app sees |
|---|---|
| Reset connections | Connections die mid-transfer, the way a firewall or a load balancer kills them. Set how often, in percent. |
| Link on and off | The network disappears for a while, then comes back, over and over. You set the cycle length and how much of it is downtime. |
| Block a port | Everything to that port vanishes. Nothing else is touched. |
| Block an address | One server becomes unreachable while the rest of the internet works. |
| LAN mode | The local network keeps working, the internet does not. Exactly the shape of a captive portal or a dead uplink. |
From the command line
Kill roughly one connection in ten, on one app:
BeanNetworkTester.exe --rst-prob 10 --target myapp.exe --duration 60Ten second cycles, down for four of them - a link that keeps coming and going:
BeanNetworkTester.exe --flap-period 10 --flap-down 40 --target myapp.exeOne server unreachable, everything else fine:
BeanNetworkTester.exe --block-ip 203.0.113.10Blocking only hits what it names
Unlike loss or delay, blocking a port or an address affects only the traffic matching it. That makes it the safest of these to run without a process target, and it is why "make this one dependency disappear" is a one-line command.
The dead-download trap
There is also a maximum packet size. Lower it a little and large transfers slow down. Lower it to a value like 576 and downloads stop completely, forever, with no error - because that is no longer a smaller packet size, it is the classic black hole where the network drops what is too big and never says so.
That is a real failure mode worth reproducing on purpose, and it is a genuinely confusing one to meet by accident. If a download dies silently right after you changed this setting, that is why.
Getting back to normal
STOP restores everything. So does closing the program, and so does the time limit if you set one. If the tool itself were ever to die mid-session, a watchdog inside it stops the capture rather than leaving your network in a broken state.