)]}'
{"doc/man-sections/server-options.rst":[{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"55770e0910baed011f40289d4b8ef3515b1e4391","unresolved":true,"context_lines":[{"line_number":668,"context_line":""},{"line_number":669,"context_line":"  Valid syntaxes::"},{"line_number":670,"context_line":""},{"line_number":671,"context_line":"     server-probe-reply off"},{"line_number":672,"context_line":"     server-probe-reply max-latency-diff"},{"line_number":673,"context_line":"     server-probe-reply max-latency-diff weight"},{"line_number":674,"context_line":"     server-probe-reply max-latency-diff weight priority"}],"source_content_type":"text/x-rst","patch_set":24,"id":"dbc114bf_a9b13251","line":671,"updated":"2026-09-17 13:24:23.000000000","message":"Since the goal was to allow eventually the server probe to be a better way of three way handshake allowing a user to turn it off works against this goal. Why do you want to allow it being turned off. Is there a good reason? If yes we should discuss that reason and alternatives.","commit_id":"9e50152ebd8573e5ea2d97849672dbd45a408169"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"4e26e11bf5acb94e23bcf3b1c75c553bce4e7399","unresolved":false,"context_lines":[{"line_number":668,"context_line":""},{"line_number":669,"context_line":"  Valid syntaxes::"},{"line_number":670,"context_line":""},{"line_number":671,"context_line":"     server-probe-reply off"},{"line_number":672,"context_line":"     server-probe-reply max-latency-diff"},{"line_number":673,"context_line":"     server-probe-reply max-latency-diff weight"},{"line_number":674,"context_line":"     server-probe-reply max-latency-diff weight priority"}],"source_content_type":"text/x-rst","patch_set":24,"id":"ae876caf_30795eec","line":671,"in_reply_to":"dbc114bf_a9b13251","updated":"2026-09-18 08:33:23.000000000","message":"No good reason, I added it just in case. A server doesn\u0027t answer only makes its own clients slower, and what an admin might wait is covered by the values (priority - \"dont prefer me\", connect_livetime - \"no handshake handover\". Removed off.","commit_id":"9e50152ebd8573e5ea2d97849672dbd45a408169"},{"author":{"_account_id":1000041,"name":"ralf_lici","display_name":"Ralf Lici","email":"ralf@mandelbit.com","username":"ralf_lici"},"change_message_id":"5ce473752016c9058e49ab47b2e1e06587bdc0a6","unresolved":true,"context_lines":[{"line_number":688,"context_line":"  priority value first, and distribute load between equally-good"},{"line_number":689,"context_line":"  servers of the same priority proportionally to their weights."},{"line_number":690,"context_line":""},{"line_number":691,"context_line":"  All values are in the range :code:`0` to :code:`65535`. A UDP server"},{"line_number":692,"context_line":"  answers probes by default, whether or not this option is given, and"},{"line_number":693,"context_line":"  the values above only change what it advertises."},{"line_number":694,"context_line":"  :code:`server-probe-reply off` stops it answering probes at all. A"},{"line_number":695,"context_line":"  probing client then treats it like a server without probe support,"}],"source_content_type":"text/x-rst","patch_set":24,"id":"ec68f1fa_f418543b","line":692,"range":{"start_line":691,"start_character":58,"end_line":692,"end_character":64},"updated":"2026-09-16 15:45:49.000000000","message":"IMHO this is a wrong design decision. The change is somewhat invasive for a server configuration and silently enabling it, with default values that cannot faithfully represent every deployment seems wrong. Specifically, upgraded servers reply and are therefore ranked ahead of older, nonresponding servers, even though the administrator configured no selection policy. Am I missing something?\n\nI would expect the server to answer only when `server_probe_reply_defined \u0026\u0026 !server_probe_reply_disabled`.","commit_id":"9e50152ebd8573e5ea2d97849672dbd45a408169"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"27fb6135bdf1e5112ea3debfdc81dc6c387aa1a4","unresolved":false,"context_lines":[{"line_number":688,"context_line":"  priority value first, and distribute load between equally-good"},{"line_number":689,"context_line":"  servers of the same priority proportionally to their weights."},{"line_number":690,"context_line":""},{"line_number":691,"context_line":"  All values are in the range :code:`0` to :code:`65535`. A UDP server"},{"line_number":692,"context_line":"  answers probes by default, whether or not this option is given, and"},{"line_number":693,"context_line":"  the values above only change what it advertises."},{"line_number":694,"context_line":"  :code:`server-probe-reply off` stops it answering probes at all. A"},{"line_number":695,"context_line":"  probing client then treats it like a server without probe support,"}],"source_content_type":"text/x-rst","patch_set":24,"id":"2df5a7be_fd1f0939","line":692,"range":{"start_line":691,"start_character":58,"end_line":692,"end_character":64},"in_reply_to":"ec68f1fa_f418543b","updated":"2026-09-17 07:39:20.000000000","message":"I would keep it on by default, but I take the point that it should be a conscious decision, so let me spell out the reasoning.\n\nProbing only works when servers answer; if every admin has to turn it on, clients see no replies for years and the feature is dead on arrival. That is how other protocol capabilities have gone in: a server announces IV_ flags, answers ECHO, sends PUSH_UPDATE, without a switch per feature. The reply is stateless, costs one small packet, is rate-limited, is only ever sent for a probe that passed the control channel wrapping and the timestamp check (now with a budget for stale ones), and carries nothing the server does not already reveal in its reset.\n \nThe ordering effect you describe is real: after an upgrade, upgraded servers get preferred over old ones by probing clients. But that is what the old ones would get once upgraded too, and the admin who does not want it has --server-probe-reply off, and the one who wants a policy has the values. The RFC leaves this open (\"the server can then reply\").\n\nIf you still think the default is wrong I will flip it, but I would rather not ship a feature that is off everywhere.","commit_id":"9e50152ebd8573e5ea2d97849672dbd45a408169"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"55770e0910baed011f40289d4b8ef3515b1e4391","unresolved":true,"context_lines":[{"line_number":685,"context_line":"  ``weight`` (default :code:`50`) and ``priority`` (default :code:`100`)"},{"line_number":686,"context_line":"  have DNS SRV (RFC 2782) semantics: clients try servers with a lower"},{"line_number":687,"context_line":"  priority value first, and distribute load between equally-good"},{"line_number":688,"context_line":"  servers of the same priority proportionally to their weights."},{"line_number":689,"context_line":""},{"line_number":690,"context_line":"  All values are in the range :code:`0` to :code:`65535`. A UDP server"},{"line_number":691,"context_line":"  answers probes by default, whether or not this option is given, and"}],"source_content_type":"text/x-rst","patch_set":28,"id":"1f9209be_ccb72e66","line":688,"updated":"2026-09-17 13:24:23.000000000","message":"Should mention if low number or high number of priority means better priority.","commit_id":"47af139f1160a47717d57d0d54f8ccfd84eaebbb"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"4e26e11bf5acb94e23bcf3b1c75c553bce4e7399","unresolved":false,"context_lines":[{"line_number":685,"context_line":"  ``weight`` (default :code:`50`) and ``priority`` (default :code:`100`)"},{"line_number":686,"context_line":"  have DNS SRV (RFC 2782) semantics: clients try servers with a lower"},{"line_number":687,"context_line":"  priority value first, and distribute load between equally-good"},{"line_number":688,"context_line":"  servers of the same priority proportionally to their weights."},{"line_number":689,"context_line":""},{"line_number":690,"context_line":"  All values are in the range :code:`0` to :code:`65535`. A UDP server"},{"line_number":691,"context_line":"  answers probes by default, whether or not this option is given, and"}],"source_content_type":"text/x-rst","patch_set":28,"id":"dadd641e_e771cdac","line":688,"in_reply_to":"1f9209be_ccb72e66","updated":"2026-09-18 08:33:23.000000000","message":"\"clients try servers with a lower priority value first\" is already there, make it explicit \"lower value \u003d preferred, as in DNS SRV\"","commit_id":"47af139f1160a47717d57d0d54f8ccfd84eaebbb"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"55770e0910baed011f40289d4b8ef3515b1e4391","unresolved":true,"context_lines":[{"line_number":698,"context_line":"  ``--hand-window`` away from the server\u0027s clock is answered only within"},{"line_number":699,"context_line":"  a small budget, a twentieth of ``--connect-freq-initial``, so a client"},{"line_number":700,"context_line":"  with a wrong clock can still probe while a replayed probe gets little."},{"line_number":701,"context_line":""},{"line_number":702,"context_line":"--stale-routes-check args"},{"line_number":703,"context_line":"  Remove routes which haven\u0027t had activity for ``n`` seconds (i.e. the ageing"},{"line_number":704,"context_line":"  time).  This check is run every ``t`` seconds (i.e. check interval)."}],"source_content_type":"text/x-rst","patch_set":28,"id":"db85ad8a_3cd95c4f","line":701,"updated":"2026-09-17 13:24:23.000000000","message":"gets little what?","commit_id":"47af139f1160a47717d57d0d54f8ccfd84eaebbb"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"4e26e11bf5acb94e23bcf3b1c75c553bce4e7399","unresolved":false,"context_lines":[{"line_number":698,"context_line":"  ``--hand-window`` away from the server\u0027s clock is answered only within"},{"line_number":699,"context_line":"  a small budget, a twentieth of ``--connect-freq-initial``, so a client"},{"line_number":700,"context_line":"  with a wrong clock can still probe while a replayed probe gets little."},{"line_number":701,"context_line":""},{"line_number":702,"context_line":"--stale-routes-check args"},{"line_number":703,"context_line":"  Remove routes which haven\u0027t had activity for ``n`` seconds (i.e. the ageing"},{"line_number":704,"context_line":"  time).  This check is run every ``t`` seconds (i.e. check interval)."}],"source_content_type":"text/x-rst","patch_set":28,"id":"e2e0ae8e_26408188","line":701,"in_reply_to":"db85ad8a_3cd95c4f","updated":"2026-09-18 08:33:23.000000000","message":"changed to \"while a replayed probe is answered at most that often\"","commit_id":"47af139f1160a47717d57d0d54f8ccfd84eaebbb"}],"src/openvpn/mudp.c":[{"author":{"_account_id":1000041,"name":"ralf_lici","display_name":"Ralf Lici","email":"ralf@mandelbit.com","username":"ralf_lici"},"change_message_id":"5ce473752016c9058e49ab47b2e1e06587bdc0a6","unresolved":true,"context_lines":[{"line_number":128,"context_line":"     * unwrapped. Deciding on the verdict instead would still pay for the"},{"line_number":129,"context_line":"     * tls-crypt-v2 client-key unwrap of a reply we are never going to send. */"},{"line_number":130,"context_line":"    if (m-\u003etop.options.server_probe_reply_disabled \u0026\u0026 BLEN(\u0026m-\u003etop.c2.buf) \u003e\u003d 1"},{"line_number":131,"context_line":"        \u0026\u0026 opcode_is_oob(*BPTR(\u0026m-\u003etop.c2.buf) \u003e\u003e P_OPCODE_SHIFT))"},{"line_number":132,"context_line":"    {"},{"line_number":133,"context_line":"        return false;"},{"line_number":134,"context_line":"    }"}],"source_content_type":"text/x-csrc","patch_set":24,"id":"5e28254e_3725cfae","line":131,"updated":"2026-09-16 15:45:49.000000000","message":"`opcode_is_oob` identifies the generic OOB envelope, not a `SERVER_PROBE` specifically. Since the same opcode carries the other OOB message types, `--server-probe-reply off` will also disable `ECHO_REQ`, `ACC`, and any future OOB handling before the message can be parsed. Is disabling all OOB traffic intentional?","commit_id":"9e50152ebd8573e5ea2d97849672dbd45a408169"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"27fb6135bdf1e5112ea3debfdc81dc6c387aa1a4","unresolved":false,"context_lines":[{"line_number":128,"context_line":"     * unwrapped. Deciding on the verdict instead would still pay for the"},{"line_number":129,"context_line":"     * tls-crypt-v2 client-key unwrap of a reply we are never going to send. */"},{"line_number":130,"context_line":"    if (m-\u003etop.options.server_probe_reply_disabled \u0026\u0026 BLEN(\u0026m-\u003etop.c2.buf) \u003e\u003d 1"},{"line_number":131,"context_line":"        \u0026\u0026 opcode_is_oob(*BPTR(\u0026m-\u003etop.c2.buf) \u003e\u003e P_OPCODE_SHIFT))"},{"line_number":132,"context_line":"    {"},{"line_number":133,"context_line":"        return false;"},{"line_number":134,"context_line":"    }"}],"source_content_type":"text/x-csrc","patch_set":24,"id":"ac3e9c44_e0cca7be","line":131,"in_reply_to":"5e28254e_3725cfae","updated":"2026-09-17 07:39:20.000000000","message":"Right, once ECHO and ACC go out-of-band this would silence them too. Moved the check to after the packet is unwrapped and parsed as a SERVER_PROBE, so off disables exactly the probe reply.","commit_id":"9e50152ebd8573e5ea2d97849672dbd45a408169"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"55770e0910baed011f40289d4b8ef3515b1e4391","unresolved":true,"context_lines":[{"line_number":256,"context_line":"        /* the echo of the peer\u0027s session id, plus what we advertise */"},{"line_number":257,"context_line":"        struct oob_probe_reply reply \u003d {"},{"line_number":258,"context_line":"            .peer_session_id \u003d state-\u003epeer_session_id,"},{"line_number":259,"context_line":"            .priority \u003d (uint16_t)m-\u003etop.options.server_probe_reply_priority,"},{"line_number":260,"context_line":"            .weight \u003d (uint16_t)m-\u003etop.options.server_probe_reply_weight,"},{"line_number":261,"context_line":"            .max_latency_diff \u003d (uint16_t)m-\u003etop.options.server_probe_reply_max_latency_diff,"},{"line_number":262,"context_line":"        };"}],"source_content_type":"text/x-csrc","patch_set":24,"id":"2e8cbafc_d882789a","line":259,"updated":"2026-09-17 13:24:23.000000000","message":"If only uint16 is the valid range, then the type should be uint16 and not doing casting here.","commit_id":"9e50152ebd8573e5ea2d97849672dbd45a408169"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"4e26e11bf5acb94e23bcf3b1c75c553bce4e7399","unresolved":false,"context_lines":[{"line_number":256,"context_line":"        /* the echo of the peer\u0027s session id, plus what we advertise */"},{"line_number":257,"context_line":"        struct oob_probe_reply reply \u003d {"},{"line_number":258,"context_line":"            .peer_session_id \u003d state-\u003epeer_session_id,"},{"line_number":259,"context_line":"            .priority \u003d (uint16_t)m-\u003etop.options.server_probe_reply_priority,"},{"line_number":260,"context_line":"            .weight \u003d (uint16_t)m-\u003etop.options.server_probe_reply_weight,"},{"line_number":261,"context_line":"            .max_latency_diff \u003d (uint16_t)m-\u003etop.options.server_probe_reply_max_latency_diff,"},{"line_number":262,"context_line":"        };"}],"source_content_type":"text/x-csrc","patch_set":24,"id":"e17f2771_aedddbcb","line":259,"in_reply_to":"2e8cbafc_d882789a","updated":"2026-09-18 08:33:23.000000000","message":"oob_probe_reply_{priority,weight,max_latency_diff} become uint16_t in options.h, casts are gone.","commit_id":"9e50152ebd8573e5ea2d97849672dbd45a408169"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"55770e0910baed011f40289d4b8ef3515b1e4391","unresolved":true,"context_lines":[{"line_number":246,"context_line":"        }"},{"line_number":247,"context_line":"        if (m-\u003etop.options.server_probe_reply_disabled)"},{"line_number":248,"context_line":"        {"},{"line_number":249,"context_line":"            return false; /* --server-probe-reply off: exactly the probe reply, nothing else */"},{"line_number":250,"context_line":"        }"},{"line_number":251,"context_line":"        /* A client whose clock is off by more than --hand-window still gets a"},{"line_number":252,"context_line":"         * few probes per period answered, which is also all a replayed probe"}],"source_content_type":"text/x-csrc","patch_set":28,"id":"d8eb059d_c812534d","line":249,"updated":"2026-09-17 13:24:23.000000000","message":"I don\u0027t understand what \"exactly the probe reply, nothing else\" means here.","commit_id":"47af139f1160a47717d57d0d54f8ccfd84eaebbb"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"4e26e11bf5acb94e23bcf3b1c75c553bce4e7399","unresolved":false,"context_lines":[{"line_number":246,"context_line":"        }"},{"line_number":247,"context_line":"        if (m-\u003etop.options.server_probe_reply_disabled)"},{"line_number":248,"context_line":"        {"},{"line_number":249,"context_line":"            return false; /* --server-probe-reply off: exactly the probe reply, nothing else */"},{"line_number":250,"context_line":"        }"},{"line_number":251,"context_line":"        /* A client whose clock is off by more than --hand-window still gets a"},{"line_number":252,"context_line":"         * few probes per period answered, which is also all a replayed probe"}],"source_content_type":"text/x-csrc","patch_set":28,"id":"c77c9465_3697676c","line":249,"in_reply_to":"d8eb059d_c812534d","updated":"2026-09-18 08:33:23.000000000","message":"\"off\" is gone now.","commit_id":"47af139f1160a47717d57d0d54f8ccfd84eaebbb"}],"src/openvpn/options.c":[{"author":{"_account_id":1000041,"name":"ralf_lici","display_name":"Ralf Lici","email":"ralf@mandelbit.com","username":"ralf_lici"},"change_message_id":"3d24ad0df039cee362e013e5ddea10b07228fc6c","unresolved":true,"context_lines":[{"line_number":483,"context_line":"    \"--client-to-client : Internally route client-to-client traffic.\\n\""},{"line_number":484,"context_line":"    \"--server-probe-reply m [w [p]] : Advertise latency margin m (ms), weight w\\n\""},{"line_number":485,"context_line":"    \"                  and priority p in replies to --server-probe clients.\\n\""},{"line_number":486,"context_line":"    \"                  \u0027off\u0027 stops answering probes altogether.\\n\""},{"line_number":487,"context_line":"    \"--duplicate-cn  : Allow multiple clients with the same common name to\\n\""},{"line_number":488,"context_line":"    \"                  concurrently connect.\\n\""},{"line_number":489,"context_line":"    \"--client-connect cmd : Run command cmd on client connection.\\n\""}],"source_content_type":"text/x-csrc","patch_set":29,"id":"ac19b049_ead3eea5","line":486,"range":{"start_line":486,"start_character":23,"end_line":486,"end_character":62},"updated":"2026-09-21 10:18:56.000000000","message":"No longer it seems ;) This stale reference appears also in the commit message.","commit_id":"4d012d1a365a805f9abeae9014602d3556083bac"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"c06dad5caaf8e87301e2147fdcc079e905704e61","unresolved":false,"context_lines":[{"line_number":483,"context_line":"    \"--client-to-client : Internally route client-to-client traffic.\\n\""},{"line_number":484,"context_line":"    \"--server-probe-reply m [w [p]] : Advertise latency margin m (ms), weight w\\n\""},{"line_number":485,"context_line":"    \"                  and priority p in replies to --server-probe clients.\\n\""},{"line_number":486,"context_line":"    \"                  \u0027off\u0027 stops answering probes altogether.\\n\""},{"line_number":487,"context_line":"    \"--duplicate-cn  : Allow multiple clients with the same common name to\\n\""},{"line_number":488,"context_line":"    \"                  concurrently connect.\\n\""},{"line_number":489,"context_line":"    \"--client-connect cmd : Run command cmd on client connection.\\n\""}],"source_content_type":"text/x-csrc","patch_set":29,"id":"7c0497a6_07baf4fc","line":486,"range":{"start_line":486,"start_character":23,"end_line":486,"end_character":62},"in_reply_to":"ac19b049_ead3eea5","updated":"2026-09-22 13:13:46.000000000","message":"good catch, fixed.","commit_id":"4d012d1a365a805f9abeae9014602d3556083bac"}]}