[Feature Request] Nextcloud servers and clients should support Zeroconf (a.k.a. "Bonjour")

pdfkungfoo · June 9, 2016, 9:57am

Feature Proposal: Zeroconf

Nextcloud servers and clients should support “Zeroconf”, the technology concept which crystallized as and is layed down in the DNS-SD/rfc6763 (DNS Service Discovery) and mDNS/rfc6762 (Multicast DNS) documents published by the Internet Engineering Task Force (IETF).

Zeroconf-/Avahi-/Bonjour-enabled devices and clients could then be able to auto-discover all Nextcloud services in their neighbourhood which are willing to share something. Nextcloud servers would announce their services by the same means.

Nextcloud Zeroconf Use Cases

Kurt wants to offer a mini-~~own~~NextCloud server which is open for his housemates, all visitors and everybody who is in reach of his WLAN. He wants them to be able to auto-discover his ~~own~~NextCloud service and connect to it without them needing to ask for an IP address. His visitors just come and start their Nextcloud clients to discover kurtsCloud.
Jos is on a conference hopping trip around the world giving talks and demos. At the start of the “live demo” part of his presentation about the newest and coolest, yet unreleased features of Nextcloud, he just plugs in a Raspberry Pi 3 with Nextcloud installed. Then he asks his audience to start their Nextcloud clients to auto-discover his Raspbi-driven Nextcloud instance and they can easily connect to it without knowing more.
Niels is on a business trip to demonstrate a new hardware product with built-in Nextcloud server support to potential customers. Most of his audience have Nextcloud clients installed on their iOS and Android mobiles already, because he had suggested this to them beforehand. After starting their Nextcloud clients they can immediately “see” the hardware’s Nextcloud server instance (which is already switched on) and can connect to its Nextcloud server with a single click.
Frank looks for a new job and is invited for an interview. While waiting in the company’s HQ lobby for his HR contact person to turn up, he (of course) plays with his tablet and has his Nextcloud client open. To his surprise he discovers that the prospect employer runs a Nextcloud instance sharing interesting documents and videos which all visitors and prospective new employees can easily see.
Olivier sits at an airport lobby and wants to connect to the Nextcloud server run by his company from his iPad. From an email two days ago he vaguely remembers that the hostname and IP address had to be changed due to an upgrade, but he forgot the details. However, he remembered that it had mentioned something like: “add our domain name to ‘search domain’ and it will work with your mobile clients”. So he goes to “Settings -> WLAN” and simply adds mycompany.com into the ‘Search Domain’ field. His Nextcloud iOS client can now easily find and connect to the new Nextcloud server even though his DHCP-delivered IP address and current domain from the airport hotspot belongs to T-mobile… (The same is true for Olivier’s Safari browser on his MacBook.)

(Preliminary end of user stories – sorry, no gender proportionality so far.)

Zeroconf Technology Usage Elsewhere

In the last 10 years DNS-SD/mDNS-based Zeroconf support has experienced a wide adoption across all fields of IT technology. I wonder why ownCloud has not yet made use of it:

If you are not yet familiar with DNS-SD and mDNS: this is what Apple uses in its technology marketed as “Bonjour”.
This is what CUPS uses for seamless sharing of (shared) printers, which lets all CUPS clients “just print” without needing to install a “driver”…
This is what Apple’s AirPrint technology uses behind the scenes to achieve seamless printing from iOS devices to all AirPrint-enabled printers…
This is what Apple’s AirPlay uses for sharing iTunes music…
This is what Kodi uses to become an AirPlay target and let Windows, Linux and Mac clients stream AirPlay content to a Kodi instance…
This is what’s behind Avahi on Linux to support Bonjour-like functionality on our preferred OS platform…
There are numerous examples now to be found in real life around you – too numerous to list them all…

_{(BTW, Wide-Area Zeroconf is also supported: your DNS Admin just needs to insert a few service resource records (RR) into the DNS server’s zone file for all Zeroconf-aware clients to discover the services offered. You can see how this works if you simply add dns-sd.org as a “browse domain” into the DNS configuration dialog of your iPad or iPhone. The dns-sd.org domain’s DNS server will announce a few (fake) services for anybody who is interested to test his DNS-SD client code:}

_{The respective clients will then be able to see a few (fake) services, like “Stuart’s Home AirPrint Printer” or “Stuart’s Cube” in their environment.)}

oparoz · June 9, 2016, 11:56am

That’s what the ownCloud snap is using, but it isn’t working very well and the URL is not recognized by browsers.

pdfkungfoo · June 9, 2016, 12:05pm

This comment expands on my feature request from above and gives you and your developers a few hints about where to start.

Discover currently available Zeroconf-enabled services

You can easily discover all currently available Zeroconf-enabled services in your neighbourhood. For this, command-line tools as well as GUI apps are available.

Command line tools

Here are a few command line examples which will let you discover DNS-SD/mDNS service announcements travel through the network which you currently are connected to:

Using the standard command line tool `dig`

You can use the following commands on any platform which supports dig.

Host name resolution without central DNS server:

Simply resolve IP addresses for hostnames you happen to know – but without knowing the central DNS server’s IP address (or while the DNS server is not available) – by using an mDNS query:

  $ dig -p 5353 @224.0.0.251 hostname.local.

mDNS is using port 5353 and the multicast address 224.0.0.251 for its queries and its announcements, which are, with about 99% match, just standard DNS packets.

The last commands could return the following output:

  ; <<>> DiG 9.8.3-P1 <<>> -p 5353 @224.0.0.251 hostname.local.
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28705
  ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;hostname.local.		IN	A
  
  ;; ANSWER SECTION:
  hostname.local.	10	IN	A	192.168.177.24
  
  ;; Query time: 78 msec
  ;; SERVER: 192.168.177.24#5353(224.0.0.251)
  ;; WHEN: Thu Jun  9 10:51:34 2016
  ;; MSG SIZE  rcvd: 50

Or, asking for a less verbose output:

  $ dig +nocmd -p 5353 @224.0.0.251 hostname.local. +noall +answer

  hostname.local.	600	IN	A	192.168.177.24

Service Discovery on Remote Domain

Asking for info about all (fake) services which the (remote) domain dns-sd.org has on offer:

 $ dig +nocmd -t PTR _services._dns-sd._udp.dns-sd.org. +noall +answer
    
    _services._dns-sd._udp.dns-sd.org. 59 IN PTR	_afpovertcp._tcp.dns-sd.org.
    _services._dns-sd._udp.dns-sd.org. 59 IN PTR	_pdl-datastream._tcp.dns-sd.org.
    _services._dns-sd._udp.dns-sd.org. 59 IN PTR	_ftp._tcp.dns-sd.org.
    _services._dns-sd._udp.dns-sd.org. 59 IN PTR	_ipp._tcp.dns-sd.org.
    _services._dns-sd._udp.dns-sd.org. 59 IN PTR	_ssh._tcp.dns-sd.org.
    _services._dns-sd._udp.dns-sd.org. 59 IN PTR	_http._tcp.dns-sd.org.
    _services._dns-sd._udp.dns-sd.org. 59 IN PTR	_printer._tcp.dns-sd.org.

They offer Apple File Sharing (indicated by _afpovertcp) as well as Printing via JetDirect/Port9100 (indicated by _pdl-datastream), File Transfer Protocol (_ftp), Internet Printing Protocol (_ipp), Secure Shell (_ssh), a Web Server (_http) and a legacy Port 515 LPR/LPD Printer (_printer).

AirPrint Printer Discovery for Remote Domain

Enumerate all AirPrint printers available at (remote) domain dns-sd.org:

 $ dig +nocmd -t ANY _universal._sub._ipp._tcp.dns-sd.org. +noall +answer
   
    _universal._sub._ipp._tcp.dns-sd.org. 59 IN PTR Stuart's\032Home\032AirPrint\032Printer._ipp._tcp.dns-sd.org.

IPP Printer Discovery for Remote Domain

Enumerate all IPP printers (includes, of course, AirPrint printers) at dns-sd.org:

 $ dig +nocmd -t ANY _ipp._tcp.dns-sd.org. +noall +answer
    
    _ipp._tcp.dns-sd.org.   59  IN  PTR Sales._ipp._tcp.dns-sd.org.
    _ipp._tcp.dns-sd.org.   59  IN  PTR Marketing._ipp._tcp.dns-sd.org.
    _ipp._tcp.dns-sd.org.   59  IN  PTR Engineering._ipp._tcp.dns-sd.org.
    _ipp._tcp.dns-sd.org.   59  IN  PTR 3rd\.\032Floor\032Copy\032Room._ipp._tcp.dns-sd.org.
    _ipp._tcp.dns-sd.org.   59  IN  PTR Stuart's\032Home\032AirPrint\032Printer._ipp._tcp.dns-sd.org.

Using the `dns-sd` command

The following commands work only on a Mac (or any platform, including Windows and Linux, where you have self-compiled Apple’s open source Bonjour SDK).

General Service Discovery on Local Network

Check for all types of services which are available to my notebook in my current network environment:

 $ dns-sd  -B _services._dns-sd._udp  local.

 Browsing for _services._dns-sd._udp.local.
 DATE: ---Thu 09 Jun 2016---
 11:45:23.751  ...STARTING...
 Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
 11:45:23.752  Add        3   4 .                    _tcp.local.          _ssh
 11:45:23.752  Add        3   4 .                    _tcp.local.          _sftp-ssh
 11:45:23.752  Add        3   4 .                    _tcp.local.          _atc
 11:45:23.752  Add        3   4 .                    _tcp.local.          _daap
 11:45:23.752  Add        3   4 .                    _tcp.local.          _smb
 11:45:23.752  Add        3   4 .                    _tcp.local.          _googlecast
 11:45:23.752  Add        3   4 .                    _tcp.local.          _ipp
 11:45:23.752  Add        3   4 .                    _tcp.local.          _ipps
 11:45:23.752  Add        3   4 .                    _tcp.local.          _afpovertcp
 11:45:23.752  Add        3   4 .                    _tcp.local.          _testlargetxt
 11:45:23.752  Add        3   4 local.               _apple-mobdev2._tcp. _sub
 11:45:23.752  Add        3   4 .                    _tcp.local.          _ipp
 11:45:23.752  Add        3   4 .                    _tcp.local.          _ipps
 11:45:23.752  Add        3   4 .                    _tcp.local.          _testtxt
 11:45:23.752  Add        3   4 .                    _tcp.local.          _testdualtxt
 11:45:23.752  Add        3   4 .                    _udp.local.          _net-assistant
 11:45:23.752  Add        3   4 .                    _tcp.local.          _nomachine
 11:45:23.752  Add        3   4 .                    _tcp.local.          _http
 11:45:23.752  Add        3   4 .                    _tcp.local.          _ipp
 11:45:23.752  Add        3   4 .                    _tcp.local.          _rfb
 11:45:23.752  Add        3   4 .                    _tcp.local.          _raop
 11:45:23.752  Add        3   4 .                    _tcp.local.          _apple-mobdev2
 11:45:23.752  Add        3   4 .                    _tcp.local.          _airplay
 11:45:23.752  Add        3   4 .                    _tcp.local.          _workstation
 11:45:23.752  Add        3   4 .                    _tcp.local.          _eppc
 11:45:23.752  Add        3   4 .                    _tcp.local.          _testupdate
 11:45:23.752  Add        3   4 .                    _tcp.local.          _udisks-ssh
 11:45:23.752  Add        2   4 .                    _tcp.local.          _amzn-wplay
 ^C

Amazing, isn’t it ?!?

All these other notebooks, workstations, IoT devices, iPhones, iPads and Android phones and tablets in my neighbourhood seem to be sharing their info about services available for them rather liberally… (But disappointing: no ownCloud or Nextcloud in sight…)

IPP Printer Discovery on Remote Domain

Searching for all IPP-enabled printers in domain dns-sd.org (using -B for “browse”):

 $ dns-sd  -B _ipp._tcp  dns-sd.org.
    
    Browsing for _ipp._tcp.dns-sd.org.
    DATE: ---Tue 17 May 2016---
    17:40:30.998  ...STARTING...
    Timestamp     A/R  Flags  if Domain        Service Type  Instance Name
    17:40:30.998  Add      3   0 dns-sd.org.   _ipp._tcp.    Stuart's Home AirPrint Printer
    17:40:30.998  Add      3   0 dns-sd.org.   _ipp._tcp.    Sales
    17:40:30.998  Add      3   0 dns-sd.org.   _ipp._tcp.    Marketing
    17:40:30.998  Add      3   0 dns-sd.org.   _ipp._tcp.    Engineering
    17:40:30.998  Add      2   0 dns-sd.org.   _ipp._tcp.    3rd. Floor Copy Room
    ^C

Look up and retrieve all info about a specific service instance which was previously discovered (using -L for “lookup”:

 $ dns-sd  -L "Stuart's Home AirPrint Printer"  _ipp._tcp  dns-sd.org.

    Lookup Stuart's Home AirPrint Printer._ipp._tcp.dns-sd.org.
    DATE: ---Tue 17 May 2016---
    17:45:22.284  ...STARTING...
    17:45:22.737  Stuart's\032Home\032AirPrint\032Printer._ipp._tcp.dns-sd.org. can be reached at airprint.dns-sd.org.:631 (interface 0)
     txtvers=1 qtotal=1 pdl=application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf rp=ipp/printer \
      URF=CP99,W8,OB10,PQ3-4-5,ADOBERGB24,DEVRGB24,DEVW8,SRGB24,IS1-2-4,MT1-2-3-5-12,MT1-2-3-5-12,RS600 ty=HP\ LaserJet\ 400\ color\ M451nw \
      Color=T Duplex=F Scan=F product=\(HP\ LaserJet\ 400\ color\ M451nw\) priority=10 adminurl=http://www.dns-sd.org/ServerStaticSetup.html \
      note=At\ Stuart\'s\ house
    ^C

Using the `avahi-browse` command line tool

The following commands should work on any Linux system with Avahi packages installed.

Browse for all locally available services of all types

This will give a similar result as the previously shown command dns-sd -B _services._dns-sd._udp local. for Mac OS X:

 $ avahi-browse _services._dns-sd._udp. -t

 + wlan1 IPv4 _amzn-wplay                        _tcp                 local
 + wlan1 IPv4 _sftp-ssh                          _tcp                 local
 + wlan1 IPv4 _atc                               _tcp                 local
 + wlan1 IPv4 _daap                              _tcp                 local
 + wlan1 IPv4 _ssh                               _tcp                 local
 + wlan1 IPv4 _apple-mobdev2                     _tcp                 local
 + wlan1 IPv4 _udisks-ssh                        _tcp                 local
 + wlan1 IPv4 _testupdate                        _tcp                 local
 + wlan1 IPv4 _eppc                              _tcp                 local
 + wlan1 IPv4 _airplay                           _tcp                 local
 + wlan1 IPv4 _raop                              _tcp                 local
 + wlan1 IPv4 _rfb                               _tcp                 local
 + wlan1 IPv4 _ipp                               _tcp                 bonjour.muada.nl
 + wlan1 IPv4 _http                              _tcp                 local
 + wlan1 IPv4 _nomachine                         _tcp                 local
 + wlan1 IPv4 _net-assistant                     _udp                 local
 + wlan1 IPv4 _testdualtxt                       _tcp                 local
 + wlan1 IPv4 _testtxt                           _tcp                 local
 + wlan1 IPv4 _ipps                              _tcp                 bonjour.muada.nl
 + wlan1 IPv4 _ipp                               _tcp                 local
 + wlan1 IPv4 _sub                               _apple-mobdev2._tcp  local
 + wlan1 IPv4 _testlargetxt                      _tcp                 local
 + wlan1 IPv4 _afpovertcp                        _tcp                 local
 + wlan1 IPv4 _ipps                              _tcp                 local
 + wlan1 IPv4 _ipp                               _tcp                 dns-sd.org
 + wlan1 IPv4 _googlecast                        _tcp                 local
 + wlan1 IPv4 _smb                               _tcp                 local
 + wlan1 IPv4 _workstation                       _tcp                 local

You should be easily figuring out how to modify the avahi-browse command to query specific local or remote (like provided on dns-sd.org) Zeroconf-enabled services.

GUI tools

Mac OS X: Bonjour Browser

For Mac, there is the no-cost GUI tool Bonjour Browser by Kevin Ballard available for download here:

Homepage www.tildesoft.com
Download http://www.tildesoft.com/files/BonjourBrowser.dmg

It is rather old, but still works. At my current location, it displays this result in its very simple interface:

"Bonjour Browser" window displaying discovered services

Linux: avahi-discover

For Linux, there is the GUI app avahi-discover. It will display a similar simple interfaces as the above Bonjour Browser tool. Note, how clicking on a particular service instance will display all its TXT record contents in the lower window pane:

"avahi-discover" window displaying discovered services

Android, iOS

I’ve found an App named “Bonjour Browser” in Google’s Play Store too: https://play.google.com/store/apps/details?id=com.grokkt.android.bonjour&hl=de. There are probably more available.
Same for Apple’s AppStore or iTunesStore: https://itunes.apple.com/de/app/discovery-bonjour-browser/id305441017?mt=8

How Zeroconf Works

Zeroconf combines mainly two networking protocol “standards” which have been layed down in a few IETF RFC documents:

DNS-SD (DNS-based Service Discovery) as described in RFC6763 at http://www.ietf.org/rfc/rfc6763.txt
mDNS (Multicast-based Domain Name Services) as described in RFC6762 at http://www.ietf.org/rfc/rfc6762.txt and RFC6761 at http://www.ietf.org/rfc/rfc6761.txt.

DNS Service Discovery works via multicast announcements and queries. The details about the exact protocol to be used (like using TCP/UDP port 5353, or addressing the reserved multicast IP address 224.0.0.251 and more) are defined as “mDNS”.

DNS-SD uses existing DNS record types to store, hold and cache specific information about services: SRV, TXT and PTR records. Thus, DNS-SD packets sent on the network are very similar to “standard” DNS packets. Therefor also, all standard DNS servers can be used to hold and deliver on request of clients all DNS-SD related information pieces.

Clients only have to be taught how to ask for specifics about a particular service type by knowing its name. More “complicated” services may use a number of (proprietary) TXT records which relate specific info to clients who know how to make use of them. Potential AirPrint clients for example are looking all IPP print services first, then for two specific TXT records to be present in their announcments: a pdl= field which contains the image/urf value, and the existence of an URF= field. If these two TXT records are present, an iPad will list this IPP printer as AirPrint capable. If further records like Duplex=T and Color=T are present, they will add duplex and color selection buttons to the print dialog user interface. The TXT record air=username,password tells the clients that they need username + password in order to use that AirPrint service.

Of course, Nextcloud developers need to come up with their own scheme of TXT records which they want to use for DNS-SD announcements via mDNS or standard wide area DNS, so clients are able to find and successfully connect to Nextcloud servers.

Developers who want to Zeroconf-enable their applications (or hardware devices) are recommended to, as a minimum, register a service type name directly through IANA. For ownCloud or Nextcloud these could be named as _owncloud and _nextcloud. You could even consider to register a preferred port number to be used. (Of course, you could even implement this functionality without registering a name, as long as Nextcloud servers and clients both know how to call each other, but this would be rather bad netizenship…)

Further Resources

Website of zeroconf.org: www.zeroconf.org
Website of mdns.org: www.mdns.org
Website of dns-sd.org: www.dns-sd.org
Stuart Cheshire’s Book about Zero Configuration Networking: O’Reilly Shop
Avahi website: www.avahi.org
Initial set of registered service names: www.dns-sd.org/ServiceTypes.html
Complete set of currently registered service names: www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

Difficult to discover sub-pages of the dns-sd.org main website (Isn’t it ironic?) – URLs here:

oparoz · June 9, 2016, 12:44pm

Very detailed and useful info, but most users use Windows and need to be able to easily find their devices, so we would need instructions for the main user base.

Also, that didn’t work for me from another box, trying to get the IP of the zeroconf device:

# dig -p 5353 @224.0.0.251 owncloud.local

; <<>> DiG 9.10.4-P1 <<>> -p 5353 @224.0.0.251 owncloud.local
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

So that’s not fool proof.

pdfkungfoo · June 9, 2016, 12:56pm

So that’s not fool proof.

So here’s more (hopefully) useful info…

Of course it’s not fool proof out of the box. However, it indeed becomes fool proof as soon as…

…your owncloud.local. device uses mDNS to publish its host name. This should be the case automatically if it is a Linux box running the avahi-daemon service.

Is this, or is this not the case?

Also note, that all my example commands using a domain name should be using a final dot in all the domain names, including “local.” (I don’t know why I forgot it in some commands, because I’m well aware that it could be very relevant; I’ll correct it.) See this web site for an explanation: “Trailing Dots in Domain Names”. You’ll probably also notice, how all DNS responses include the trailing dots in the domain names…

However, in your particular case, if your owncloud-named device used DNS-SD/mDNS for announcing its hostname, the dig command should have been tolerant and forgiving enough to be able to resolve owncloud.local as well as owncloud.local.

Even my old Windows test box is able to “resolve” the .local. TLD, as you can see from the following ping command:

 $ ping kp-w10-01.local.
  
  PING kp-w10-01.local. (192.168.177.21) 56(84) bytes of data.
  64 bytes from kp-w10-01.fritz.box (192.168.177.21): icmp_seq=1 ttl=128 time=108 ms
  64 bytes from kp-w10-01.fritz.box (192.168.177.21): icmp_seq=2 ttl=128 time=28.3 ms
  64 bytes from kp-w10-01.fritz.box (192.168.177.21): icmp_seq=3 ttl=128 time=50.7 ms
  ^C

The secret sauce behind that is that the box has iTunes installed. Which in turn includes Bonjour. Which in turn makes sure to announce iTune’s presences (and its sharing of podcasts) via DNS-SD. Which, as a side effect, also reveals the hostname, and that it should really be addressed as kp-w10-01.fritz.box instead of kp-w10-01.local.…

oparoz · June 9, 2016, 1:07pm

That’s the problem, the Snap is using mDNS and if I run the command locally, then I see the hostname and IP being listed, but not from a remote box. I know it works for some people, but ideally, it should work for everybody.

But anyway, I think the client could use that if it helps make suggestions and if there aren’t any, then some documentation could be provided to the user to try alternative techniques. The problem comes from the server. NC is not shipped as a VM, so it’s up to the user to install mDNS and configure it. What would really help is a how-to so that users installing NC at home without using the Snap can make it easy for clients to discover the box, as you’ve described in your posts.

pdfkungfoo · June 9, 2016, 2:56pm

To be very honest with you, I have not the slightest clue what “Snap” is. I’m also not familiar with current ownCloud 7, 8 or 9 features, since playing with it myself was quite some years ago. Furthermore, I’m not a developer/coder myself. So – I’m sorry to have to talk to you from the perspective of a total ownCloud/Nextcloud noob.

My only guess is that whatever is using mDNS and DNS-SD here is not using it correctly or completely.

This should/could be a starting point how to debug this further…

Yes. And I’m pretty sure, by implementing Zeroconf functionality with the help of Avahi on Linux and with the help of the FOSS Bonjour SDK by Apple (for Windows clients), it will. The effort shouldn’t be all too greate, the code to be written should be minimal.

Hell, I could even register and announce a fake ownCloud server on my local network by running the following command an Mac OS X:

 $ dns-sd                                       \
     -R "Public ownCloud Demo (Dummy Only)"     \
     _http._tcp.,_owncloud                      \
     .                                          \
     443                                        \
     txtvers=1                                  \
     qtotal=1                                   \
     ty="@pdfkungfoo's Own Handmade Model"      \
     note="@pdfkungfoo's flat"                  \
     note2="(totally dummy and fake device)"    \
     air="username,password"                    \
     kind="documents,chat,movies,music,contacts,calendar" \
     adminurl="mailto:pdfkungfoo@gmail.com"     \
     TLS=1.2                                    \
     UUID=533f7ac6-1c37-11e6-ac21-ffa8e4bdcbf9  \
     DUUID=12345678-9ABC-DEF0-1234-56789ABCDEF0 \
     Chat=F                                     \
     Documents=T                                \
     Movies=F                                   \
     Music=T                                    \
     Contacts=T                                 \
     Calendar=T

…or with the analog avahi-publish command on Linux:

 $ avahi-publish                                \
    -s "Public Nextcloud Demo 2 (Dummy Only)" _nextcloud._tcp.  443  \
    -H kp-w10-01.local.                          \
    -d local.                                    \
      txtvers=1                                  \
      qtotal=1                                   \
      ty="@pdfkungfoo's Own Handmade Model"      \
      note="@pdfkungfoo's flat"                  \
      note2="(totally dummy and fake device)"    \
      air="username,password"                    \
      kind="documents,chat,movies,music,contacts,calendar" \
      adminurl="mailto:pdfkungfoo@gmail.com"     \
      TLS=1.2                                    \
      UUID=533f7ac6-1c37-11e6-ac21-ffa8e4bdcbf9  \
      DUUID=12345678-9ABC-DEF0-1234-56789ABCDEF0 \
      Chat=F                                     \
      Documents=T                                \
      Movies=F                                   \
      Music=T                                    \
      Contacts=T                                 \
      Calendar=T

…and both service instances are happily displayed by my Bonjour Browser or by avahi-discover:

Fake Nextcloud service announcement for my LAN

However, there is no client (yet) which could make use of my announcement, and could interpret my (completely made-up) TXT records spicing my DNS-SD announcements.

On the other hand, I also could proxy-announce (with the help of an Avahi command) in my local network a remote ownCloud server existing in real life, so my local nodes could more easily find it:

 $ avahi-publish      \
    -s "The Real ownCloud Demo Server" _http._tcp.  80 \
    -H demo.owncloud.org \
    -d local.               \
      path="apps/gallery"

(To keep this announcement valid and alive for a longer time, just run it in the background.)

If I enable Bonjour in Internet Explorer or in Safari, then the ownCloud demo website server appears in the list of published HTTP resources, with the local descriptive name I’ve given to it in the announcement, and a single click connects the web client, directly going the path indicated by my path= TXT record:

Safari showing Avahi-published shortcut/bookmark pointing to ownCloud demo server

pdfkungfoo · June 9, 2016, 3:09pm

What do you mean by this? Which exact URL is published, and in what way? Is it via mDNS as a DNS-SD announcement? Could you elaborate, please?

Not all browsers are DNS-SD or Bonjour enabled (Safari is; Windows IE is said to be, once Bonjour is installed on Windows) – so even if the URL announcement is 100% correct and perfect, it may not be used.

However, if you Zeroconf-enable Nextcloud clients, at least these should be able to auto-discover available Nextcloud servers/resources…

oparoz · June 9, 2016, 3:26pm

I don’t blame you as it’s still a very young tech
http://www.ubuntu.com/internet-of-things

Could be. I’ll just post links to the set up if a dev wants to take a look at it

mDNS publisher which is using
Multicast DNS library for Go

The command looks like this, but that probably won’t tell you much since it’s using a custom made command.

# mdns-publisher owncloud

This results in the following entries

owncloud.local.         60      IN      A       1.2.3.4

And that’s the biggest culprit and probably the reason it doesn’t work. Users of Chrome on Windows per example can’t reach owncloud.local

Yep, that’s great for the clients, but for someone trying to set up their new NC box, it doesn’t work unless an app is shipped which finds all the boxes installed on the network. That’s what lots of networking and storage equipment vendors are providing.

pdfkungfoo · June 9, 2016, 5:16pm

Thanks for the info. I wasn’t aware of that so far.

Thanks. I’ll have a look sometime in July and see if I can make “heads and tails” from it…

Looks like a good A record to me… However: is the real host really using an IP address like this? Does the A record retrieved really match the device’s IP address?

I don’t have an ownCloud server here at the moment – but the Chrome browser on my Windows test box connects just fine to http://mycupsserver.local.:631/printers.

Internet Explorer connects to http://mycupsserver:631/printers after I added a “local.” entry to respective field for “Append these DNS suffixes (in order)” on the DNS configuration tab:

How to make sure that Windows makes use of the special domain.

The Nextcloud server itself should make sure that it its presence is announced (of course, this should be made easy to also switch off during the setup) via DNS-SD. Either via Bonjour or Avahi, or all by itself if it discovers no presence of a general Bonjour/Avahi service. (If it does it all by itself, it can limit its DNS-SD awareness to its own supported service types only.)

oparoz · June 9, 2016, 5:24pm

Yes, that was just an example and if I use the real IP as URL, I reach the box.

I suspect the problem is related to some firewall/router or network configuration issue, but this just highlights how different networks can be. I have no problem seeing the box in the network tab when enabling nmbd on it per example.

pdfkungfoo · June 9, 2016, 5:45pm

Let me get this right… So do I understand it correctly:

A dig command like

 $ dig +nocmd -p 5353 @224.0.0.251 owncloud.local. +noall +answer

returns this result:

owncloud.local. 60 IN A x.x.x.x

But you cannot connect to https://owncloud.local. or https://owncloud.local or http://owncloud.local. or http://owncloud.local even though there is an ownCloud server at IP address x.x.x.x on port 80 and/or on port 443?

However, you can connect to https://x.x.x.x or to https://x.x.x.x ?

Can you successfully run

ping owncloud.local.

?

oparoz · June 9, 2016, 5:56pm

The dig command only returns that result when run locally, so the box seems configured properly, but the rest of the network does not know what .local is.

Interestingly, when run on the box…

# ping owncloud.local.
ping: unknown host owncloud.local.

Netstat lists mDNS

udp        0      0 *:mdns                  *:*
udp        0      0 *:mdns                  *:*
udp6       0      0 [::]:mdns               [::]:*
udp6       0      0 [::]:mdns               [::]:*

pdfkungfoo · June 9, 2016, 6:07pm

I’m still confused. If you say “when run locally” I guess you mean when run on localhost? (Your “locally” does not refer to other nodes on the LAN?)

If the other nodes on the LAN cannot successfully run ping owncloud.local., then they have probably no Avahi daeman running. If they have, it should work. If it doesn’t, I’m at my wits’ end for now… (On Windows it should work if Apple’s Bonjour is installed and the “Bonjour Service” is running, or a process with the name mDNSResponder is listed. On Macs Bonjour is running out of the box, in the shape of a process named mDNSResponder.)

oparoz · June 9, 2016, 6:15pm

Yes, that means that I log in via SSH and type the commands.

I’ve checked and on Windows, I have 2 mDNSResponder services running

I’m going to check from a Linux box

pdfkungfoo · June 9, 2016, 6:15pm

IMHO, this does not yet mean there is really an mDNS service there. It means something is using port 5353 (the “well known” port used for mDNS).

Can you add -p -n for your (Linux) netstat command to see which process name binds to port 5353?

pdfkungfoo · June 9, 2016, 6:18pm

2 probably is 1 too many, if they are trying to wrestle both for listening access at port 5353.

oparoz · June 9, 2016, 6:38pm

It’s the correct app

udp        0      0 *:mdns                  *:*                                 10897/mdns-publishe
udp        0      0 *:mdns                  *:*                                 23100/mdns-publishe
udp6       0      0 [::]:mdns               [::]:*                              10897/mdns-publishe
udp6       0      0 [::]:mdns               [::]:*                              23100/mdns-publishe

Could be, but one of them is there to connect to a specific client.

I did a quick DLL search and quite a few apps are including the mdns dll, including browsers, so there shouldn’t be an issue.

I also tried from Ubuntu Xenial which is running avahi-daemon and dig couldn’t find owncloud.local.

pdfkungfoo · June 9, 2016, 9:04pm

Ok, I’m at my wits’ end then while doing a dry-run debugging of this problem from a remote place.

Without access to the live thing itself, inside the respective environment, with my fingers on a network sniffer like Wireshark or tcpdump I have no real idea how to proceed further from here.

This debugging topic wasn’t the appropriate thing for this feature request thread anyway, and I’m sorry to have made it happen here and today.

Hopefully it doesn’t deviate too much from what was intended. Can you turn this into a GitHub issue at some appropriate project location?

oparoz · June 9, 2016, 9:20pm

I completely agree, I just wanted to point out that it wasn’t that easy without some cooperation from the network and client env, but problems could stem from a misconfiguration on the box itself.

I encourage you to play with the Snap. Here are the instructions to install it. It works in a VM if you install the amd64 images. I even have i386 images for a slightly different version.

The wiki should have everything that you need, otherwise, just ask

I wouldn’t worry about that.

This would be the project’s issue tracker for now:

Try the snap if you can and if you find a problem, then you’re probably the best person to open an issue there. If not I’ll just make a request to offer an alternative way to reach the box. In the end it may be that this can only be solved via some documentation.