)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"change_message_id":"9afb9ee15c18ab798246934c2ed9d6814326e17e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8f796033_71def18c","updated":"2025-07-27 10:39:01.000000000","message":"Actually it is just fixing one particular symptom, but we can get there in other paths as well - here\u0027s a reconnect that happened to trigger the \"query stats now!\" timer\n\n```\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 sitnl_send: checking for received messages\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 sitnl_send: rtnl: received 36 bytes\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 net_route_v6_del: fd00:abcd:220:201::/64 via fd00:abcd:220:2::1006 dev tun1 table 0 metric 100\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 sitnl_send: checking for received messages\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 sitnl_send: rtnl: received 36 bytes\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 net_route_v6_del: fd00:abcd:220:200::74/128 via fd00:abcd:220:2::1006 dev tun1 table 0 metric 100\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 sitnl_send: checking for received messages\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 sitnl_send: rtnl: received 36 bytes\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 dco_get_peer: peer-id -1\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 ovpn-dco: received netlink message type\u003d31 cmd\u003d3 flags\u003d0x0002\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 ovpn_handle_peer: parsing message for peer 0...\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 ovpn_handle_peer: received data for a non-existing peer 0\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 ovpn-dco: received netlink message type\u003d31 cmd\u003d3 flags\u003d0x0002\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 ovpn_handle_peer: parsing message for peer 1...\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 dco_update_peer_stat / dco_read_bytes(1): 1064936\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 dco_update_peer_stat / dco_write_bytes(1): 1064360\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 dco_update_peer_stat / tun_read_bytes(1): 1040000\nJul 27 12:14:55 ubuntu2004 tun-udp-p2mp[297683]: freebsd-74-amd64/udp6:194.97.140.3:62210 peer-id\u003d2 dco_update_peer_stat / tun_write_bytes(1): 1040000\n```\n\nno float involved, but still we have a \"peer-id\u003d2\" prefix for \"peer 1\" counters.\n\nSo I would suggest to move the `clear_prefix()` call into the DCO functions that deal with incoming messages, most of which will not deal with \"the client that is currently listed in the prefix\".  Maybe `ovpn_handle_msg()` (which would need the quivalent patch for FreeBSD and Windows)?  Or something generic in `dco.c` that deals with DCO events?","commit_id":"39d22dc66acc8f353b269b6f06f749a7add1e927"},{"author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"change_message_id":"56f809cded1d20dfbd5d08a7fa83816df9b9e18d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"49a36679_7b33e6bd","updated":"2025-07-27 11:02:31.000000000","message":"Here\u0027s another one... counter timer triggering while an outgoing TLS renegotiation is in progress\n\n```\nJul 27 12:33:36 ubuntu2004 tun-udp-p2mp[298589]: udp6:[2001:608:0:814::fb00:14]:33827 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519, peer signing digest/type: SHA256 RSASSA-PSS\nJul 27 12:33:36 ubuntu2004 kernel: [443346.370968] tun1: del peer 1\nJul 27 12:33:36 ubuntu2004 kernel: [443346.370974] tun1: deleting peer with id 1, reason 1\nJul 27 12:33:36 ubuntu2004 tun-udp-p2mp[298589]: udp6:[2001:608:0:814::fb00:14]:33827 [freebsd-14-amd64] Peer Connection Initiated with [AF_INET6]2001:608:0:814::fb00:14:33827\nJul 27 12:33:36 ubuntu2004 tun-udp-p2mp[298589]: freebsd-14-amd64/udp6:[2001:608:0:814::fb00:14]:33827 peer-id\u003d2 dco_get_peer: peer-id -1\nJul 27 12:33:36 ubuntu2004 tun-udp-p2mp[298589]: freebsd-14-amd64/udp6:[2001:608:0:814::fb00:14]:33827 peer-id\u003d2 ovpn-dco: received netlink message type\u003d31 cmd\u003d3 flags\u003d0x0002\nJul 27 12:33:36 ubuntu2004 tun-udp-p2mp[298589]: freebsd-14-amd64/udp6:[2001:608:0:814::fb00:14]:33827 peer-id\u003d2 ovpn_handle_peer: parsing message for peer 0...\nJul 27 12:33:36 ubuntu2004 tun-udp-p2mp[298589]: freebsd-14-amd64/udp6:[2001:608:0:814::fb00:14]:33827 peer-id\u003d2 dco_update_peer_stat / dco_read_bytes(0): 440\nJul 27 12:33:36 ubuntu2004 tun-udp-p2mp[298589]: freebsd-14-amd64/udp6:[2001:608:0:814::fb00:14]:33827 peer-id\u003d2 dco_update_peer_stat / dco_write_bytes(0): 480\n```\n\nin this case resetting the prefix would mess up prefix logging for the TLS handshake, so it\u0027s not the right approach anyway.\n\nDigging through error.c I found something half-forgotten...\n\n```\n    /* set up client prefix */\n    if (flags \u0026 M_NOIPREFIX)\n    {\n        prefix \u003d NULL;\n    }\n    else\n    {\n        prefix \u003d msg_get_prefix();\n    }\n```\n\nso I think the *right* approach is to use `msg(...|M_NOIPREFIX, ...)` for everything that is not normally related to a particular MI instance - like, most of the DCO events.\n\nMagic","commit_id":"39d22dc66acc8f353b269b6f06f749a7add1e927"},{"author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"change_message_id":"97a86031fe128dec7d989dabab2e82b3da8660e0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"cda3071a_a303312b","updated":"2025-07-27 10:24:07.000000000","message":"This does fix the problem observed.  I\u0027m not 100% sure it is the best place to reset the prefix (maybe we want to do it for incoming DCO messages instead?), but let\u0027s fix the obvious issue first.","commit_id":"39d22dc66acc8f353b269b6f06f749a7add1e927"},{"author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"change_message_id":"e351551bbb5920acfe1b02f9f7e80d15d7caa379","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d49ba7fc_663c129e","updated":"2025-09-08 20:40:13.000000000","message":"closing in on better understanding how the rest of multi.c does this","commit_id":"39d22dc66acc8f353b269b6f06f749a7add1e927"},{"author":{"_account_id":1000007,"name":"ordex","display_name":"Antonio Quartulli","email":"antonio@mandelbit.com","username":"ordex"},"change_message_id":"177cd211a8e905cf84909fcea8138184eedea826","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"c94f2053_47ac11a6","in_reply_to":"8f796033_71def18c","updated":"2025-07-28 11:37:49.000000000","message":"These are 2 different problems:\n1) when we float we set an unexpected prefix and we stick to it.\n2) when we parse notifications we may use the prefix coming from another instance.\n\nThis patch is trying to fix problem 1, which is similar but different from problem 2.","commit_id":"39d22dc66acc8f353b269b6f06f749a7add1e927"},{"author":{"_account_id":1000007,"name":"ordex","display_name":"Antonio Quartulli","email":"antonio@mandelbit.com","username":"ordex"},"change_message_id":"8354516a6b4379038941547c894ae8f0166745d5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"9613fb4f_26a118b8","in_reply_to":"c94f2053_47ac11a6","updated":"2025-07-28 11:39:36.000000000","message":"After fixing problem 1) we should heck what remains of problem 2, because we execute DCO commands always in the context of a known peer. We can\u0027t truly jump from peer X to peer Y.\nAlso when doing a PEER_GET with id\u003d-1 (dump all peers), we should not have any prefix set.\nIf we had one imho it was a leftover from the float (problem 1)","commit_id":"39d22dc66acc8f353b269b6f06f749a7add1e927"},{"author":{"_account_id":1000007,"name":"ordex","display_name":"Antonio Quartulli","email":"antonio@mandelbit.com","username":"ordex"},"change_message_id":"3ccfbe347f951fd926037cd7976c743585079b00","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"d9c73eeb_4bd71e0c","updated":"2025-09-11 19:00:21.000000000","message":"This looks sane to me. The only question I have is: it possible that we had set another prefix before waiting for the next event and now this spurious DCO notification is getting in the way? Or we normally clear the prefix before going back to waiting for the next event?","commit_id":"822a5684af7450388eede627f63777a975a2e525"},{"author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"change_message_id":"cb5918db2ea8b303c5a70873b34c46c3dd16a237","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"f234a44f_758af6dc","updated":"2025-09-11 20:12:00.000000000","message":"cooperative work","commit_id":"822a5684af7450388eede627f63777a975a2e525"}],"src/openvpn/multi.c":[{"author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"change_message_id":"e351551bbb5920acfe1b02f9f7e80d15d7caa379","unresolved":true,"context_lines":[{"line_number":3418,"context_line":"                                        (struct sockaddr *)\u0026dco-\u003edco_float_peer_ss);"},{"line_number":3419,"context_line":"            multi_process_float(m, mi, mi-\u003econtext.c2.link_sockets[0]);"},{"line_number":3420,"context_line":"            /* multi_process_float() generated and set a new peer prefix, but we"},{"line_number":3421,"context_line":"             * don\u0027t to keep it at this point."},{"line_number":3422,"context_line":"             */"},{"line_number":3423,"context_line":"            clear_prefix();"},{"line_number":3424,"context_line":"            CLEAR(dco-\u003edco_float_peer_ss);"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"e172fcee_459f337e","line":3421,"updated":"2025-09-08 20:40:13.000000000","message":"don\u0027t \"want\" to keep it?\n\nBut I think we can just drop that comment, as the overall logic is always the same across multi.c\n\n```\n   /* find mi that this is about */\n   set_prefix(mi);\n   /* do something */\n   clear_prefix();\n```\n\n... and I think this should look the same.  Will test more and come back.","commit_id":"39d22dc66acc8f353b269b6f06f749a7add1e927"}]}