)]}'
{"id":"openvpn~1477","triplet_id":"openvpn~master~Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc","project":"openvpn","branch":"master","attention_set":{},"removed_from_attention_set":{"1000003":{"account":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"last_update":"2026-03-04 10:43:55.000000000","reason":"Change was submitted"},"1000001":{"account":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"last_update":"2026-02-11 15:25:35.000000000","reason":"\u003cGERRIT_ACCOUNT_1000001\u003e replied on the change","reason_account":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."}}},"hashtags":["mailsubmitted"],"change_id":"Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc","subject":"Merge stream_buf_get_next and stream_buf_set_next","status":"MERGED","created":"2026-01-19 13:56:31.000000000","updated":"2026-03-04 10:43:55.000000000","submitted":"2026-03-04 10:43:55.000000000","submitter":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"total_comment_count":22,"unresolved_comment_count":1,"has_review_started":true,"submission_id":"1477","meta_rev_id":"0cd503f123d65986cb19bdb1b6567d11b4d74aa5","_number":1477,"virtual_id_number":1477,"owner":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"actions":{},"labels":{"Code-Review":{"all":[{"value":0,"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},{"value":0,"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."}],"values":{"-2":"This shall not be submitted","-1":"I would prefer this is not submitted as is"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me, approved"},"default_value":0}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."}],"CC":[{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2026-01-19 13:56:32.000000000","updated_by":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"reviewer":{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"},"state":"CC"},{"updated":"2026-01-19 14:11:45.000000000","updated_by":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"reviewer":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"state":"REVIEWER"}],"messages":[{"id":"448857ce993e107e2ae7a37dde745bfd1853631b","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-01-19 13:56:31.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"c1780141b33f159941e65dca9f08c16b0d945f99","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-01-19 14:11:45.000000000","message":"Patch Set 1: Code-Review-2\n\n(3 comments)","accounts_in_message":[],"_revision_number":1},{"id":"84d7f9e351466d8457cc08268576ce18d8faf6c6","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-01-20 17:36:07.000000000","message":"Uploaded patch set 2.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":2},{"id":"f2b2940288d200a7fd63e6c6c08018da9e24aa59","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-01-20 18:02:37.000000000","message":"Uploaded patch set 3.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":3},{"id":"22a8e621dfff156d934d8767d1ed68336b7148d3","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-01-21 11:58:04.000000000","message":"Patch Set 3: -Code-Review","accounts_in_message":[],"_revision_number":3},{"id":"e63e33821e1e8760618774f7b73feca3b810e38d","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-01-21 12:14:08.000000000","message":"Patch Set 3: Code-Review-1\n\n(6 comments)","accounts_in_message":[],"_revision_number":3},{"id":"62ed183c82425f42f1081e6ed048a525b2eeee06","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-01-21 12:24:46.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"f2fb1bcabbe672717682d2dee0f6f8d2dbd393f8","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-01-22 09:10:50.000000000","message":"Patch Set 3:\n\n(6 comments)","accounts_in_message":[],"_revision_number":3},{"id":"b28317e7aeb13ebad85d33ba33c974c409bdac45","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-01-22 09:11:26.000000000","message":"Uploaded patch set 4.\n\nOutdated Votes:\n* Code-Review-1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":4},{"id":"2dd8ecfd542c73a9de5383783dbef68c0b03a0b3","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-01-22 12:05:06.000000000","message":"Patch Set 4: Code-Review-1\n\n(3 comments)","accounts_in_message":[],"_revision_number":4},{"id":"391678f213a14e147b44fa6ada594c51ae8cb0a0","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-01-22 12:40:03.000000000","message":"Patch Set 4:\n\n(2 comments)","accounts_in_message":[],"_revision_number":4},{"id":"95ef10d73d30c19c17ce4ab18c80e4745406917b","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-01-22 12:40:19.000000000","message":"Uploaded patch set 5: Commit message was updated.\n\nOutdated Votes:\n* Code-Review-1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":5},{"id":"d6f95b5fd9b29cf2ef83109c676d42fe284f521e","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-02-11 11:20:24.000000000","message":"Uploaded patch set 6: Patch Set 5 was rebased.","accounts_in_message":[],"_revision_number":6},{"id":"771ebd1500c1dc6207a1e040fa3e1a69ffd22e7a","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-02-11 11:33:51.000000000","message":"Uploaded patch set 7: Patch Set 6 was rebased.","accounts_in_message":[],"_revision_number":7},{"id":"e4c8dc2a5fa2539fb782e06083911ffbfb0f8124","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-02-11 15:25:35.000000000","message":"Patch Set 7: Code-Review+2\n\n(1 comment)","accounts_in_message":[],"_revision_number":7},{"id":"bfd5a761394338ba4040c8156a366f50e8b82ca8","tag":"autogenerated:gerrit:setHashtag","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-02-17 13:57:22.000000000","message":"Hashtag added: mailsubmitted","accounts_in_message":[],"_revision_number":7},{"id":"0cd503f123d65986cb19bdb1b6567d11b4d74aa5","tag":"autogenerated:gerrit:merged","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2026-03-04 10:43:55.000000000","message":"Change has been successfully pushed.","accounts_in_message":[],"_revision_number":8}],"current_revision_number":8,"current_revision":"5e85c3491fcf75f1a006d410d1a2a7720c2d3f09","revisions":{"6d251f14704b3ba6d62f79794f2ad8ccbc310499":{"kind":"REWORK","_number":1,"created":"2026-01-19 13:56:31.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/77/1477/1","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/77/1477/1","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/1 \u0026\u0026 git checkout -b change-1477 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/77/1477/1","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"2ece9a5df5ed14ca4beb026eef0687f448322245","subject":"cryptoapi: Avoid conversion warnings"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-19 13:08:44.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-19 13:56:09.000000000","tz":60},"subject":"Fix rare crash when read buffer are not initialised and read is still signalled","message":"Fix rare crash when read buffer are not initialised and read is still signalled\n\nThis assertion happens when we do not expect a read event from the socket and\nthen in link_socket_read_tcp the function stream_buf_get_next can trigger\nan assert on ASSERT(buf_defined(\u0026sb-\u003enext));\n\nTo avoid this weird corner case, just always initialise the read buffer\nwhether or not we expect a read to occur.\n\nReproducing this bug requires very special circumstances. The reproduction is\n   openvpn --cert server-secp384r1.crt  --key server-secp384r1.key \\\n   --dev ml-tan --dev-type tap --tun-mtu 1400 --config ~/fp --topology subnet \\\n   --port 2201 --verb 3  --mode server  --tls-server --proto tcp6-server\n   --ifconfig 10.0.0.1 255.255.255.0\n\nas the server side and\n\n  openvpn --client --proto tcp --remote poseidon --port 2201 --dev tap\n\nThe client side must be on Linux. Other platform do not reproduce this\nbug.\n\nNote that the client will not configure any IP or IPv6 on the interface\nand will also not bring up the interface. The server must also send at least\none real data packet to the client (no keepalive ping). Just having the\ninterface up normally produces enough traffic.\n\nNow forcefully reset the TCP connection. E.g. by executing on the server\n\n    sudo ss --kill sport 2201\n\nThis will now trigger the assertion. This happens since OpenVPN waits\nforever to get a write back from the poll from the tun/tap device but\nthis never happens since the device is not up.\n\nAs long as we do not get back the tun device for writing, we also do\nnot put the socket back into the EVENT_READ state. And this also means\nthat code to initialise the read buffer (stream_buf_set_next) is never\nrun.\n\nBut the reset on the TCP socket triggers the TCP socket to be available\nfor read, even if it is just for a read of 0 bytes to indicate the reset.\nSo the link_socket_read_tcp will run into the assert.\n\nChange-Id: Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"316919f81eccd8b483141e4e3d62eca0226cc1b9":{"kind":"REWORK","_number":2,"created":"2026-01-20 17:36:07.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/77/1477/2","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/77/1477/2","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/2 \u0026\u0026 git checkout -b change-1477 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/77/1477/2","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"f456d3f5ff982ce40f1189a43791400f8f0b3281","subject":"Change stream_buf_read_setup_dowork parameter to struct steam_buf"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-20 17:22:54.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-20 17:34:04.000000000","tz":60},"subject":"Merge stream_buf_get_next and stream_buf_set_next","message":"Merge stream_buf_get_next and stream_buf_set_next\n\nThe stream_buf_set_next prepares a buffer in the stream_buf\nstructure that will be retrieved by stream_buf_get the next\ntime it is used.\n\nThis temporary copy of the buffer is unnecessary as the buffer\nnext can also be constructed on the fly.\n\nThis also fixes a rare crash when read buffer are not initialised and\nread is still signalled as the initialisation of next will now happen whenever\nit is required.\n\nThis assertion happens when we do not expect a read event from the socket and\nthen in link_socket_read_tcp the function stream_buf_get_next can trigger\nan assert on ASSERT(buf_defined(\u0026sb-\u003enext));\n\nTo avoid this weird corner case, just always initialise the read buffer\nwhether or not we expect a read to occur.\n\nThis also adds documentation about the methods and field associated with\nthe stream_buf structure.\n\nReproducing this bug requires very special circumstances. The reproduction is\n   openvpn --cert server-secp384r1.crt  --key server-secp384r1.key \\\n   --dev ml-tan --dev-type tap --tun-mtu 1400 --config ~/fp --topology subnet \\\n   --port 2201 --verb 3  --mode server  --tls-server --proto tcp6-server\n   --ifconfig 10.0.0.1 255.255.255.0\n\nas the server side and\n\n  openvpn --client --proto tcp --remote poseidon --port 2201 --dev tap\n\nThe client side must be on Linux. Other platform do not reproduce this\nbug.\n\nNote that the client will not configure any IP or IPv6 on the interface\nand will also not bring up the interface. The server must also send at least\none real data packet to the client (no keepalive ping). Just having the\ninterface up normally produces enough traffic.\n\nNow forcefully reset the TCP connection. E.g. by executing on the server\n\n    sudo ss --kill sport 2201\n\nThis will now trigger the assertion. This happens since OpenVPN waits\nforever to get a write back from the poll from the tun/tap device but\nthis never happens since the device is not up.\n\nAs long as we do not get back the tun device for writing, we also do\nnot put the socket back into the EVENT_READ state. And this also means\nthat code to initialise the read buffer (stream_buf_set_next) is never\nrun.\n\nBut the reset on the TCP socket triggers the TCP socket to be available\nfor read, even if it is just for a read of 0 bytes to indicate the reset.\nSo the link_socket_read_tcp will run into the assert.\n\nChange-Id: Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc\n"},"branch":"refs/heads/master"},"ca0fbcfa480c9907ffa15821fe63c7745144c6e8":{"kind":"REWORK","_number":3,"created":"2026-01-20 18:02:37.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/77/1477/3","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/77/1477/3","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/3 \u0026\u0026 git checkout -b change-1477 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/77/1477/3","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/3 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"f456d3f5ff982ce40f1189a43791400f8f0b3281","subject":"Change stream_buf_read_setup_dowork parameter to struct steam_buf"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-20 17:22:54.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-20 18:01:58.000000000","tz":60},"subject":"Merge stream_buf_get_next and stream_buf_set_next","message":"Merge stream_buf_get_next and stream_buf_set_next\n\nThe stream_buf_set_next prepares a buffer in the stream_buf\nstructure that will be retrieved by stream_buf_get the next\ntime it is used.\n\nThis temporary copy of the buffer is unnecessary as the buffer\nnext can also be constructed on the fly.\n\nThis also fixes a rare crash when read buffer are not initialised and\nread is still signalled as the initialisation of next will now happen whenever\nit is required.\n\nThis assertion happens when we do not expect a read event from the socket and\nthen in link_socket_read_tcp the function stream_buf_get_next can trigger\nan assert on ASSERT(buf_defined(\u0026sb-\u003enext));\n\nTo avoid this weird corner case, just always initialise the read buffer\nwhether or not we expect a read to occur.\n\nThis also adds documentation about the methods and field associated with\nthe stream_buf structure.\n\nReproducing this bug requires very special circumstances. The reproduction is\n   openvpn --cert server-secp384r1.crt  --key server-secp384r1.key \\\n   --dev ml-tan --dev-type tap --tun-mtu 1400 --config ~/fp --topology subnet \\\n   --port 2201 --verb 3  --mode server  --tls-server --proto tcp6-server\n   --ifconfig 10.0.0.1 255.255.255.0\n\nas the server side and\n\n  openvpn --client --proto tcp --remote poseidon --port 2201 --dev tap\n\nThe client side must be on Linux. Other platform do not reproduce this\nbug.\n\nNote that the client will not configure any IP or IPv6 on the interface\nand will also not bring up the interface. The server must also send at least\none real data packet to the client (no keepalive ping). Just having the\ninterface up normally produces enough traffic.\n\nNow forcefully reset the TCP connection. E.g. by executing on the server\n\n    sudo ss --kill sport 2201\n\nThis will now trigger the assertion. This happens since OpenVPN waits\nforever to get a write back from the poll from the tun/tap device but\nthis never happens since the device is not up.\n\nAs long as we do not get back the tun device for writing, we also do\nnot put the socket back into the EVENT_READ state. And this also means\nthat code to initialise the read buffer (stream_buf_set_next) is never\nrun.\n\nBut the reset on the TCP socket triggers the TCP socket to be available\nfor read, even if it is just for a read of 0 bytes to indicate the reset.\nSo the link_socket_read_tcp will run into the assert.\n\nChange-Id: Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc\n"},"branch":"refs/heads/master"},"7fb0a3c9eabbf9b7746eab932356518d60be3b63":{"kind":"REWORK","_number":4,"created":"2026-01-22 09:11:26.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/77/1477/4","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/77/1477/4","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/4 \u0026\u0026 git checkout -b change-1477 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/77/1477/4","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/4 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"004bca91da7c0186c5b574b92ffdd61c2179bb8c","subject":"Change stream_buf_read_setup_dowork parameter to struct steam_buf"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-20 17:22:54.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-22 09:11:07.000000000","tz":60},"subject":"Merge stream_buf_get_next and stream_buf_set_next","message":"Merge stream_buf_get_next and stream_buf_set_next\n\nThe stream_buf_set_next prepares a buffer in the stream_buf\nstructure that will be retrieved by stream_buf_get the next\ntime it is used.\n\nThis temporary copy of the buffer is unnecessary as the buffer\nnext can also be constructed on the fly.\n\nThis also fixes a rare crash when read buffer are not initialised and\nread is still signalled as the initialisation of next will now happen whenever\nit is required.\n\nThis assertion happens when we do not expect a read event from the socket and\nthen in link_socket_read_tcp the function stream_buf_get_next can trigger\nan assert on ASSERT(buf_defined(\u0026sb-\u003enext));\n\nTo avoid this weird corner case, just always initialise the read buffer\nwhether or not we expect a read to occur.\n\nThis also adds documentation about the methods and field associated with\nthe stream_buf structure.\n\nReproducing this bug requires very special circumstances. The reproduction is\n   openvpn --cert server-secp384r1.crt  --key server-secp384r1.key \\\n   --dev ml-tan --dev-type tap --tun-mtu 1400 --config ~/fp --topology subnet \\\n   --port 2201 --verb 3  --mode server  --tls-server --proto tcp6-server\n   --ifconfig 10.0.0.1 255.255.255.0\n\nas the server side and\n\n  openvpn --client --proto tcp --remote poseidon --port 2201 --dev tap\n\nThe client side must be on Linux. Other platform do not reproduce this\nbug.\n\nNote that the client will not configure any IP or IPv6 on the interface\nand will also not bring up the interface. The server must also send at least\none real data packet to the client (no keepalive ping). Just having the\ninterface up normally produces enough traffic.\n\nNow forcefully reset the TCP connection. E.g. by executing on the server\n\n    sudo ss --kill sport 2201\n\nThis will now trigger the assertion. This happens since OpenVPN waits\nforever to get a write back from the poll from the tun/tap device but\nthis never happens since the device is not up.\n\nAs long as we do not get back the tun device for writing, we also do\nnot put the socket back into the EVENT_READ state. And this also means\nthat code to initialise the read buffer (stream_buf_set_next) is never\nrun.\n\nBut the reset on the TCP socket triggers the TCP socket to be available\nfor read, even if it is just for a read of 0 bytes to indicate the reset.\nSo the link_socket_read_tcp will run into the assert.\n\nChange-Id: Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc\n"},"branch":"refs/heads/master"},"031ae975e867940573719c64c09275c86899bef1":{"kind":"NO_CODE_CHANGE","_number":5,"created":"2026-01-22 12:40:19.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/77/1477/5","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/77/1477/5","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/5 \u0026\u0026 git checkout -b change-1477 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/77/1477/5","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/5 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"004bca91da7c0186c5b574b92ffdd61c2179bb8c","subject":"Change stream_buf_read_setup_dowork parameter to struct steam_buf"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-20 17:22:54.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-22 12:39:20.000000000","tz":60},"subject":"Merge stream_buf_get_next and stream_buf_set_next","message":"Merge stream_buf_get_next and stream_buf_set_next\n\nThe stream_buf_set_next prepares a buffer in the stream_buf\nstructure that will be retrieved by stream_buf_get the next\ntime it is used.\n\nThis temporary copy of the buffer is unnecessary as the buffer\nnext can also be constructed on the fly.\n\nThis also fixes a rare crash when read buffer are not initialised and\nread is still signalled as the initialisation of next will now happen whenever\nit is required.\n\nThis assertion happens when we do not expect a read event from the socket and\nthen in link_socket_read_tcp the function stream_buf_get_next can trigger\nan assert on ASSERT(buf_defined(\u0026sb-\u003enext));\n\nTo avoid this weird corner case, just always initialise the read buffer\nwhether or not we expect a read to occur.\n\nThis also adds documentation about the methods and field associated with\nthe stream_buf structure.\n\nReproducing this bug requires very special circumstances. The reproduction is\n   openvpn --cert server-secp384r1.crt  --key server-secp384r1.key \\\n   --dev ml-tan --dev-type tap --tun-mtu 1400 --config ~/fp --topology subnet \\\n   --port 2201 --verb 3  --mode server  --tls-server --proto tcp6-server\n   --ifconfig 10.0.0.1 255.255.255.0\n\nas the server side and\n\n  openvpn --client --proto tcp --remote poseidon --port 2201 --dev tap\n\nThe client side must be on Linux. Other platforms do not reproduce this\nbug.\n\nNote that the client will not configure any IP or IPv6 on the interface\nand will also not bring up the interface. The server must also send at least\none real data packet to the client (no keepalive ping). Just having the\ninterface up normally produces enough traffic.\n\nNow forcefully reset the TCP connection. E.g. by executing on the server\n\n    sudo ss --kill sport 2201\n\nThis will now trigger the assertion. This happens since OpenVPN waits\nforever to get a write back from the poll from the tun/tap device but\nthis never happens since the device is not up.\n\nAs long as we do not get back the tun device for writing, we also do\nnot put the socket back into the EVENT_READ state. And this also means\nthat code to initialise the read buffer (stream_buf_set_next) is never\nrun.\n\nBut the reset on the TCP socket triggers the TCP socket to be available\nfor read, even if it is just for a read of 0 bytes to indicate the reset.\nSo the function link_socket_read_tcp will run into the assert.\n\nChange-Id: Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc\n"},"branch":"refs/heads/master"},"932cde61bc3852c3e1bfdc67aca40bbde3a3f3df":{"kind":"TRIVIAL_REBASE","_number":6,"created":"2026-02-11 11:20:24.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/77/1477/6","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/77/1477/6","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/6 \u0026\u0026 git checkout -b change-1477 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/77/1477/6","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/6 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"0f3a16e56bbefd9dfd95a24a21318f40f83c1cb0","subject":"Change stream_buf_read_setup_dowork parameter to struct steam_buf"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-20 17:22:54.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-02-11 11:18:47.000000000","tz":60},"subject":"Merge stream_buf_get_next and stream_buf_set_next","message":"Merge stream_buf_get_next and stream_buf_set_next\n\nThe stream_buf_set_next prepares a buffer in the stream_buf\nstructure that will be retrieved by stream_buf_get the next\ntime it is used.\n\nThis temporary copy of the buffer is unnecessary as the buffer\nnext can also be constructed on the fly.\n\nThis also fixes a rare crash when read buffer are not initialised and\nread is still signalled as the initialisation of next will now happen whenever\nit is required.\n\nThis assertion happens when we do not expect a read event from the socket and\nthen in link_socket_read_tcp the function stream_buf_get_next can trigger\nan assert on ASSERT(buf_defined(\u0026sb-\u003enext));\n\nTo avoid this weird corner case, just always initialise the read buffer\nwhether or not we expect a read to occur.\n\nThis also adds documentation about the methods and field associated with\nthe stream_buf structure.\n\nReproducing this bug requires very special circumstances. The reproduction is\n   openvpn --cert server-secp384r1.crt  --key server-secp384r1.key \\\n   --dev ml-tan --dev-type tap --tun-mtu 1400 --config ~/fp --topology subnet \\\n   --port 2201 --verb 3  --mode server  --tls-server --proto tcp6-server\n   --ifconfig 10.0.0.1 255.255.255.0\n\nas the server side and\n\n  openvpn --client --proto tcp --remote poseidon --port 2201 --dev tap\n\nThe client side must be on Linux. Other platforms do not reproduce this\nbug.\n\nNote that the client will not configure any IP or IPv6 on the interface\nand will also not bring up the interface. The server must also send at least\none real data packet to the client (no keepalive ping). Just having the\ninterface up normally produces enough traffic.\n\nNow forcefully reset the TCP connection. E.g. by executing on the server\n\n    sudo ss --kill sport 2201\n\nThis will now trigger the assertion. This happens since OpenVPN waits\nforever to get a write back from the poll from the tun/tap device but\nthis never happens since the device is not up.\n\nAs long as we do not get back the tun device for writing, we also do\nnot put the socket back into the EVENT_READ state. And this also means\nthat code to initialise the read buffer (stream_buf_set_next) is never\nrun.\n\nBut the reset on the TCP socket triggers the TCP socket to be available\nfor read, even if it is just for a read of 0 bytes to indicate the reset.\nSo the function link_socket_read_tcp will run into the assert.\n\nChange-Id: Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc\n"},"branch":"refs/heads/master"},"bd6f40a8ea9fbf4f23d5a47a7220ce09c92e6df2":{"kind":"TRIVIAL_REBASE","_number":7,"created":"2026-02-11 11:33:51.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/77/1477/7","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/77/1477/7","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/7 \u0026\u0026 git checkout -b change-1477 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/77/1477/7","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/7 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5486e940173da08446b59078278bf682d683b272","subject":"Change stream_buf_read_setup_dowork parameter to struct steam_buf"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-01-20 17:22:54.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-02-11 11:33:44.000000000","tz":60},"subject":"Merge stream_buf_get_next and stream_buf_set_next","message":"Merge stream_buf_get_next and stream_buf_set_next\n\nThe stream_buf_set_next prepares a buffer in the stream_buf\nstructure that will be retrieved by stream_buf_get the next\ntime it is used.\n\nThis temporary copy of the buffer is unnecessary as the buffer\nnext can also be constructed on the fly.\n\nThis also fixes a rare crash when read buffer are not initialised and\nread is still signalled as the initialisation of next will now happen whenever\nit is required.\n\nThis assertion happens when we do not expect a read event from the socket and\nthen in link_socket_read_tcp the function stream_buf_get_next can trigger\nan assert on ASSERT(buf_defined(\u0026sb-\u003enext));\n\nTo avoid this weird corner case, just always initialise the read buffer\nwhether or not we expect a read to occur.\n\nThis also adds documentation about the methods and field associated with\nthe stream_buf structure.\n\nReproducing this bug requires very special circumstances. The reproduction is\n   openvpn --cert server-secp384r1.crt  --key server-secp384r1.key \\\n   --dev ml-tan --dev-type tap --tun-mtu 1400 --config ~/fp --topology subnet \\\n   --port 2201 --verb 3  --mode server  --tls-server --proto tcp6-server\n   --ifconfig 10.0.0.1 255.255.255.0\n\nas the server side and\n\n  openvpn --client --proto tcp --remote poseidon --port 2201 --dev tap\n\nThe client side must be on Linux. Other platforms do not reproduce this\nbug.\n\nNote that the client will not configure any IP or IPv6 on the interface\nand will also not bring up the interface. The server must also send at least\none real data packet to the client (no keepalive ping). Just having the\ninterface up normally produces enough traffic.\n\nNow forcefully reset the TCP connection. E.g. by executing on the server\n\n    sudo ss --kill sport 2201\n\nThis will now trigger the assertion. This happens since OpenVPN waits\nforever to get a write back from the poll from the tun/tap device but\nthis never happens since the device is not up.\n\nAs long as we do not get back the tun device for writing, we also do\nnot put the socket back into the EVENT_READ state. And this also means\nthat code to initialise the read buffer (stream_buf_set_next) is never\nrun.\n\nBut the reset on the TCP socket triggers the TCP socket to be available\nfor read, even if it is just for a read of 0 bytes to indicate the reset.\nSo the function link_socket_read_tcp will run into the assert.\n\nChange-Id: Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc\n"},"branch":"refs/heads/master"},"5e85c3491fcf75f1a006d410d1a2a7720c2d3f09":{"kind":"TRIVIAL_REBASE_WITH_MESSAGE_UPDATE","_number":8,"created":"2026-03-04 10:43:55.000000000","uploader":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"ref":"refs/changes/77/1477/8","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/77/1477/8","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/8 \u0026\u0026 git checkout -b change-1477 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/77/1477/8","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/77/1477/8 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d5814ecd2323ec7c2e6dad2cbf3884c031d9a5a3","subject":"Document management client versions"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2026-02-16 16:22:31.000000000","tz":60},"committer":{"name":"Gert Doering","email":"gert@greenie.muc.de","date":"2026-03-04 09:20:02.000000000","tz":60},"subject":"Merge stream_buf_get_next and stream_buf_set_next","message":"Merge stream_buf_get_next and stream_buf_set_next\n\nThe stream_buf_set_next prepares a buffer in the stream_buf\nstructure that will be retrieved by stream_buf_get the next\ntime it is used.\n\nThis temporary copy of the buffer is unnecessary as the buffer\nnext can also be constructed on the fly.\n\nThis also fixes a rare crash when read buffer are not initialised and\nread is still signalled as the initialisation of next will now happen\nwhenever it is required.\n\nThis assertion happens when we do not expect a read event from the socket\nand then in link_socket_read_tcp the function stream_buf_get_next can\ntrigger an assert on ASSERT(buf_defined(\u0026sb-\u003enext));\n\nTo avoid this weird corner case, just always initialise the read buffer\nwhether or not we expect a read to occur.\n\nThis also adds documentation about the methods and field associated with\nthe stream_buf structure.\n\nReproducing this bug requires very special circumstances.  To reproduce,\nrun a client with\n\n    openvpn --client --proto tcp --dev tap --ifconfig noexec ...\n\nThe client side must be on Linux. Other platforms do not reproduce this\nbug.\n\nNote that the client will not configure any IP or IPv6 on the interface\nand will also not bring up the interface. The server must also send at least\none real data packet to the client (no keepalive ping). Just having the\ninterface up normally produces enough traffic.\n\nNow forcefully reset the TCP connection. E.g. by executing on the client\n\n    sudo ss --kill dport \u003cserver port\u003e\n\nThis will now trigger the assertion. This happens since OpenVPN waits\nforever to get a write back from the poll from the tun/tap device but\nthis never happens since the device is not up.\n\nAs long as we do not get back the tun device for writing, we also do\nnot put the socket back into the EVENT_READ state. And this also means\nthat code to initialise the read buffer (stream_buf_set_next) is never\nrun.\n\nBut the reset on the TCP socket triggers the TCP socket to be available\nfor read, even if it is just for a read of 0 bytes to indicate the reset.\nSo the function link_socket_read_tcp will run into the assert.\n\nChange-Id: Ifd3e953104a67c8bf2a225e179865e3dbd0dbfbc\nSigned-off-by: Arne Schwabe \u003carne-openvpn@rfc2549.org\u003e\nAcked-by: Frank Lichtenheld \u003cfrank@lichtenheld.com\u003e\nGerrit URL: https://gerrit.openvpn.net/c/openvpn/+/1477\nMessage-Id: \u003c20260216162236.22304-1-gert@greenie.muc.de\u003e\nURL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg35673.html\nSigned-off-by: Gert Doering \u003cgert@greenie.muc.de\u003e\n"},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}