Autodetection of network shares

[kallisti5]

Currently, if you mount an NFS device, it goes into the BVolumeRoster with a "IsShared" == true setting. This results in the share showing up in the tracker menu with the other devices.

It would be an interesting feature to automatically detect shared volumes on the network and auto load them into BVolumeRoster (unmounted)

​https://en.wikipedia.org/wiki/Zero-configuration_networking#Apple_Bonjour ​https://en.wikipedia.org/wiki/Zero-configuration_networking#Avahi

The not well known mount_nfs command results in not many users realizing we support NFS shares.

[pulkomandy]

I never heard of zeroconf being used with NFS. The protocols allow it, but if no shares are advertised this way, the list will never get any entries.

Or, do you know of another way to discover available NFS shares? Hint: port-scanning random IP addresses is not the way to go.

However, Tracker integration or some UI to mount network drives (it could be in mount preferences, or network prefs, or something yet separate), would be nice. Not sure we can do away with asking the user for the server and share names, however.

[kallisti5]

Bonjour supports _nfs._tcp. Complete list here: ​https://developer.apple.com/library/content/qa/qa1312/_index.html

I wrote a tiny SSDP library, but as you said upnp doesn't (normally) do nfs.

libmicrossdp :( $ ./a.out 
Discovered 13 devices:
	'urn:schemas-upnp-org:device:Printer:1' - 'http://192.168.1.144:5200/Printer.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'
	'239.255.255.250:1900' - 'http://192.168.1.136:80/description.xml'

Unfortunately everyone has their own "standard" and consensus of something so fundamental was never reached. Anything we do in terms of automatic location of local network resources will likely need to be an aggregation of multiple inputs.

• nfs - Bonjour / mDNS
• iscsi - iSCSI Discovery

[kallisti5]

​https://github.com/mjansson/mdns is a nice minimal mDNS (header-only) library which is public domain.

 ./mdns_example 
Local IPv4 address: 192.168.1.100
Local IPv6 address: fe80::df4f:8f26:811e:83e4%enp6s0
Opened 2 sockets for DNS-SD
Sending DNS-SD discovery
Reading DNS-SD replies
[fe80::211:32ff:fe25:3bb1%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _smb._tcp.local. rclass 0x1 ttl 10 length 12
[fe80::211:32ff:fe25:3bb1%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _ftp._tcp.local. rclass 0x1 ttl 10 length 7
[fe80::211:32ff:fe25:3bb1%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _http._tcp.local. rclass 0x1 ttl 10 length 8
[fe80::211:32ff:fe25:3bb1%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _afpovertcp._tcp.local. rclass 0x1 ttl 10 length 14
[fe80::211:32ff:fe25:3bb1%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _device-info._tcp.local. rclass 0x1 ttl 10 length 15
192.168.1.10:5353 : answer _services._dns-sd._udp.local. PTR _smb._tcp.local. rclass 0x1 ttl 10 length 12
192.168.1.10:5353 : answer _services._dns-sd._udp.local. PTR _ftp._tcp.local. rclass 0x1 ttl 10 length 7
192.168.1.10:5353 : answer _services._dns-sd._udp.local. PTR _http._tcp.local. rclass 0x1 ttl 10 length 8
192.168.1.10:5353 : answer _services._dns-sd._udp.local. PTR _afpovertcp._tcp.local. rclass 0x1 ttl 10 length 14
192.168.1.10:5353 : answer _services._dns-sd._udp.local. PTR _device-info._tcp.local. rclass 0x1 ttl 10 length 15
192.168.1.191:5353 : answer _services._dns-sd._udp.local. PTR _airplay._tcp.local. rclass 0x1 ttl 10 length 16
192.168.1.191:5353 : answer _services._dns-sd._udp.local. PTR _raop._tcp.local. rclass 0x1 ttl 10 length 8
192.168.1.229:5353 : answer _services._dns-sd._udp.local. PTR _airplay._tcp.local. rclass 0x1 ttl 10 length 16
192.168.1.153:5353 : answer _services._dns-sd._udp.local. PTR _spotify-connect._tcp.local. rclass 0x1 ttl 10 length 24
192.168.1.153:5353 : answer _services._dns-sd._udp.local. PTR _airplay._tcp.local. rclass 0x1 ttl 10 length 11
192.168.1.143:5353 : answer _services._dns-sd._udp.local. PTR _http._tcp.local. rclass 0x1 ttl 10 length 13
192.168.1.143:5353 : answer _services._dns-sd._udp.local. PTR _ipp._tcp.local. rclass 0x1 ttl 10 length 7
192.168.1.143:5353 : answer _services._dns-sd._udp.local. PTR _pdl-datastream._tcp.local. rclass 0x1 ttl 10 length 18
192.168.1.143:5353 : answer _services._dns-sd._udp.local. PTR _printer._tcp.local. rclass 0x1 ttl 10 length 11
[fe80::9e93:4eff:fe39:e027%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _http._tcp.local. rclass 0x1 ttl 10 length 13
[fe80::9e93:4eff:fe39:e027%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _ipp._tcp.local. rclass 0x1 ttl 10 length 7
[fe80::9e93:4eff:fe39:e027%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _pdl-datastream._tcp.local. rclass 0x1 ttl 10 length 18
[fe80::9e93:4eff:fe39:e027%enp6s0]:5353 : answer _services._dns-sd._udp.local. PTR _printer._tcp.local. rclass 0x1 ttl 10 length 11
192.168.1.187:5353 : answer _services._dns-sd._udp.local. PTR _ssh._tcp.local. rclass 0x1 ttl 10 length 12
192.168.1.187:5353 : answer _services._dns-sd._udp.local. PTR _sftp-ssh._tcp.local. rclass 0x1 ttl 10 length 12
192.168.1.187:5353 : answer _services._dns-sd._udp.local. PTR _workstation._tcp.local. rclass 0x1 ttl 10 length 15
192.168.1.226:5353 : answer _services._dns-sd._udp.local. PTR _m2m._tcp.local. rclass 0x1 ttl 255 length 17

If we had some network tracker interface, this would be a really interesting platform-agnostic way to connect to local services on the network.

Looking in the example above, Haiku could show multiple web servers, ssh servers, printers, in Tracker. We could open _http._tcp.local devices as ​http://... in WebPositive, _ssh._tcp.local in a terminal SSH session, etc.

[kallisti5]

hm.. maybe an mdns filesystem with attributes tracker will pickup on?

[nephele]

I never heard of zeroconf being used with NFS. The protocols allow it, but if no shares are advertised this way, the list will never get any entries.

I think probono from helloSystem might be able to give us some info here. helloSystem implemented autodiscover of ssh/http/nfs and such already iirc.