# Exit statuses

`udpstp client` exits with the ErrorStatus that OB-UDPST reports, except that a Test that completed with only warnings exits 0. In JSON results the same number is `ErrorStatus`, warnings included. Generated from the documentation of `crates/udpstp/src/exit.rs`.

| ErrorStatus | Meaning |
|---|---|
| 0 | The Test completed, with the STOP exchange or when its Test Interval ran out |
| 49 | Ours, JSON only, the last warning code, where OB-UDPST won't add one: the Test completed without a valid Maximum IP-Layer Capacity (no Sub-Interval met the Performance Criterion); it exits 0 |
| 2-6 | The Test completed with a warning (JSON only; it exits 0), in order: 4 nothing received for 1 s at some point (WARN_LOC_STOPPED), 5 the peer said it had stopped receiving (WARN_REM_STOPPED), 3 the peer missed Status PDUs (WARN_REM_STATUS), 2 Status PDUs never arrived (WARN_LOC_STATUS), 6 invalid PDUs (WARN_RX_INVPDU); the first of these that applies |
| 50 | The configuration or command line is invalid |
| 51 | The key file can't be read or is invalid |
| 75 | The Client or Server couldn't start |
| 100 + code | The Server refused the Setup Request with that cmdResponse; 100 alone for a code RFC 9946 doesn't define, 107 or 108 for a Setup Response that failed verification or the time window |
| 150 + code | The same for the Activation exchange: 152 for BADPARAM, 150 for an undefined code, 157 or 158 for a response that failed verification |
| 200 | The Test didn't complete: no answer from the Server in time, or the Watchdog ended it (ERROR_CONN_MIN, as OB-UDPST ends up reporting both) |
| 201 | Ours: the Server coerced a parameter the Client was told to refuse |
| 202 | Ours: the Server set a parameter the Client can't run with |
| 203 | Ours: the Servers gave a Multi-Connection Test's Test Connections different parameters |
| 204 | Ours: the Client user interrupted the running Test (Ctrl-C, or a signal to stop), or a write to its standard output failed, while the Test ran or with its final results. On Unix a Client stopped by a signal then dies of it, so a shell sees 128 plus the signal (130 for SIGINT, 143 for SIGTERM, 129 for SIGHUP); 204 is then the JSON ErrorStatus, unless every Test Connection had already ended, when it reflects the Test. On Windows, and for a failed write, the Client exits 204 |
| 255 | Any other error |

A Multi-Connection Test reports as OB-UDPST does: once any Test
Connection completed, success with the most severe warning of all; if
none did, the first Test Connection's error, by mcIndex, or 200 when
none had one of its own (ERROR_CONN_MIN, which keeps an earlier error).

Our own codes sit in OB-UDPST's connection-error range (200 plus an
offset), which uses only 200, away from the ranges that add an IANA
registered cmdResponse. Codes above 128 read like a shell's "killed by
signal" status; that comes with matching OB-UDPST. OB-UDPST keeps the last
warning and lets a warning replace an error; we keep the most severe.

Conformance Records: [exit-zero-with-warnings](../conformance/obudpst-differences.md#exit-zero-with-warnings), [exit-own-error-statuses](../conformance/obudpst-differences.md#exit-own-error-statuses), [exit-most-severe-warning](../conformance/obudpst-differences.md#exit-most-severe-warning), [client-interrupt](../conformance/obudpst-differences.md#client-interrupt).