Bug 418417

Summary:	KIO should poll NT1/SMB1 browse masters to discover workgroup hosts
Product:	[Frameworks and Libraries] kio-extras	Reporter:	Jason Straight <j.straight-kde>
Component:	Samba	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	a.samirh78, j.straight-kde, kdelibs-bugs, sitter
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Jason Straight 2020-03-02 22:40:53 UTC

I saw another post about this on phabricator, but nothing here.

https://phabricator.kde.org/D18878

I know that WSD discovery is coming for SMB2/3, but we're still going to have broken SMB1, and I think it shouldn't be neglected, as there are still so many devices that force admins to support SMB1, such as NAS, printers (or MFC's), etc., and if you roam between networks that support 1 vs 2/3 then you've got to change your smb.conf file all the time.

My suggestion is that kio attempts to poll browse masters with SMB1 if the min proto is set to NT1, as opposed to how it now only does it if max proto is set to NT1.

On the phabricator discussion, it a point was made that falling back to NT1 was not preferable if it overrode the system admin's settings and introduced possible insecurities of SMB1.

If the min proto is explicitly set to NT1, then that shouldn't be an issue. Furthermore, that argument is moot anyway, considering a user can create a ~/.smb/smb.conf file which overrides the system-wide /etc/smb/smb.conf configuration.

Thanks.

Comment 1 Harald Sitter 2020-03-13 11:51:26 UTC

Obligatory stop using smb1: https://techcommunity.microsoft.com/t5/storage-at-microsoft/stop-using-smb1/ba-p/425858

With that out of the way your suggestions isn't entirely unreasonable but KIO doesn't make the browsing decision, that's libsmbclient. So, I think you'll want to file a bug in the samba bugzilla to get the behavior changed. I would think there's a reason they've made it attach to maximum though, so perhaps there's a good explanation.

On a side note: just because legacy equipment doesn't support wsdiscovery/dnssd doesn't mean you cannot expose it via those systems.
Any host can act as a publisher for another host, for example any cheapo ARM board would do the trick by making a bunch of services publishing the relevant data on wsd/dnssd

e.g. with avahai
> avahi-publish -a blackbox.local 192.168.100.206
> avahi-publish -s -H blackbox.local SMB_ON_BLACKBOX _smb._tcp 445 

and/or with https://github.com/christgau/wsdd
> wsdd.py -v -n BLACKBOX # (in this case the name must be the actual netbios/llmnr name of the host; or you need to use a literal ip address as name)