IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit c6d0df787a.
Said commit did not help with GitLab CI timeouts, but just made the CI
pipeline take longer when the test did time out.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Print the time (as reckoned by tevent) at which each ‘negprot done’ and
‘echo done’ message is produced, and print another message if one of the
requests times out.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15498
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Tue Oct 24 15:51:40 UTC 2023 on atb-devel-224
This demonstrates the race quite easily against
Samba and works fine against Windows Server 2022.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15346
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
commit 55b2f247f9 already remove a few of these,
but a few remained.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The timer for the timeout_cb() handler was created on a memory context
which doesn't get freed, so the timer was still valid when running
the next test and fired there. It was then writing into random memory
leading to segfaults.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Thu Dec 1 15:03:19 UTC 2022 on sn-devel-184
GCC 9.3.0 doesn't like a true array being compared to NULL.
[3628/3972] Compiling source4/torture/smb2/multichannel.c
../../source4/torture/smb2/multichannel.c:1077:7: error: comparison of array 'trees2' equal to a null pointer is always false [-Werror,-Wtautological-pointer-compare]
if (trees2 == NULL || trees2[i] == NULL) {
^~~~~~ ~~~~
../../source4/torture/smb2/multichannel.c:1284:7: error: comparison of array 'trees2' equal to a null pointer is always false [-Werror,-Wtautological-pointer-compare]
if (trees2 == NULL || trees2[i] == NULL) {
^~~~~~ ~~~~
../../source4/torture/smb2/multichannel.c:2337:7: error: comparison of array 'trees2' equal to a null pointer is always false [-Werror,-Wtautological-pointer-compare]
if (trees2 == NULL || trees2[i] == NULL) {
^~~~~~ ~~~~
3 errors generated.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Fri Jul 17 07:16:31 UTC 2020 on sn-devel-184
This is similar to the smb2.multichannel.leases.test5,
but it tests the oplock case instead of leases.
With Oplocks Windows only sends a single break on the latest channel,
this is not what the spec says...
Maybe we should have a similar test that would expect the
behavior from the [MS-SMB2] (3/4/2020 rev 60.0)
"3.3.4.6 Object Store Indicates an Oplock Break":
...
If the server implements the SMB 3.x dialect family, SMB2 Oplock Break
Notification MUST be sent to the client using the first available
connection in Open.Session.ChannelList where Channel.Connection is not
NULL. If the server fails to send the notification to the client, the
server MUST retry the send using an alternate connection, if available,
in Open.Session.ChannelList.
...
Here I add one test that demonstrates the Windows behavior:
smb2.multichannel.oplocks.test3_windows
and a 2nd test that demonstrates the behavior from MS-SMB2.
smb2.multichannel.oplocks.test3_specification
Note that Windows 10 seems to behave differently and it's not
possible to open all 32 channel used by this test.
Against remote servers it's required to run iptables as root:
#> smbtorture //server/torture -Uu%p \
--option="torture:use_iptables=yes" \
--option="torture:iptables_command=sudo /sbin/iptables" \
smb2.multichannel.oplocks.test3_windows
#> smbtorture //server/torture -Uu%p \
--option="torture:use_iptables=yes" \
--option="torture:iptables_command=sudo /sbin/iptables" \
smb2.multichannel.oplocks.test3_specification
The test will also work against a Samba server
with 'smbd:FSCTL_SMBTORTURE = yes', and won't require iptables
in that case.
Samba will get a "smb2 disable oplock break retry" configuration
option to switch between both behaviors, as it's much more common with Samba
that leases are not supported and clients will fallback to
oplocks together with multichannel.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
This tests 32 channels, which is the maximum Windows Server
versions support. (Note that Windows 10 (a Client OS as SMB server,
seems to support only 20 channels and may differ in other aspects,
so we ignore that for now).
This works at least against Windows Server 2019
and we see lease break notification retries every ~ 1.3 seconds
with ~ 5 TCP retransmissions. At that rate we see the remaining
5 retries after the conflicting SMB2 Create already returned.
Older Windows Server versions use much longer timeouts in the TCP-stack,
they send lease break notification retries less often and only 4 in
total, all other channels get TCP-RST packets because of missing
TCP keepalive packets before they're used.
The intervals between lease break notification retries are
~19 seconds for 2012[_R2] and ~25 seconds for 2016.
It means that only ~2 lease break notifications arrive before
the open returns after ~35 seconds.
Note that Windows 10 seems to behave differently and it's not
possible to open all 32 channel used by this test.
Against remote servers it's required to run iptables as root:
#> smbtorture //server/torture -Uu%p \
--option="torture:use_iptables=yes" \
--option="torture:iptables_command=sudo /sbin/iptables" \
smb2.multichannel.leases.test4
The test will also work against a Samba server
with 'smbd:FSCTL_SMBTORTURE = yes', and won't require iptables
in that case.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
Having a test that would only pass against Samba makes things way
to complex, they're already complex and we should try to behave
like windows as much as possible.
The next commit will add a better test that will work against Windows
Servers and the future Samba servers.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
We still receive the break on the blocked channel,
it's only the response ACKs, which we are blocking (or simulate to
block).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
We may want to use this in other places too, not only multichannel.c
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
This is a way to test without being able to use iptables.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
In order to create useful tests, we should block the outgoing
tcp packets only. That means we're able to see incoming
break notifications, but prevent outgoing TCP ACKs to be delivered
to the server.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
This avoid useless session setups and tree connects on the wire.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
Test to see how the server behaves when the client flushes data back to
the server but doesn't send the lease break response over the channel.
Does it then retry the lease break?
This test is specifically expected to run against Samba and will not
work against a MS Windows servers because it uses the ignore method to
ignore oplock breaks sent by the server.
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Check to see how the server behaves if lease break response is sent
over a different channel to one over which the break is received.
The test by default blocks channels by ignoring incoming lease break
requests on that channel. This does not work when testing against a
windows server.
Use --option=torture:use_iptables=true to use iptables to block ports
instead when testing against windows servers.
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Test to check if lease breaks are sent by the server as expected.
The test by default blocks channels by ignoring incoming lease break
requests on that channel. This does not work when testing against a
windows server.
Use --option=torture:use_iptables=true to use iptables to block ports
instead when testing against windows servers.
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Test to check if lease breaks are sent by the server as expected.
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Test to see if oplock break retries are sent by the server.
Also checks to see if new channels can be created and used
after an oplock break retry.
The test by default blocks channels by ignoring incoming lease break
requests on that channel. This does not work when testing against a
windows server.
Use --option=torture:use_iptables=true to use iptables to block ports
instead when testing against windows servers.
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Test to confirm that server sends oplock breaks as expected.
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
We use two methods to block channels
1) Simply ignore incoming oplock break requests and do not respond to
them.
This method doesn't work against Microsoft Windows based servers which
rely on the tcp stack for confirmation that the oplock break command was
sent to the client machine. This is meant to be used with samba servers
and is the default method.
2) Use iptables to block the channel.
The method requires the use of a privileged account and can only be used
on Linux systems with iptables installed. To use this blocking method,
pass the option
--option=torture:use_iptables=true
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Helper functions used by both oplock and lease break tests.
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
New macros used by our tests.
Signed-off-by: Guenther Deschner <gd@samba.org>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Also Skip MC tests for s4 ntvfs fileserver, it's not supported at all.
Use knownfail for s3 fileserver for the time being (until socketwrapper
supports fd-passing).
Signed-off-by: Guenther Deschner <gd@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
