The samba3.blackbox.durable_v2_delay test triggers
a race where the first connection with a specific client_guid
already entered exit_server_common(), but didn't left it
before the 2nd connection with the same client_guid is accepted.
The smbd child for the 2nd connection found the smbXsrv_client record
of the first connection and used smb2srv_client_connection_pass()
in order to send the new connection over, but it doesn't wait
for any kind of ack, that the connection was actually taken over.
We need an MSG_SMBXSRV_CONNECTION_ACCEPTED as response to
After calling smb2srv_client_connection_pass(), the sending process
needs to watch the smbXsrv_client.tdb record and wait for a
If we get MSG_SMBXSRV_CONNECTION_ACCEPTED we can exit the new process.
If the smbXsrv_client record got removed, the new process should go on
and take care of the new connection, as if it would have been the
first connection for that client guid.
Mark as regression in order to remember it for 4.13.0 if possible
We moved from blocker to regession bug status because we do not want to have a nice-to-have bug list that blocks the next release. If this is a regression from the previous release it should have the regression status, otherwise it should not. This is the otherwise case, isn't it? ;-)
This bug was referenced in samba master:
This is fixed in master now and will be included in 4.15.
(We may backport this to 4.14 at a later time...)