Linux-based client will not resolve service #40

robreuss · 2020-11-30T01:20:00Z

I'm attempting to browse for a Bonjour service from a Linux client running on Raspbian Buster on a Raspberry Pi Zero W that is published by an iOS server . Although it finds the service, it does not resolve.

This delegate method is called:
public func netService(_ sender: NetService, didNotResolve errorDict: [String: NSNumber])

The error provided is:
["NSNetServicesErrorCode": -1, "NSNetServicesErrorDomain": 10]

I thought I had this Linux-based client browsing/resolution working under Linux about a year or two ago, although that was with Ubuntu Mate, and perhaps I made a configuration change to that install.

I used avahi-browse to look for the service and it is published:

`Server version: avahi 0.7; Host name: goose.local
E Ifce Prot Name Type Domain

wlan0 IPv6 RoverController _RemoteLogging._tcp local
wlan0 IPv4 RoverController _RemoteLogging._tcp local
= wlan0 IPv6 RoverController _RemoteLogging._tcp local
hostname = [Robs-iPad-Pro.local]
address = [192.168.86.35]
port = [63252]
txt = []
= wlan0 IPv4 RoverController _RemoteLogging._tcp local
hostname = [Robs-iPad-Pro.local]
address = [192.168.86.35]
port = [63252]
txt = []
: Cache exhausted
: All for now
`

That same Linux host is itself running a service and iOS devices are able to connect to that no problem.

Thanks.

The text was updated successfully, but these errors were encountered:

robreuss · 2020-11-30T16:32:28Z

I think this issue might be related:
#31

In that case, I seem to have put in place logic that prevented the library from attempting resolve twice, so I'll dig in and see if that is not functioning correctly.

I'm currently working on tag 0.7.0 since I was getting the fatal errors on 0.8.0:
276ca1c#commitcomment-44640585

robreuss · 2020-11-30T16:52:07Z

I did some debugging with dns-sd -B and dns-sd -L. Browsing successfully sees the service I want to resolve, but when I attempt to resolve using "-L", I get a "NSNetServicesErrorCOde -65540". See also the message in bold below that has strange formatting for the service name/domain, repeating the domain for some reason:

'Cdns_sd' /home/pi/Development/PanTilt/.build/checkouts/Cdns_sd: warning: system packages are deprecated; use system library targets instead
'Cdns_sd' avahi-compat-libdns_sd.pc: warning: non whitelisted flag(s): -D_REENTRANT
Browsing for _RemoteLogging._tcp
DATE: ---Monday, November 30, 2020---
11:47:25.025  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
*** WARNING *** The program 'dns-sd' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
11:47:25.025  Add        ?   ? local.               _RemoteLogging._tcp. RoverController
11:47:25.025  Add        ?   ? local.               _RemoteLogging._tcp. RoverController
^Cpi@goose:~/Development/PanTilt $ swift run dns-sd -L _RemoteLogging._tcp local.
'Cdns_sd' /home/pi/Development/PanTilt/.build/checkouts/Cdns_sd: warning: system packages are deprecated; use system library targets instead
'Cdns_sd' avahi-compat-libdns_sd.pc: warning: non whitelisted flag(s): -D_REENTRANT
**Lookup _RemoteLogging._tcp.local..local.**
DATE: ---Monday, November 30, 2020---
11:47:54.054  ...STARTING...
*** WARNING *** The program 'dns-sd' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
DNSService call failed ["NSNetServicesErrorDomain": 10, "NSNetServicesErrorCode": -65540]```

Bouke · 2020-11-30T22:21:41Z

You're passing incorrect arguments to dns-sd:

dns-sd -L <Name> <Type> <Domain>                       (Resolve a service instance)

The name is the Instance Name as printed by the browse tool (RoverController). To resolve this service: (domain is optional)

swift run dns-sd -L RoverController _RemoteLogging._tcp

Regarding the issue with 0.8.0, I've found the problem: the version of swift installed by me is overridden on CI. Will publish a new version in the next few days after I've sorted that CI issue.

robreuss · 2020-11-30T22:41:35Z

I corrected the arguments but I'm getting a "-1" error message:

Server version: avahi 0.7; Host name: goose.local
E Ifce Prot Name                                          Type                 Domain
+  wlan0 IPv6 RoverController                               _RemoteLogging._tcp  local
+  wlan0 IPv4 RoverController                               _RemoteLogging._tcp  local
=  wlan0 IPv6 RoverController                               _RemoteLogging._tcp  local
   hostname = [Robs-iPad-Pro.local]
   address = [192.168.86.35]
   port = [52566]
   txt = []
=  wlan0 IPv4 RoverController                               _RemoteLogging._tcp  local
   hostname = [Robs-iPad-Pro.local]
   address = [192.168.86.35]
   port = [52566]
   txt = []
: Cache exhausted
: All for now
^CGot SIGINT, quitting.
pi@goose:~/Development/PanTilt $ swift run dns-sd -L RoverController _RemoteLogging._tcp
'Cdns_sd' /home/pi/Development/PanTilt/.build/checkouts/Cdns_sd: warning: system packages are deprecated; use system library targets instead
'Cdns_sd' avahi-compat-libdns_sd.pc: warning: non whitelisted flag(s): -D_REENTRANT
Lookup RoverController._RemoteLogging._tcp.local.
DATE: ---Monday, November 30, 2020---
17:39:55.055  ...STARTING...
*** WARNING *** The program 'dns-sd' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
DNSService call failed ["NSNetServicesErrorDomain": 10, "NSNetServicesErrorCode": -1]

Bouke · 2020-11-30T23:11:11Z

Could you change the following line:

NetService/Sources/NetService/NetService.swift

Line 497 in d8c6507

didNotResolve(error: -1)

To:

            print(String(cString: gai_strerror(1)))
            didNotResolve(error: Int(error))

The -1 error is a generic error code, with this change it should give a clear error message + code.

robreuss · 2020-12-01T18:26:19Z

Here's the edit I made per your request, on a fork:
robreuss@1b37de9

For some reason, didNotResolve is not firing recently. My app is consistently seeing two services (I guess IPv4 and IPv6)., and II had code to prevent resolving a second service, though the first service was not resolving regardless. When I removed the code to prevent the second resolving process, then I do consistently get didNotResolve, but it gives "Unknown error":

[EC] {RemoteLogging} Browser did not resolve: ["NSNetServicesErrorCode": -2, "NSNetServicesErrorDomain": 10]```

robreuss · 2020-12-01T19:13:25Z

I've implemented this in a similar way on a Raspberry Pi 3 running Ubuntu 16.04/Swift v5.1.2 and it successfully resolves. The Zero I'm having the issue on is running Raspbian Buster/Swift v5.1.5. It's possible there are configuration differences between them as I setup the RPi 3 over a year ago.

The connection fails because of "Connection Refused" message that I think is coming from the BlueSocket framework, so probably unrelated to the browsing issue.

robreuss · 2020-12-01T19:47:03Z

I reverted to tag 0.7.0 and still see the resolving problem, if that tells you anything.

Bouke · 2020-12-01T22:03:40Z

I'm afraid I don't know what error number -2 means. I've run into issues on ARM before, however I'm currently on 5.1.5 myself as well:

Swift version 5.1.5 (swift-5.1.5-RELEASE)
Target: armv6-unknown-linux-gnueabihf

Can you include a stack trace when the delegate is called? (e.g. print(Thread.callStackSymbols.joined(separator: "\n"))).

robreuss · 2020-12-09T01:38:00Z

Here's the trace from the didNotResolve delegate:

[EC] {RemoteLogging} Browser did not resolve: ["NSNetServicesErrorDomain": 10, "NSNetServicesErrorCode": -1]
/home/pi/usr/lib/swift/linux/libFoundation.so($s10Foundation6ThreadC16callStackSymbolsSaySSGvgZ+0x28) [0xb65ec828]
.build/armv6-unknown-linux-gnueabihf/debug/PanTilt(+0x13710) [0x447710]
.build/armv6-unknown-linux-gnueabihf/debug/PanTilt(+0x13264) [0x447264]
.build/armv6-unknown-linux-gnueabihf/debug/PanTilt(+0x8d680) [0x4c1680]
.build/armv6-unknown-linux-gnueabihf/debug/PanTilt(+0x8e58c) [0x4c258c]
.build/armv6-unknown-linux-gnueabihf/debug/PanTilt(+0x848a4) [0x4b88a4]
.build/armv6-unknown-linux-gnueabihf/debug/PanTilt(+0x84bd4) [0x4b8bd4]```

robreuss · 2020-12-10T17:04:18Z

I moved forward to 8.1.0 (from 7.0.0) on my RPi 3 and it resolved but I now get a Connection Refused error:
TCP Client got error connecting socket: Error code: -9989(0x-2705), Connection refused

If that's indicating some type of barrier on iOS, perhaps that is what's keeping my RPi Zero from resolving? I realized that's kind of a long-shot.

Any ideas on why an iOS would be refusing connections? Probably related to my socket framework but thought I would ask anyway!

robreuss · 2020-12-10T19:22:01Z

I solved the connection refused issue. Will be testing on the RPi Zero (Raspbian Buster) later today so don't invest any time in this just yet.

robreuss · 2020-12-11T00:19:44Z

I've got everything working from an RPi 3 running Ubuntu Mate to an iOS device, but unfortunately it is exhibit the same resolving problem with RPi Zero running Raspbian Buster. Any thoughts? In my research it seems Ubuntu is not available for the Zero.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Linux-based client will not resolve service #40

Linux-based client will not resolve service #40

robreuss commented Nov 30, 2020

robreuss commented Nov 30, 2020

robreuss commented Nov 30, 2020

Bouke commented Nov 30, 2020 •

edited

Loading

robreuss commented Nov 30, 2020

Bouke commented Nov 30, 2020

robreuss commented Dec 1, 2020

robreuss commented Dec 1, 2020

robreuss commented Dec 1, 2020

Bouke commented Dec 1, 2020

robreuss commented Dec 9, 2020

robreuss commented Dec 10, 2020

robreuss commented Dec 10, 2020

robreuss commented Dec 11, 2020

Linux-based client will not resolve service #40

Linux-based client will not resolve service #40

Comments

robreuss commented Nov 30, 2020

robreuss commented Nov 30, 2020

robreuss commented Nov 30, 2020

Bouke commented Nov 30, 2020 • edited Loading

robreuss commented Nov 30, 2020

Bouke commented Nov 30, 2020

robreuss commented Dec 1, 2020

robreuss commented Dec 1, 2020

robreuss commented Dec 1, 2020

Bouke commented Dec 1, 2020

robreuss commented Dec 9, 2020

robreuss commented Dec 10, 2020

robreuss commented Dec 10, 2020

robreuss commented Dec 11, 2020

Bouke commented Nov 30, 2020 •

edited

Loading