> On 24-04-2025 10:26, Arne Schwabe wrote:
> The code doesn't really do what the comment does. If you were trying to
> actually figure out if it is the same client you should rather compare
> the session ID of the tls state.
As for the session_id, I checked the following:
- m->session[TM_ACTIVE].session_id (matches)
- m->session[TM_ACTIVE].key[KS_PRIMARY].session_id_remote (matches)
- m->session[TM_ACTIVE].key[KS_LAME_DUCK].session_id_remote (is zero)
- m->session[TM_UNTRUSTED].session_id (does not match)
- m->session[TM_UNTRUSTED].key[KS_PRIMARY].session_id_remote (is zero)
- m->session[TM_UNTRUSTED].key[KS_LAME_DUCK].session_id_remote (is zero)
So, two session IDs match. I'll assume you meant the
m->session[TM_ACTIVE].session_id one then.
I can change the if-expression in my original patch to this:
if (m1->multi_state == CAS_CONNECT_DONE
&& m2->multi_state == CAS_NOT_CONNECTED
&& m1->locked_cert_hash_set
&& !m2->locked_cert_hash_set
&& session_id_equal(&m1->session[TM_ACTIVE].session_id,
&m2->session[TM_ACTIVE].session_id))
Or do you suggest something else?
>> The offending commit is:
>>
>> commit b364711486dc6371ad2659a5aa190941136f4f04
>> Author: Arne Schwabe <a...@rfc2549.org>
>> Date: Mon May 2 17:43:10 2022 +0200
>>
>> Implement stateless HMAC-based sesssion-id three-way-handshake
>>
>> Double checked and confirmed. Apparently this alters things so the
>> source-IP-switched connection shows up as a second connection.
[...]
> Well that changes the behaviour of how new sessions are established,
> that this change is the one that is triggering the issue is even more
> perplexing.
Well. If it was expected, we wouldn't be here investigating ;)
Can I assist you with some test or extra log line?
Cheers,
Walter
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
