smb: use prettyname.kio-discovery-wsd for hostname of wsdiscoveries
ClosedPublic

Authored by sitter on Apr 2 2020, 12:18 PM.

Details

Summary

previously we simply used the ip address. this is fairly awkward though.
instead try to deduce a resolvable host name from the pretty name.

at discovery time we now mark wsdiscovieres for special handling

at listDir time we then attempt to resolve the name.local and if that
fails strip the .local to get the presumed LLMNR/netbios name. this means
the (first) listDir may be slower while we try to find a working hostname
but discovery is still as fast as possible.

Test Plan

wsdd on linux server resolves as expected, wsd on win10 also resolves as expected

Diff Detail

Repository
R320 KIO Extras
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
sitter created this revision.Apr 2 2020, 12:18 PM
Restricted Application added projects: Dolphin, Frameworks. · View Herald TranscriptApr 2 2020, 12:18 PM
Restricted Application added subscribers: kfm-devel, kde-frameworks-devel. · View Herald Transcript
sitter requested review of this revision.Apr 2 2020, 12:18 PM

Competes with D27902
While this diff runs the risk of not being able to resolve 100% of the time (sans ip address fallback in listDir) it has the huge advantage that discovery isn't getting super slow when multiple wsd hosts are found and consequently need costly host resolution performed. So, I like this diff muuuuch better.

ngraham accepted this revision.Apr 2 2020, 2:44 PM

I like this much better too!

Stable branch?

This revision is now accepted and ready to land.Apr 2 2020, 2:44 PM

Stable was the plan, yes.

I've thought of some complications with this approach though. Actually a combination of two

  1. the .local match also applies to dnssd
  2. all linux VMs I've checked wouldn't be able to resolve netbios names natively as the relevant modules are simply not loaded by default. meaning the netbios fallback will never be hit because 'foo' cannot ever be resolved (well, unless the user manually enables nmbd or lllmnr resolution)

to mitigate 2 we could just always fall back to netbios regardless of its resolvability, but that has the problem that we can then discover DNSSD services on bar.local have that fall back to bar and somewhat unexpected report that 'bar' was not resolvable (when in fact the intended and wanted resolution is bar.local for the DNSSD scenario). I'm not sure it's a huge problem, but it certainly irks me a bit because very practically libsmbc's resolution may be way more flexible than the regular libc/nss resolution.

OTOH fixing both would require yet more URL hackery to carry more context from the discovery into the list call. by either making the hostname foo.kio-discovery-wsd instead of foo.local or putting the discovery method into a query smb://foo?kio-discovery=wsd. I find both a bit meh. but then dnssd can be entirely unaffected by any of this

sitter retitled this revision from smb: use prettyname.local for hostname of wsdiscoveries to smb: use prettyname.kio-discovery-wsd for hostname of wsdiscoveries.Apr 3 2020, 2:03 PM
sitter edited the summary of this revision. (Show Details)
sitter updated this revision to Diff 79220.Apr 3 2020, 2:05 PM

reshuffle: instead of using .local directly use a fake .kio-disocvery-wsd suffix. look for that at listing time and redirect to name.local or name as appropriate

this prevents dnssd results form incorrectly getting run through the query branch AND has a 100% fallback chance for the llmnr/netbios name if the dnssd name isn't resolvable for wsdiscoveries

kossebau added inline comments.
smb/kio_smb_browse.cpp
239

QString::remove() operates on the object itself, no need to assign back to host.

Besides, why not use QString::chop(wsdSuffix.size()) ?

sitter added inline comments.Apr 3 2020, 4:10 PM
smb/kio_smb_browse.cpp
239

Mh. Good point indeed, I'll move to chop. Thanks!

sitter updated this revision to Diff 79234.Apr 3 2020, 5:06 PM

chop instead of convoluted remove

meven accepted this revision.Apr 4 2020, 10:10 AM

Seems good to me

This revision was automatically updated to reflect the committed changes.