Opensuse, KDE Plasma, X11, Nvidia – stop video and screen tearing

Posted on 5. November 2020 by eremo

In these times of Corona, home-office and of increased Internet usage some of us Linux guys may experience an old phenomenon: screen and video tearing. In my case it happened with an Nvidia card and with X11 (Wayland does not yet work on my Opensuse Leap 15.1 – I am too lazy to investigate why). I have ignored the tearing already for some months – but now it really annoyed me. I saw tearing already some years ago; at that point in time activating triple buffering helped. But not these days …

Where did I see the tearing?

I observed tearing effects

when moving “wobbling windows” (one of KDE’s desktop effects) across the screen – strangely enough when moving them slowly,
when watching TV and video streams in browsers (independent of FF, Opera or Chromium) – mostly when major parts of the video changed quickly.

Not much, not always – but enough to find it annoying. So, I invested some time – and got rid of it.

Driver and contents of the xorg.conf file

Driver: Latest Nvidia driver from Opensuse’s NVidia Repository: nvidia-glG05, x11-video-nvidiaG05.

I have three screens attached to my NVidia card (GTX 960); two of them are of the same type, but one has a lower resolution than the others. The screens are configured to work together as a super wide screen via the Xinerama setting in the xorg configuration file. Below, you find the contents of the file “/etc/X11/xorg.conf” with details about the screen configuration and modes.

xorg.conf

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 450.80.02


Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from data in "/etc/sysconfig/mouse"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"

    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL U2515H"
    HorizSync       30.0 - 113.0
    VertRefresh     56.0 - 86.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 960"
EndSection

Section "Screen"

    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-2"
    Option         "ForceFullCompositionPipeline"  "on"
#    Option         "ForceCompositionPipeline"  "on"
    Option         "metamodes" "DP-4: nvidia-auto-select +0+0, DP-0: nvidia-auto-select +2560+0, DVI-I-1: nvidia-auto-select +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: nvidia-auto-select +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1920x1080 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1680x1050 +5120+0; DP-4: nvidia-auto-select 
+2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1600x1200 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1440x900 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1280x1024 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1280x960 +5120+0"
    Option         "SLI" "Off"
    Option         "TripleBuffer" "True"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

The most important statement regarding the suppression of tearing is

    Option         "ForceFullCompositionPipeline"  "on"

Alternatively,

    Option         "ForceCompositionPipeline"  "on"

seems to work equally well. Use the latter, if your graphics should react a bit sluggish.

We find more information about these options in the “nvidia-settings” application:

When you move your mouse over the option for “ForceCompositionPipeline” and “ForceFullCompositionPipeline”, you get

The Nvidia driver can use a composition pipeline to apply Xscreen transformations and rotations. “ForceCompositionPipeline” can be used to force the use of this pipeline, even when no transformations or rotations are applied to the screen. This option is implicitly set by ForceFullCompositionPipeline.

and, respectively,

“This option implicitly enables “ForceCompositionPipeline” and additionally makes use of the composition pipeline to apply ViewPortOut scaling.”

Important: If you want to test the setting via nidia-settings, you have to activate the options it for all three screens!.

When I first tested “ForceCompositionPipeline” I just set it on the page of “nvidia-settings” for the first screen of my three, wrongly assuming that this setting was applied in general. However, tearing did not disappear. I realized after some time that it still happened on 2 screens predominantly. I even suspected a different quality of the display-port cables to my screens to be the cause of tearing. Wrong … the ForceCompositionPipeline had been applied to one screen, only.

So, switch to the other screens by using the first combo-box on the “nvidia-settings”-page and set “ForceCompositionPipeline” for all screens. Do this before you eventually save the settings to a “xorg.conf”-file (as root). Your resulting xorg.conf file may look a bit different; the CompositionPipeline-settings might be included as a side-option of the meta-mode settings – and not in form of a special separate line as shown above.

Regarding Xvideo- and OpenGL-settings you should activate syncing;

KDE Plasma settings

KDE Plasma settings for the screens should be consistent with the “nvidia-settings”. You use KDE’s “system-settings” >> “Display and Monitor” >> “Displays” and “Compositor”.

The combination of all the settings discussed above worked in my case – the tearing disappeared for videos in browsers, in video applications as well as on the Xinerama KDE Plasma screen in general.

Conclusion

It is easy to suppress video and screen tearing on an Opensuse Leap system with KDE PLasma and a Nvidia graphics card. The most important point is to activate “ForceCompositionPipeline” on all individual screens via “nvidia-settings” or to activate this option globally for the Xinerama screen of a multi-monitor configuration.

KDE, Pulseaudio and Browsers – make the LADSPA equalizer the default sink

Posted on 4. November 2020 by eremo

During these days of Covid-19, home-office and lock-downs browsers and other Internet streaming tools as VLC become important personal gates to the world. When streaming videos or songs a user, of course, wants to hear some sound. No problem with Linux – Alsa helped you already decades ago. But things used to become a bit complicated if you wanted to direct the output of multiple sound-sources through a global equalizer of your Linux desktop environment (in my case preferably KDE). An equalizer may help to compensate deficits of cheap speakers or hearing problems of elderly persons as me. Well, if you found a global desktop equalizer at all. With KDE, no chance – it always was a strange policy of the KDE-people to assume that an equalizer is none of their responsibilities. So, a standard Linux user depended on application specific equalizers – which at least many Linux sound and video players offered. But what about browsers?

This is, where “Pulseaudio” and the related “Ladspa” based equalizer really were of help to a common user. As a matter of fact, I have never been a real friend of “Pulseaudio” [PA]; you can find some critical posts regarding PA in this blog. However, I gladly admit that Pulseaudio and its control interfaces have become substantially better with the years. At some point in the past PA started to work reasonably well even with multi-channel soundcards. It is now also much better integrated with KDE’s “Phonon” system than some years ago. Today, you can define e.g. a central volume control without destroying the relative volume ratios of different output channels of a sound card. And: We have a well integrated equalizer as a desktop-wide, global tool to improve the sound quality. So, why a post about it?

A problem with (automatically) changing streams and an assignment to a default sink

A problem with KDE and Pulseaudio in the past was the following: Only some applications (as e.g. “Clementine) ” gave/give the user a chance to specify a sink of the sound environment to which the sound output of the application is transferred for further processing.

A sound sink is a kind of sound module which accepts a sound stream as input, processes it and may send an output to other processing modules or an amplifier. On KDE you may find some available sinks for your sound card or cards under “system-settings >> Multimedia”. An important sink in our present context is the PA equalizer. See https://doc.qt.io/archives/qt-4.8/phonon-overview.html for the inclusion of media objects and sinks into a sound flow model (“graphs”) for KDE.

However, a lot of applications as e.g. browsers do not offer any settings to modify the primary sound sink. Instead they address a “default sink” of the system. What the “default sink” was, was either non-transparent to the user, or some related settings within your KDE desktop were just ignored, or you had to dive deep into the unhandy Alsa and the PA-configuration options. This led to major inconveniences for normal users:

When a new sound stream was activated a default sound sink was chosen by many applications which often did not correspond to the preferred one – namely the equalizer.

This problem could only partially be overcome by using “pavucontrol”, a PA-tool to control volume settings on channels and sinks in the system. “pavucontrol”actually allowed and allows the user to assign sinks to running applications and their sound streams. However, when the application switched from one stream to another – e.g. automatically in a media-player with a list of songs or on the web (youtube changing videos) – then the newly selected stream fell back to the default sink. Driving the user nuts ….

Setting of the default sink for the KDE desktop

nI use Opensuse Leap 15.1/2 with KDE as my main working environment (besides Debian and Kali with Gnome 🙂 ). By chance I recently found something which did not work for me in previous installations. In KDE we have a specific sound system – “Phonon” – which allows the user to organize the priority of “devices” (sinks) for certain kinds of applications. In my case you see the settings for “music” applications:

You see that I have 2 sound cards available – but to make things simpler I deactivated one of them for this blog post. The first device listed is the PA’s LADSPA equalizer:

It got the highest priority for music streams – more precisely for applications which follow the Qt/Phonon-API-rules when playing music streams. But, what about browsers (FF, Chromium, Opera, …), what about applications designed for Gnome and GTK3? You often can direct them to use PA, but what does PA respect as a default sink in a KDE environment with Phonon?

Well the simple “trick” which I found working recently is to set the priorities for all audio in KDE’s Phonon-settings:

Then we get the following PA-settings (install and start the pulseaudio-manager application “paman”):

This is what we need! And this setting is (now) respected by browsers and other applications that seek a default sink.

So: KDE, Pulseaudio and Phonon settings actually give a common KDE user the chance to direct all sound through the Ladspa equalizer as a default sink.

If your media-player offers its own equalizer you can of course combine both equalizers.

By the way: Common volume control

In the above picture on Phonon settings the sink “Simultaneous output to …” directs multiple sound sources to one or multiple sound devices. As we direct all sound through the equalizer first, we give the “Simultaneous output …“-device second priority.

We can use it for a common volume control in KDE’s Kmix: If you right-click on the Kmix symbol or open it you get an option to choose the main output channel :

Now, this setting assigns the desktop’s global volume control to this sink – which leaves all other volume settings, e.g. for the relative volumes of the sound-card channels, untouched:

You may find that this settings is transported to the sound control keys of a keyboard with a media control bar (e.g. on a Cherry keyboard).

Conclusion

With the help of KDE’s system-settings and Pulseaudio we can direct the output of all audio applications through a desktop wide equalizer, which we define by Phonon settings as a default sink. This is simply done by giving PA’s LADSPA equalizer the highest priority for all audio. You do not need to dive into PA configuration depths or the command line for changing PA’s device and sink graphs for sound flows.
The “Simultaneous output ….” device (or sink) allows for a global volume control which respects other volume settings controlled e.g. via PA’s “pavucontrol”.

Samba 4, shares, wsdd and Windows 10 – how to list Linux Samba servers in the Win 10 Explorer

Posted on 24. May 2020 by eremo

These days I relatively often need to work with Windows 10 at home (home-office, corona virus, …). Normally, I isolate my own Win 10 instance in a VMware virtual machine on my Linux PC – and reduce any network connections of this VM to selected external servers. Under normal conditions all ports on the Linux host are closed for the virtual machine [VM]. But on a few temporary occasions I want to the Win 10 system to access a specific Samba exchange directory on a KVM virtualized Linux instance on the same host.

Off topic: You see that I never present directories of my Linux host directly to a Win 10 guest via Samba. Instead I transfer files via an exchange directory on an intermediate VM whose Samba service is configured to disallow access of the Win system on shares presented to the host. A primitive, but effective form of separation. The only inconvenient consequence is that synchronization becomes a two-fold process on the host and the Linux VM. But we have Linux tools for this, so the effort is limited. )

Of course we want to use the SMB protocol in a modern version, i.e. version 3.x (SMB3), over TCP/IP for this purpose (port 445). In addition we need some mechanism to detect and browse SMB servers on the Windows system. In the old days NetBIOS was used for the latter. On the Linux side we had the nmbd-daemon for it – and we could set up a special Samba server as a WINS server.

During the last year Microsoft has – via updates and new builds of Windows 10 – followed a consistent politics of deactivating the use of SMB V1.0 systematically. This, however, led to problems – not only between Windows PCs, but also between Win 10 instances and Samba 4 servers. This article addresses one of these problems: the missing list of available Samba servers in the Windows Explorer.

There are many contributions on the Internet describing this problem and some even say that you only can solve it by restoring SMB V1 capabilities in Win 10 again. In this article I want to recommend two different solutions:

Ignore the problem of Samba server detection and use your Samba shares on Win 10 with the SMB3 protocol as network drives.
If you absolutely want to see and list your Samba servers in the Windows Explorer of a Win 10 client, use the “Web-Service-Discovery” service via a WSDD-daemon provided by a Python script of Steffen Christgau.

I myself got on the right track of solving the named problem by an article of a guy called “Stilez”. His article is the first one listed under the section “Links” below. I recommend strongly to read it; it is Stilez who deserves all credit in pointing out both the problem and the solution. I just applied his insight to my own situation with virtualized Samba servers based on Opensuse Leap 15.1.

SMB V1.0 should be avoided – but NetBIOS needs it to exchange information about SMB servers

SMB, especially version SMB V1.0, is well known for security problems. Even MS has understood this – especially after the Wannacry disaster. See e.g. the links in the section “Links” => “Warnings of SMBV1” at the end of this article. MS has deactivated SMB V1 in the background via some updates of Win 8 and Win 10.

One of the resulting problem is that we do not see Samba servers in the Windows Explorer of a Win 10 system any longer. In the section “Network” of the Windows Explorer you normally should see a list of servers which are members of a Workgroup and offer shares.

Two years ago we would use NetBIOS’s discovery protocol and a WINS server to get this information. Unfortunately, the NetBIOS service detection ability depends on SMB1 features. The stupid thing is that we for a long while now had and have a relatively secure SMB2/3, but NetBIOS discovery only worked with SMB V1 enabled on the Windows client. Deactivating SMB V1 means deactivating NetBIOS at the
same time – and if you watch your Firewall logs for incoming packets from the Win 10 clients you will notice that exactly such a thing happened on Win 10 clients.

This actually means that you can have a full featured Samba/NetBIOS setup on the Linux side, that you may have opened the right ports on the firewalls for your Samba/WINS server and client systems, but that you will nevertheless not get any list of available Samba servers in Win 10’s Explorer. 🙁

Having understood this leads to the key question for our problem:

By what did MS replace the detection features of NetBIOS in combination with SMB-services?

Settings on the MS Win side – which alone will not help

When you google a bit you may find many hints regarding settings by which you activate network “discovery” functionalities via two Windows services. See

https://www.wintips.org/fix-windows-10-network-computers-not-showing/
https://winaero.com/blog/network-computers-not-visible-windows-10-version-1803/

You can follow these recommendations. If you want to see your own PC and other Windows systems in the Explorer’s list of network resources you must have activated them (see below). However, in my Win 10 client the recommended settings were already activated – with the exception of SMB V1, which I did and do not wish to reactivate again. The “discovery” settings may help you with other older Windows systems, but they do not enable a listing of Samba 4 servers without additional measures on Win 10.

There is another category of hints which in my opinion are contra-productive regarding security. See https://devanswers.co/network-error-problem-windows-cannot-access-hostname-samba/
Why activate an insecure setting? Especially, as such a setting does not really help us with our special problem? 🙁

A last set of hints concerns the settings on the Samba server, itself. I find it especially nice when such recommendations come from Microsoft :-). See: http://woshub.com/cannot-access-smb-network-shares-windows-10-1709/

[global]
server min protocol = SMB2_10
client max protocol = SMB3
client min protocol = SMB2_10
encrypt passwords = true
restrict anonymous = 2

Thanks to MS we now understand that we should not use SMB V1 …. But, actually, these hints are again insufficient regarding the Explorer problem …

What you could do – but should NOT do

Once you have understood that NetBIOS and SMB V1 still have an intimate relation (at least on a Windows systems) you may get the idea that there might exist some option to reactivate SMBV1 again on the Win 10 system. This is indeed possible. See here:
https://community.nethserver.org/t/windows-10-not-showing-servers-shares-in-network-browser/14263/4
https://www.wintips.org/fix-windows-10-network-computers-not-showing/

If you follow the advice of the authors and in addition re-open the standard ports for NetBIOS (UDP) 137, 138, (TCP) 139 on your firewalls between the Win 10 machine and your Samba servers you will – almost at once – get up the list of your accessible Samba servers in the Network section of the Win 10 Explorer. (Maybe you have to restart the smb and nmb services on your Linux machines).

But: You should not do this! SMB V1 should definitely become history!

Fortunately, a re-activation of SMB V1
on a Win 10 system is NOT required to mount Samba shares and it is neither required to get a list of available Samba servers in the Win 10 Explorer.

What you should do: Win 10 service settings

There are two service settings which are required to see other servers (and your own Win10 PC itself) in the list of network hosts presented by the Windows explorer:
Start services.msc ( press the Windows key + R => Enter “services.msc” in the dialog. Or: start services.msc it via the Control Panel => System and Security => Services)

Look for “Function Discovery Provider Host” => Set : Startup Type => Automatic
Look for “Function Discovery Resource Publication” => Set : Startup Type => Automatic (Delayed Start) !!

I noticed that on my VMware Win 10 guests the second setting appeared to be crucial to get the Win 10 PC itself listed among the network servers.

What you should do: Use the SMBV3 protocol!

As you as a Linux user meanwhile have probably replaced all your virtualized Win 7 guests, you should use the following settings in the [global] section of the configuration file “/etc/samba/smb.conf” of your Samba servers:

[global]
…
“protocol = SMB3”.
…

This is what Win 10 supports; you need SMB2_10 with some builds of Win 8 (???), only. Remember also that port 445 must be open on a firewall between the Win 10 client and your Samba server.

For Linux requirements to use SMB3 see
https://wiki.samba.org: SMB3 kernel status
For “SMB Direct” (RDMA) you normally need a kernel version > 4.16. On Opensuse Leap 15.1 most of the required kernel features have been backported. In Win 10 SMB Direct is normally activated; you find it in the “Window-Features” settings (https://www.windowscentral.com/how-manage-optional-features-windows-10)

Not seeing Samba servers in the Explorer does not mean that mounting a Samba share as a network drive does not work

Not seeing the Samba servers in the Win 10 Explorer – because the NetBIOS detection is defunct – does not mean that you cannot work with a Samba share on a Win 10 system. You can just “mount” it on Windows as a “network drive“:

Open a Windows Explorer, choose “This PC” on the left side, then click “Map network drive” in the upper area of the window and follow the instructions:
You choose a free drive letter and provide the Samba server name and its share in the usual MS form as “\\SERVERNAME\SHARE”.
Afterwards, you must activate the option “Connect using different credentials” in the dialog on the Win 10 side, if your Win 10 user for security reasons has a different UID and Password on the Samba server than on Win 10. Needless to say that this is a setting I strongly recommend – and of course we do not allow any direct anonymous or guest access to our Samba server without credentials delivered from a Windows machine (at least not without any central authentication systems).
So, you eventually must provide a valid Samba user name on your Samba server and the password – and there you happily go and use your resources on the Samba share from your Win 10 client.

I assumed of course that you have allowed access from the Win 10 host and the user by respective settings of “hosts allow” and “valid users” for the share in your Samba configuration.
Note: You need not mark the option for reconnecting the share in the Windows dialog for network drives if you only use the Samba exchange shares temporarily.

On an Opensuse system this works perfectly with the protocol settings for SMB3 on the server. So, you can use your shares even without seeing the samba
server in the Explorer: You just have to know what your shares are named and on which Samba servers they are located. No problem for a Linux admin.

In my opinion this approach is the most secure one among all “peer to peer”-approaches which have to work without a central network wide authentication service. It only requires to open port 445 for the time of a Samba session to a specific Samba server. Otherwise you do not provide any information for free to the Win 10 system and its “users”. (Well, an open question is what MS really does with the provided Samba credentials. But that is another story ….)

What you should do: Use the WSDD service on your Samba server

If you allow for some information sharing between your virtualized Win 10 and other KVM based virtual Samba machines in your LAN – and are not afraid of Microsoft or Antivirus companies on the Windows system to collect respective information – then there is a working option to get a stable list of the available Samba servers in the Windows Explorer – without the use of SMB V1.0.

Windows 10 implements web service detection via multiple mechanisms; among them: Multicast messages over ports 3702 (UDP), TCP 5357 and 1900 (UDP). For a detection of Samba services you “only” need ports 3702 (UDP) and 5357 (TCP). The general service detection port 1900 can remain closed in the firewalls between your Win 10 instances and your Linux world for our specific purpose. See
https://www.speedguide.net/port.php?port=5357
https://www.speedguide.net/port.php?port=3702
https://techcommunity.microsoft.com/t5/ask-the-performance-team/ws2008-the-wsd-port-monitor/ba-p/372760
https://en.wikipedia.org/wiki/Simple Service Discovery Protocol

The mechanism using ports 3702 and 5351 is called “Web Service Discovery” and was introduced by MS to cover the detection of printers and other devices in networks. In combination with SMB2 and SMB3 it is the preferred service to detect Samba services.

OK, do we have something like a counter-part available on a Linux system? Obviously, such a service is not (yet?) included in Samba 4 – at least not in the 4.9 version on my system with Opensuse Leap 15.1. The fact that WSD is not (yet?) a part of Samba may have some good reasons. See link.
One can understand the reservations and hesitation to include it, as WSD also serves other purposes than just the detection of SMB services.

Fortunately, a guy named Steffen Christgau, has written an (interesting) Python 3 script, which offers you the basic WSD functionality. See https://github.com/christgau/wsdd.

You can use the script in form of a daemon process on a Linux system – hence we speak of WSDD.

Using YaST I quickly found out that a WSDD RPM package is actually included in my “Opensuse Leap 15.1 Update” repository. People with other Linux distros may download the present WSDD version from GitHub.

On Opensuse it comes with an associated systemd service-file which you find in the directory “/usr/lib/systemd/system”.

[Unit]
Description=Web Services Dynamic Discovery host daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
AmbientCapabilities=CAP_SYS_CHROOT
PermissionsStartOnly=true
Environment= WSDD_ARGS=-p
ExecStartPre=/usr/lib/wsdd/wsdd-init.sh
EnvironmentFile=-/run/sysconfig/wsdd
ExecStart=/usr/sbin/wsdd --shortlog -c /run/wsdd $WSDD_ARGS
ExecStartPost=/usr/bin/rm /run/
sysconfig/wsdd
User=wsdd
Group=wsdd

[Install]
WantedBy=multi-user.target

Reading the documentation you find out that the daemon runs chrooted – which is a reasonable security measure.
Opensuse even provides an elementary configuration file in “/etc/sysconfig/wsdd“.

I used the parameter

WSDD_WORKGROUP=”MYWORKGROUP”

there to announce the right Workgroup for my (virtualized) Samba server.

So, I had everything ready to start WSDD by “rcwsdd start” (or by “systemctl start wsdd.service”) on my Samba server.

On the local firewall of the SMB server I opened

port 445 (TCP) for SMB(3) In/Out for the server and from/to the Win-10-Client,
port 3702 (UDP) for incoming packets to the server and outgoing packets from the server to the Multicast address 239.255.255.250,
port 5357 (TCP) In/Out for the server and from/to the Win 10 client.

And: I closed all NetBIOS ports (UDP 137, 138 / TCP 139) and eventually stopped the “nmbd”-service on the Samba server! (UDP 137, 138 / TCP 139)

Within a second or so, my Samba 4 server appeared in the Windows 10 Explorer!

Further hints:
As the 3702 port is used with the UDP protocol it should be regarded as potentially dangerous. See: https://blogs.akamai.com/sitr/2019/09/new-ddos-vector-observed-in-the-wild-wsd-attacks-hitting-35gbps.html
The port 1900 which appeared in the firewall logs does not seem to be important. I blocked it.

So far, so good. However, when I refreshed the list in the Win 10 Explorer my SAMBA server disappeared again. 🙁

What you should do: Take special care about the network interface to which the WSDD service gets attached to

It took me a while to find out that the origin of the last problem had to do with the fact that my virtualized server and my Win 10 client both had multiple network interfaces on virtualized bridges. There are no loops in the configuration, but it occurred that multiple broadcasts packets arrive via different paths at the Samba server and were answered – and thus multiple return messages appeared at the Win 10 client during a refresh – which Win 10 did not like (see the discussion in the following link.
https://github.com/christgau/wsdd/issues/8

As soon as I restricted the answer of the Samba server to exactly one of the interfaces on my virtual bridge via the the parameter “WSDD_INTERFACES” in the “/etc/sysconfig/wsdd”-configuration file everything went fine. Refreshes now lead to an immediate update including the Samba server.

So, be a little careful, when you have some complicated bridge structures associated with your virtualized VMware or KVM guests. The WSDD service should be limited to exactly one interface of the Samba server.

Note: As we do not need NetBIOS any longer – block ports 137, 138 (UDP) and 139 (TCP) in your firewalls! It will make you feel better instantaneously.

Conclusion

The “end” of SMB V1 on Win 10 is a reasonable step. However, it undermines the visibility of Samba servers in the Windows Explorers. The reason is that NetBIOS requires SMB1.0 features on Windows. NetBIOS is/was therefore consistently deactivated on Win 10, too. The service detection on the network is replaced by the WSD service which was originally introduced for printer detection (and possibly other devices). Activating it on the Win 10 system may help with the detection of other Windows (8 and 10) systems on the network, but not with Samba 4 servers. Samba servers presently only serve NetBIOS requests of Win clients
to allow for server and share detection. Therefore, without additional measures, they are not displayed in the Windows Explorer of a regular Win 10 client.

This does, however, not restrict the usage of Samba shares on the Win 10 client via the SMB3 protocol. They can be used as “network drives” – just as before. Not distributing name and device information on a network has its advantages regarding security.

If you absolutely must see your Samba servers in the Win 10 Explorer install and configure the WSDD package of Steffen Christgau. You can use it as a systemd service. You should restrict the interfaces WSDD gets attached to – especially if your Samba servers are attached to virtual network bridges (Linux bridges or VMware bridges).

So:

Disable SMBV1 in Windows 10 if an update has not yet done it for you!
Set the protocol in the Samba servers to SMBV3!
Try to work with “networks drives” on your Win 10 guests, only!
Install, configure and use WSDD, if you really need to see your Samba servers in the Windows Explorer.
Open the port 445 (TCP, IN/OUT between the Win 10 client and the server), 3072 (UDP, OUT from the server and the Win 10 client to 239.255.255.250, IN to the server from the Win 10 client / IN to the Win 10 client from the server; rules details depending on the firewall location), port 5357 (TCP; In/OUT between the Samba server and the Win 10 client) on your firewalls between the Samba server and the Win 10 system.
Close the NetBIOS ports in your firewalls!
You should also take care of stopping multicast messages leaving perimeter firewalls; normally packets to multicast addresses should not be routed, but blocking them explicitly for certain interfaces is no harm, either.

Of course you must repeat the WSDD and firewall setup for all your Samba servers. But as a Linux admin you have your tools for distributing common configuration files or copying virtualization setups.