0.4.0

⭐ If it saved you time, leave a star. That is how the next tester who needs it finds out it exists.

The short version. This release is about numbers you can trust and targeting that catches what
you aimed at. If you read nothing else:

• Aiming at a process now catches a connection from its first packet, TCP and UDP alike.
  "Drop SYN" combined with a process target previously did nothing at all, and DNS and QUIC walked
  past untouched.
• "Effective loss" was wrong and is now right. It counts every impairment, over the traffic you
  aimed at. A session losing 90% of its traffic to a speed limit used to report 0.0%.
• Presets and the shipped scenarios were recalculated against published measurements. Latency
  was applied twice, and three presets were eight times too fast.
• A session moves about 1.3x more packets a second, and a delay you ask for arrives without the
  old few-millisecond surcharge.
• New: "Capture only the targeted traffic". On a real run without it, the driver threw away 43%
  of the traffic you had aimed at before this tool ever saw it.
• New: "Show only the targeted traffic", five new presets, a "Driver queue wait" reading, and a
  warning when your target shares a port with another program.
• Config and scenario files now reject a typo instead of ignoring it.
• Plus a long list of fixes to the counters, the Connections table and session start/stop.

If you script this tool, read the BREAKING section: presets, "Effective loss", profiles, the
statistics CSV, the connections CSV and the reproduction report all changed shape or meaning.

BREAKING

• A misspelled setting in a config file is now an error. "latancy": 300 used to load in
  silence, so --dry-run said "Configuration is valid" and the run went out with no latency at
  all. Unknown settings now fail with code 3, naming the key and suggesting the near miss. Files
  this tool saved keep loading. A hand-written file with an unknown name will not.

• A mistake in a scenario file now says so instead of doing nothing. "duraton" used to leave a
  reset at its default and "lop" used to turn looping off, both silently, so the tool looked like
  it was ignoring your file. Unknown keys, in a step or at the top level, are now an error naming
  the key. A correct file keeps working.

• A scenario that ends now ends the run. A non-looping scenario with a timeline used to print
  "Scenario finished." and then run forever, which in a pipeline is a job that hangs to its own
  timeout and writes no summary. Such a run now stops with stop_reason: "scenario_done" and says
  so at the start. --duration still wins wherever you pass it.

• The old reset_now scenario action is gone. reset_tcp does the same thing and is now the
  only action. A file still using reset_now will not load and says which step to fix. The
  "Reset TCP now" button is unaffected.

• The presets were wrong and are now checked against published measurements. Latency was set as
  if it were a ping, but it is added in both directions, so "Satellite link" at 600 ms delivered a
  1200 ms ping. Three presets held kilobits where the field wants kilobytes, making them
  eight times too fast. If you scripted --preset, your traffic changes. Ids are unchanged, but
  --preset "Satellite link" is now "Satellite (geostationary)".

• The shipped scenarios in scenarios/ were recalculated the same way, so a scenario and a
  preset describe the same network with the same numbers. The ping you get is now the number written
  in the file.

• "Effective loss" now means what its name says, and your numbers will change. It used to be the
  configured Loss percentage over every packet seen, ignoring speed limits, blocking, LAN cut, link
  outages, resets, dropped SYNs and expired NAT. It now counts every impairment, over the traffic you
  aimed at. effective_loss_pct and effective_corruption_pct moved with it, so reports from before
  and after are not comparable.

• "Duplicated" counts packets actually sent twice, not packets the tool decided to duplicate.
  Under load the copy was thrown away while the counter rose anyway: 40 packets in, "Duplicated"
  read 40, nothing reached the wire. This matches "Corrupted", which always counted only real
  changes. Reports from before and after are not comparable on that field.

• Profiles now remember more of the link: latency spikes, link outages (flapping) and the buffer,
  on top of the original seven fields. Outages are why it was worth doing - a profile can finally
  describe a link that cuts out. Old profiles load exactly as before. Picking a preset now clears
  all of these, so "Perfect network" really does clear everything, and --preset finally does what
  the window does.

• The Connections table now shows what arrived AND what was offered. "down", "up" and "total"
  held captured bytes under headings meaning delivered, so a row could read 5 MB while the
  application got 0.4 MB. Those three are now delivered, and new "down seen" / "up seen"
  hold what was captured. The connections CSV changed shape: the three old byte columns are
  replaced by six delivered_* and captured_* ones, renamed rather than reused.

• The reproduction report's "connections reset" counted packets, not connections. One reset
  connection could report itself as 50. The report now carries three keys that answer three
  questions: connections_reset, rst_packets_dropped and rst_sent. The statistics CSV gained a
  matching connections_reset column. Nothing on screen changed.

• The statistics CSV gained capture_narrowed and packets_in_scope columns. The first records
  whether "Capture only the targeted traffic" was in effect, without which two rows under one header
  can count completely different traffic. Your existing file is moved aside with a timestamp and a
  fresh one started, as it already is whenever columns change, so no row misaligns. A script reading
  by column position needs the new offsets.

• --gui no longer accepts any other option. --gui --loss 30 --duration 600 used to open no
  window and quietly impair in the background, with no STOP button anywhere. It now stops with a
  usage error (code 2) and says what to do instead. If a script relied on this, delete --gui
  from it.

Added

• Five new presets: Satellite (low orbit), Distant server (another continent), Congested home
  link (bufferbloat), Train / metro (tunnels) and In-flight Wi-Fi. Two are worth a note: bufferbloat
  only bites once you really saturate the link, and Train / metro is the only preset that takes the
  connection fully down, so your application has to reconnect rather than just slow down.

• "Show only the targeted traffic" (Settings, off by default) points the counters, the chart, the
  Connections table and the connections CSV at your target alone. It changes what you see, never
  what is captured or impaired. Three things deliberately do not follow it: "Queue overflow",
  "Dropped at stop" and "Send failed" always cover everything, because they count the tool's own
  losses. The statistics CSV carries both totals instead. Reports and --format json are unchanged.

• "Capture only the targeted traffic" (--narrow-filter) pushes your destination IP and port
  into WinDivert, so traffic that could never be impaired is not handed over at all. It is a
  correctness fix, not just a speed one: measured on a real run, without it the driver threw away
  43% of the traffic you aimed at before the tool saw it. It applies at START, and does nothing
  for a process target, a wildcard or an re: pattern - the run says which.

• "Driver queue wait (peak)" in the Session tab shows how long packets waited inside WinDivert
  before the tool saw them. That is the one delay the tool adds and counted nowhere. It is measured,
  not estimated. Expect a fraction of a millisecond when idle; above 50 ms the log says so. Blank
  under --simulate.

• A session now records the WinDivert queue it ran behind (length, time and size) in the log and
  in the reproduction report, so a report from a machine you do not have in front of you says which
  queue produced its numbers.

• The tool now warns when your target shares a port with another program. Windows lets several
  programs hold one local port - that is how mDNS, SSDP and DHCP work - and this tool decides what to
  break from the port number. On this machine four ports out of 127 were shared, one of them by five
  programs. Applying a target now names the port and who holds it, so you know that part of the
  result is a coin toss.

• The command line says when your target stops matching, instead of finishing green in silence.
  Measured: aiming by process id and restarting the program left five out of five new connections
  untouched with nothing in the output. Aiming by name recovers on its own and costs only the
  first connection. Aiming by process id never recovers. If the program under test restarts, aim
  by name.

• Every run with a process target ends by saying how much of the captured traffic was yours -
  "In scope: 40 of 500 captured packets" - and calls it out when that is zero. A run where your
  target caught nothing looks exactly like a run where your application coped. It is a warning, not
  a failure, because a quiet target is perfectly ordinary.

Changed

• The checkbox is now called "Capture only the targeted traffic", not "Narrow the driver filter
  to the target". The old name described the machinery. The --narrow-filter flag is unchanged, and
  its tooltip was rewritten to say what it does and when it will not apply.

• A session moves about a third more packets a second. The tool handles packets on two threads,
  and Python left one waiting up to 5 ms for its turn - that waiting, not the work, was the limit. A
  session now asks for shorter turns and hands the setting back at STOP. Measured on loopback and a
  real card: 1.33x to 1.36x, in 24 comparisons out of 24, at slightly less processor time per
  packet.

• A packet you did not ask to change goes back on the wire exactly as it arrived, and the session
  moves about 12% more traffic for it. Checksums used to be recomputed for every packet, including
  untouched ones, which also meant a session with nothing configured did not quite pass traffic
  through unchanged. Measured: 1.12x more packets a second, 8 comparisons out of 8, and 24 MiB of
  TCP arrived byte for byte over a real card.

• Targeting a process no longer competes with the traffic it is measuring. Working out which
  sockets belong to your target used to happen on the thread handling your packets, dozens of times a
  second. It now runs on its own thread. A freshly opened connection is still impaired within tens of
  milliseconds and STOP stays immediate.

• Semicolons are gone from the interface texts and both READMEs. Twenty-one tooltips and about
  eighty lines of documentation used them to join sentences, which is not how people write. Code
  samples keep theirs, where a semicolon is syntax.

• "Spike chance" and "Spike size" moved to "Latency (ping)" from "Advanced (NAT / connections)",
  because a spike is latency. Nothing about how they work changed, nor their flags, nor their place
  in a profile.

• "Blocking (firewall)" starts collapsed on a fresh install, like the other advanced panels. If
  you have used the tool before, your own choices are remembered.

• The Latency and Jitter tooltips say the thing that was easy to get wrong: ping rises by about
  twice the latency you set, because both the request and the reply are delayed, while jitter widens
  the wobble by about 1.4x rather than doubling it. Both READMEs explain it too.

Fixed

• Aiming at a process missed the first packet of every new connection. Measured: 20 fresh
  connections with "Drop SYN" at 100% produced 20 successful connections and not one dropped SYN, so
  "Drop SYN" plus a process target did nothing at all. The first packet is now checked against
  the live socket map.
  What changes for you: connections aimed at a process now take longer to open and a minority
  fail outright, which is what a bad network does. If a test measured "time to first byte" under
  impairment, expect it to move.

• Aiming at a process did not touch the first packet of a UDP exchange - and DNS and QUIC take a
  fresh port every time, so it did not touch them at all. If you tested a game, a video call or a
  browser over QUIC and the impairment seemed weaker than configured, this is why. Ordinary TCP data
  is deliberately still not re-checked: measuring showed it would cost throughput for nothing.

• The live "which app owns this port" map could be dragged backwards by a stale reading, so a
  connection was briefly credited to the wrong application. A periodic sweep of the socket table,
  always a little behind, was applied on top of the live signal from the driver. Measured over 25
  seconds of ordinary traffic: 919 times. Readings are now weighed by when they were taken.

• Targeting could follow a process id after the process was gone, and Windows hands those numbers
  out again. A restarted target could come back under a remembered number and not be impaired,
  while an unrelated program inheriting that number was. The tool now checks the process is still
  the same one, and forgets it when it closes its last connection.

• Three fixes to short-lived and freshly opened connections. Targeting now follows the system's
  socket events instead of scanning a few times a second, so a connection that opens and closes
  between two scans is no longer missed. The Connections table fills in the owning program from the
  first packet instead of leaving the row blank. And setting a process target no longer makes the
  first START pause for a second or two.

• The "impaired?" column now reflects the whole session, not just this instant. It asked whether
  the port was in the target right now, so a row flipped to "no" the moment its connection closed
  and a run impairing all of Chrome looked like it caught almost nothing. The column, the row
  highlight, the sort and the CSV now read one record, so they cannot disagree.

• The tool kept pausing itself and then blaming WinDivert. Every so often it spent up to half a
  second working out which program owns which connection, stopped collecting packets while it did,
  and then told you the driver's queue was backing up and to narrow your filter. The delay was its
  own. Measured over 95 seconds with programs constantly starting: the worst pile-up dropped from
  508 ms to 17 ms and the warning stopped appearing.

• The "driver held a packet" warning described lost accuracy when what you were losing was
  traffic. Measured on a deliberately overloaded run: at 138,000 packets a second offered, the tool
  moved about 14,000 and 91.75% was thrown away by the driver before the tool saw it, while every
  drop counter on screen read zero. The warning now says a full driver queue means dropped packets,
  not just late ones.

• With "Capture only the targeted traffic" on, the Statistics and Connections tabs said the exact
  opposite of the truth, keeping their "counters cover ALL captured traffic" line while the driver
  had been told to hand over nothing else. The checkbox tooltip promised the opposite and both
  READMEs contradicted themselves. Both notes, the chart caption and the READMEs now describe what
  the figures actually cover, including the case where a process target is set as well.

• Four fixes to the Scope settings. The two "only the targeted traffic" switches now sit in one
  Scope card instead of separate panels a few rows apart, with a line that tells you before
  START whether your destination can actually be narrowed. The Settings window scrolls, so no group
  falls off the bottom. Starting a session logs which of the two outcomes you got. And the Session
  panel gained a "Capture" row, so a saved run says which traffic it counted.

• Three counters were lying about how much was lost. "Buffer overflow" and "Dropped at stop"
  charged for duplicate copies as well as packets, so a run duplicating everything reported nearly
  twice as many dropped as captured. A connection's "dropped" count ignored packets its own queue
  threw away. And packets the tool failed to re-inject left the arithmetic entirely - those now have
  a "Send failed" counter, a banner and an event-log entry, throttled so they cannot flood the
  log.

• Three tooltips were telling you things that were not true. "Dropped" claimed to count link
  outages, which have had their own counter for a while. "Downloaded (MB)" promised a figure that
  never appeared. And "Effective loss" read as "never reached the far end" when it measures damage
  done on this machine - loss out in the network never arrives here, so nothing here can count it.
  No numbers changed.

• The delay you set is the delay you get. Windows rounds up the wait used to hold a packet back,
  and it was a fixed surcharge rather than a percentage, so it barely showed at 100 ms and swamped
  small settings. Measured with a plain ping: asking for 10 ms used to cost 12.6 ms extra and now
  costs 1 ms, the same 1 ms as at 50 ms. Jitter below about 15 ms used to vanish into the noise.

• Long cut-offs and NAT blackouts now last as long as you set them. The tool forgets a connection
  it has not seen for a while, and a forgotten connection looks brand new - so a reset cooldown above
  about half a minute resumed after roughly 30 seconds however long you asked for, and "NAT mapping
  expiry" at 30 seconds never blocked a single packet.

• "NAT mapping expiry" now really cuts the incoming direction. The packet rejected for "the
  mapping has expired" was itself counted as activity, so the mapping reopened on the spot: an app
  that never sent a keep-alive lost about one packet every five seconds and otherwise worked, passing
  a test it should have failed. Incoming traffic now stays cut until the application sends something.

• "Reset connections" now works where it claimed to. It no longer fires on a connection that is
  still opening, where the forged reset carries no acknowledgement number and Windows is entitled to
  ignore it - measured, the connection hung until its own timeout. And it now really resets local
  (loopback) connections, which previously just went quiet for the cooldown while the tool reported
  an RST as sent. Connections to other machines were never affected.

• Ping traffic never appeared in the Connections tab, which claims to list all of them - anything
  without ports was silently left out. Thirty seconds of pinging left the tab empty while the
  counters ticked up beside it. Portless traffic is now listed as one row per address with the port
  cells empty.

• The Connections tab could empty itself instead of dropping its oldest rows. When many rows
  carried the same timestamp they all fell on the same side of the "old" estimate, so far more went
  than intended - in the extreme, everything. It now refuses to drop below the level it is trimming
  to.

• When the capture could not start, the tool told you the wrong reason. A handle that failed to
  open produced WinDivert handle is not open - a symptom naming nothing - while the real cause went
  to a diagnostic file nobody reads. The helpful messages both interfaces already had, including the
  window's "run as Administrator" hint, could therefore never appear. Starting now fails immediately,
  with the reason.

• Four ways a session mishandled its own start and stop. A failed start could leave the tool
  holding your traffic without impairing it, refusing every later START. Ending a session kept hold
  of your traffic for a moment while tidying up, so a connection could stall. STOP could take two
  seconds in two different races. And the log could print a fault above its own "Start" line.

• An unforeseen error during a run is now an exit code, not a stack trace. A failure inside the
  reporting loop escaped as a raw traceback with code 1, which is also "the session could not
  start", so a pipeline could not tell an internal bug from a driver that would not open. It is now
  runtime (1) with a line saying what happened, and the run still writes its complete
  summary - a --format json file no longer ends mid-stream.

• Three fixes to --dry-run and --doctor claiming more than they checked. --dry-run said
  "Configuration is valid" about a command that then exits 7, so it now says which half it checked
  and points at --doctor. It also reads your --scenario file now, which it never opened.
  --doctor no longer calls a driver "not loaded" when Windows simply refused to let it look.

• Three fixes to the shared-port warning. It listed your own target among the strangers, because
  a program like Chrome runs several processes. It offered two possible outcomes when the socket
  table already decides which one applies. And it printed bare numbers, so 5353 read like a fault
  rather than mDNS. It now says 5353 (mDNS), names the program, and states the one outcome that is
  true.

• Three files could stop the program from starting, and no longer do. A translation file with a
  malformed header, a window-layout file with an entry in the wrong shape, and a --config file that
  was valid JSON but not a set of settings - the last one reported the tool as having crashed. Each
  is now skipped or reported clearly, and the rest of your setup is kept.

• Four smaller interface fixes. The throughput chart could be squeezed until it vanished on a
  narrow window (the Live tab now scrolls). "Close" was cut in half at the bottom of the Settings
  window. The profile picker cut long names off at 24 characters. And "Save profile..." opens with
  the cursor already in the name box.

• Two things left litter behind. A failed "Export connections CSV" left a stray .tmp file next
  to the real one, and stopping a session could file a crash report in crashes/ for an ordinary
  STOP. Neither happens now.

• Starting a second scenario without stopping the first is no longer possible. The engine
  replaced the running one and left the old one going in the background, so two scenarios fought over
  the same settings. Nothing in the program does this today, so it is a guard rather than a bug you
  could have hit.

Docs

• Both READMEs now document the scenario file format, the seven shipped scenarios, both CSV exports
  and all 17 Connections columns - none of which were written down anywhere. The column meanings
  existed only as tooltips, and the CSV headers only in the code.

• Three corrections to what the READMEs claimed. A connection is in scope "the moment it opens"
  only for a program the tool already recognises, not for that program's first connection. An
  exclusion like !chrome also covers every connection whose owner could not be identified, so do
  not use one to protect an application - name the one you do want broken. And both files explained
  greyed-out fields with an "Enable" checkbox that no longer exists.

• The Requirements and Tests sections now match reality. psutil is not what makes process
  targeting work on Windows - the socket table and process names come from the OS, and targeting
  keeps working without it. Source installs work on Python 3.10 and newer while CI tests and builds
  on 3.14 only, which is the version frozen into the released .exe. The Tests section also now
  covers the GUI render check and how a release is produced.