Recently I've been working on fixing bugs in an Android app, where one of its main functions is to find network-connected printers and print to them. It was originally using the JmDNS library to do the network discovery of printers:
https://github.com/jmdns/jmdns

I've been working on this app for the past few weeks, and suddenly this past Monday, a weird issue started happing - The JmDNS library started to only give an ipv6 network address for our test printer (previously, it had been giving an ipv4 address), and it seemed the ipv6 address it was giving was incorrect, as the app couldn't ping and couldn't otherwise connect to the printer with that address.

I found that Google added a network service discovery API to the Android SDK starting with SDK version 16:
https://developer.android.com/training/connect-devices-wirelessly/nsd
I updated the Android app to use the Android network service discovery API instead of JmDNS, and I found the Android network service discovery returns the correct network address for the printer (and is getting its ipv4 address). Now the app can connect and print to the printer again.

I'm curious if anyone here has worked with network service discovery and has seen anything weird like the issue I was having?

The office where I work did have a power outage last weekend, and I wonder if that may have affected anything on our network to cause the issue I was seeinig. But it seems like it was purely a software issue, so I don't really know why I started seeing that issue.

Also, I feel like the official Android network service discovery API would probably be better to use than a 3rd-party library, but JmDNS is still in development (the latest version is from August 2021), so I imagine there may be advantages of using it. I'm wondering why choose something like JmDNS over the Android network service discovery API?

Nightfox

---
■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com

Re: Android JmDNS vs. Android Network Service Discovery
By: Nightfox to All on Thu Jun 09 2022 09:42 am

> Recently I've been working on fixing bugs in an Android app, where one of
> its main functions is to find network-connected printers and print to them.
> It was originally using the JmDNS library to do the network discovery of
> printers: https://github.com/jmdns/jmdns
>
> I've been working on this app for the past few weeks, and suddenly this past
> Monday, a weird issue started happing - The JmDNS library started to only
> give an ipv6 network address for our test printer (previously, it had been
> giving an ipv4 address), and it seemed the ipv6 address it was giving was
> incorrect, as the app couldn't ping and couldn't otherwise connect to the
> printer with that address.
>
> I found that Google added a network service discovery API to the Android SDK
> starting with SDK version 16:
> https://developer.android.com/training/connect-devices-wirelessly/nsd
> I updated the Android app to use the Android network service discovery API
> instead of JmDNS, and I found the Android network service discovery returns
> the correct network address for the printer (and is getting its ipv4
> address). Now the app can connect and print to the printer again.
>
> I'm curious if anyone here has worked with network service discovery and has
> seen anything weird like the issue I was having?
>
> The office where I work did have a power outage last weekend, and I wonder
> if that may have affected anything on our network to cause the issue I was
> seeinig. But it seems like it was purely a software issue, so I don't really
> know why I started seeing that issue.
>
> Also, I feel like the official Android network service discovery API would
> probably be better to use than a 3rd-party library, but JmDNS is still in
> development (the latest version is from August 2021), so I imagine there may
> be advantages of using it. I'm wondering why choose something like JmDNS
> over the Android network service discovery API?

The underlying system function is probably getaddrinfo (https://linux.die.net/man/3/getaddrinfo) which provides the caller control over the inclusion/exclusion of address families (e.g. IPv4 or IPv6). I'm not familiar with JmDNS or the Android network service discovery API, but look for similar control over the address "families" that may be returned by such discovery functions.
--
digital man (rob)

Rush quote #8:
One likes to believe in the freedom of music...
Norco, CA WX: 77.2°F, 63.0% humidity, 2 mph E wind, 0.00 inches rain/24hrs
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: Android JmDNS vs. Android Network Service Discovery
By: Digital Man to Nightfox on Thu Jun 09 2022 10:57 am

DM> The underlying system function is probably getaddrinfo
DM> (https://linux.die.net/man/3/getaddrinfo) which provides the caller
DM> control over the inclusion/exclusion of address families (e.g. IPv4 or
DM> IPv6). I'm not familiar with JmDNS or the Android network service
DM> discovery API, but look for similar control over the address "families"
DM> that may be returned by such discovery functions.

I suspected there may be some underlying function to control which type of network addresses are returned. When using the JmDNS library, there was nothing specifying to use either ipv4 or ipv6 addresses (and it was getting an ipv4 address previously). I hadn't changed anything in the app to specify which type of address to receive though; for some reason it seemed to change on its own. It had started working again with the JmDNS library, but when I ran through some specific steps, it triggered something to only get an ipv6 address (no change in the code).

Nightfox

---
■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com

Re: Android JmDNS vs. Android Network Service Discovery
By: Nightfox to Digital Man on Thu Jun 09 2022 12:02 pm

> Re: Android JmDNS vs. Android Network Service Discovery
> By: Digital Man to Nightfox on Thu Jun 09 2022 10:57 am
>
> DM> The underlying system function is probably getaddrinfo
> DM> (https://linux.die.net/man/3/getaddrinfo) which provides the caller
> DM> control over the inclusion/exclusion of address families (e.g. IPv4 or
> DM> IPv6). I'm not familiar with JmDNS or the Android network service
> DM> discovery API, but look for similar control over the address "families"
> DM> that may be returned by such discovery functions.
>
> I suspected there may be some underlying function to control which type of
> network addresses are returned. When using the JmDNS library, there was
> nothing specifying to use either ipv4 or ipv6 addresses (and it was getting
> an ipv4 address previously). I hadn't changed anything in the app to
> specify which type of address to receive though; for some reason it seemed
> to change on its own. It had started working again with the JmDNS library,
> but when I ran through some specific steps, it triggered something to only
> get an ipv6 address (no change in the code).

Could the change just simply be on the DNS records for the address your resolving? Are you seeing this same change in behavior for all addresses being resolved or just some?
--
digital man (rob)

Synchronet "Real Fact" #23:
The third ever Synchronet BBS was The Beast's Domain (sysop: King Drafus)
Norco, CA WX: 89.0°F, 43.0% humidity, 15 mph S wind, 0.00 inches rain/24hrs
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: Android JmDNS vs. Android Network Service Discovery
By: Digital Man to Nightfox on Thu Jun 09 2022 02:16 pm

>> I suspected there may be some underlying function to control which
>> type of network addresses are returned. When using the JmDNS library,
>> there was nothing specifying to use either ipv4 or ipv6 addresses (and
>> it was getting an ipv4 address previously). I hadn't changed anything
>> in the app to specify which type of address to receive though; for
>> some reason it seemed to change on its own. It had started working
>> again with the JmDNS library, but when I ran through some specific
>> steps, it triggered something to only get an ipv6 address (no change
>> in the code).

DM> Could the change just simply be on the DNS records for the address your
DM> resolving? Are you seeing this same change in behavior for all addresses
DM> being resolved or just some?

I'd only been testing it with the one printer (which was the only printer that was coming up), so I'm not really sure.

Nightfox

---
■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com

Re: Android JmDNS vs. Android Network Service Discovery
By: Nightfox to Digital Man on Thu Jun 09 2022 02:59 pm

DM>> Could the change just simply be on the DNS records for the address
DM>> your resolving? Are you seeing this same change in behavior for all
DM>> addresses being resolved or just some?

Ni> I'd only been testing it with the one printer (which was the only printer
Ni> that was coming up), so I'm not really sure.

Other apps on the device were able to get the correct (and ipv4) address of the printer, which made me think it may have been something going on with the jmDNS library.

Nightfox

---
■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com

Re: Android JmDNS vs. Android Network Service Discovery
By: Nightfox to Digital Man on Thu Jun 09 2022 03:28 pm

> Re: Android JmDNS vs. Android Network Service Discovery
> By: Nightfox to Digital Man on Thu Jun 09 2022 02:59 pm
>
> DM>> Could the change just simply be on the DNS records for the address
> DM>> your resolving? Are you seeing this same change in behavior for all
> DM>> addresses being resolved or just some?
>
> Ni> I'd only been testing it with the one printer (which was the only
> Ni> printer that was coming up), so I'm not really sure.
>
> Other apps on the device were able to get the correct (and ipv4) address of
> the printer, which made me think it may have been something going on with
> the jmDNS library.

I just realized this is multicast DNS (Bonjour) you're dealing with. Very different animal from what I was originally interpretting your problem/solution to be.

Network packet captures with the appropriate disectors/parsers might help illuminate what's going on.
--
digital man (rob)

Sling Blade quote #6:
Karl: he should've had a chance to grow up. He would had fun some time.
Norco, CA WX: 86.1°F, 47.0% humidity, 8 mph SSE wind, 0.00 inches rain/24hrs
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net