Attributes are empty

[falmanna]

Hello, I am facing tow problems while using discovery service, 1- The attributes of a DNS service I am receiving are always empty, 2- I am not able to discover a service that has a '-' in its protocol when I do this I am receiving error with message "Formate specifier: s"

[tiwiz]

Hello,

I'm not sure that "-" is an allowed character in the ZeroConf draft. For what concerns the attributes, can you tell us how you are creating the service and if you see correctly the attributes with some other Bonjour-enabled softwares?

Thanks!

[falmanna]

For the '-' character, if you check the registered services here http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml, you can find many contains this character '-', so I think it is allowed.

For the attributes, I am using the following: subscription = ZeRXconf.startDiscovery(context, "_http._tcp.").subscribe(onNext, onError);

and in onNext I am trying to get the attributes map serviceInfo.getAttributes() but it is always empty, knowing that other methods are returning values, such as getAddress(), getServiceLayer().

[tiwiz]

OK, Let's try to narrow down the issue, so we can see where to fix it ;-)

If you use Bonjour Browser, do you find the service and see the attributes? Can you send a screenshot of it?

Thanks!

[falmanna]

Yes sure, I am using it to check the services, here is a screenshot

You can see that there are three attributes, and here is the log from my app: Code:

Log.v(TAG,"getAttributes "+ new Gson().toJson(serviceInfo.getAttributes().entrySet()));
            for (Map.Entry entry: serviceInfo.getAttributes().entrySet()) {
                Log.v(TAG, new Gson().toJson("getKey "+ entry.getKey()));
                Log.v(TAG, new Gson().toJson("getValue "+entry.getValue()));
            }
            Log.v(TAG, new Gson().toJson("getServiceName "+serviceInfo.getServiceName()));

Log:

 V/AddDevicePresenter: getAttributes []
V/AddDevicePresenter: getServiceName omega

[tiwiz]

Are you on Android 5.1+, right?

Thanks!

[falmanna]

Yes, I am on 6.0.1

Thank you for your fast response.

[tiwiz]

That is really strange... can you share the service data, so we can investigate :-)

[falmanna]

It is there in the screenshot

[tiwiz]

The issue should be fixed as per version 1.0.3.

Please, use the startDiscovery(context, protocol, *needsTxtRecord = true*) method and it should work.

[falmanna]

Great! Thank you...

Was there an issue? If yes, can you tell me what is it?

[tiwiz]

Yup, there was an issue within Android native library not resolving TXT record properly. Switching to jmDNS when needed is a temporary solution, but it should do until they fix the SDK itself :-)

[falmanna]

Awesome, what about the - character? is it now fixed also?

[tiwiz]

Yup, that should be fixed as well, the whole routine now uses jmDNS

[falmanna]

Friend, I tested it in my app, this time while true it is not showing any results. I also tested your sample app, it is not showing any results, if I changed the value to false it works as before! Did you test it?

[tiwiz]

Yup, I tested with a NodeJS script setting a txtRecord and it was showing the data correctly.

var mdns = require('mdns')

var txtRecord = { name: 'omega',
ID: '1234test',
path: '/',
board: 'omega',
"Address IPv6": 'fe80::42a3::6bff::fec1::253c::80'
}

ad = mdns.createAdvertisement(mdns.tcp('http'), 4321, {txtRecord: txtRecord})
ad.start();

How are you creating the service itself?

[falmanna]

Looks like it is only discovering services created by your app, I created one with your app and it worked, but it is not showing other services. I think it is something related to the service naming, because it is logging getServiceLayer _http._tcp.local. while true, and getServiceLayer ._http._tcp while false

[tiwiz]

When it is false, it's using the normal Android API, so it does need the local. suffix, while with true it needs it as it is needed by the jmDNS library. I tested it again and it's showing properly the service created with the NodeJS script (see attached screenshots). How are you creating the service? :-)

[falmanna]

I am in a lab full of devices, and the omega services that I am referring to is created using Avahi.
I attached 3 screenshots, tow from Bonjour app, and one from your sample app, see how your app is only discovering the service created by it while Bonjour discovered many services.

[tiwiz]

In this specific case, there is the filter (_http._tcp.) set. If you call the startDiscovery(context) without the protocol, it will list all the available services :-)

[falmanna]

The third screenshot is only showing _http._tcp. services in Bonjour app, there are 3 services, 2 printers, and your service, while in your sample there is only your service

[tiwiz]

This is really strange... I tried with also TeamViewer's protocol and it finds everything correctly... the Bonjour app and the sample are running on the same conditions, right?

[falmanna]

Yes, Both are running on my mobile. Try to create a services using avahi if you can.

Here I am trying to discover _ssh._tcp.

Bonjour App

Your Sample App

[tiwiz]

Aaaah, found the issue!

It loos like Avahi is not compatible with .local unicast zone, but that is needed by jmDNS (that library is quite old, unfortunately). Bonjour Browser, though, is based on Apple DNS, that has not this limitation (neither has Android-API, that's why if you switch to false, it works properly). I am implementing also the Apple library, but that is not as fast as tweaking the other 2 libraries, I'm sorry.

[falmanna]

Ummm, Thank you for your time and efforts :) Do you know what should I be using? looks like the Android API has this Attributes issue, and jmDNS has the .local issue! Do you think apple library works with all these cases?

[tiwiz]

Yup, it should work :-) You can try using the RxDNSSD library, if I recall correctly, it embeds the Apple one :-)

[falmanna]

Cool! Best wishes friend :)