[avahi] Published service gets incorrect address

[Denis Kharlamov]

Thank you, Tom! I think you may be onto something. The link you’ve provided seems rather informative. Some of it went over my head, but I’m sure some of my colleagues will be able to  comprehend it better than I did.

I just wanted to follow up with some more information and screenshot from avahi-discover (see attached), regarding what is happening.

-          We have several machines (in screenshot they are cpcssil1, sil1, and avlab2u).

-          Each machine can have many instances of a UI Server running.

-          UI Server publishes itself as a service on the network.

-          The service name is always unique in a format of UIS_<hostname>_<username>_<port>. I’m aware of a service name conflict resolution, and that is handled via adding ‘#2’ to the service name.
In the screenshot, you can see that there are 2 services running on cpcssil1 and 2 services running on avlab2u. I didn’t capture it in a screenshot, but the Address for those is shown correctly in avahi-discover as “cpcssil1.local” and “avlab2u.local”.
When a user runs a Login Client (the client has the discovery), it will correctly pick up all the services, and if it will have no problem connecting to “avlab2u:30007”.
Also in the screenshot, you can see that the highlighted sil1 machine, has the address of “sil1-2.local” which is not correct. If you try to ping sil1-2, it does not exist. If you try to connect to sil1-2:30003, it does not exist.

Do you still suspect that the issue is due to the conflict resolution? Do you think adding a flag “AVAHI_PUBLISH_ALLOW_MULTIPLE - For raw records: Allow multiple local records of this type, even if they are intended to be unique.” Might solve the issue?

Thank you,
Denis

From: avahi [mailto:avahi-bounces at lists.freedesktop.org] On Behalf Of Tom Pusateri
Sent: Monday, June 19, 2017 7:27 PM
To: Avahi ML <avahi at lists.freedesktop.org>
Subject: Re: [avahi] Published service gets incorrect address

Without more information, this sounds like normal naming conflict resolution as described in:

https://tools.ietf.org/html/rfc6762#page-31

Another host on the link local network is using the same name and so your name is made unique by appending “-2”.

Sometimes, this occurs when a single host has multiple interfaces on the same link local network (like wired and wireless ethernet) or when there are bugs in the conflict resolution implementations.

This is harmless as long as your host is correctly resolving this name with the “-2” appended.

If you have mdns name resolution configured, you can ping (or ping6 if appropriate) "<name>-2.local” to see if it is resolving ok.

By killing the avahi-daemon, it is probably starting to use <name> again until conflict resolution kicked in and causes the name change to append the “-2”.

If this is not accurate, please send more detailed info (logs, packet traces, etc.).

Thanks,
Tom

On Jun 19, 2017, at 9:51 AM, Denis Kharlamov <dkharlamov at aversan.com<mailto:dkharlamov at aversan.com>> wrote:

Hello,

I’m experiencing a peculiar issue with my avahi where the address of the published service gets a “-2” appended to it.

My use of Avahi is essentially this: http://www.avahi.org/doxygen/html/client-publish-service_8c-example.html
The service always gets published without fail, with the correct service name, and TXT records. However, the address that avahi-discover shows, has a -2 appended to it.
I am not sure why, because in code I am passing a null pointer for the host, as per documentation:
“The host this services is residing on. We recommend to pass NULL here, the daemon will than automatically insert the local host name in that case”

The only way I’ve been able to resolve this is by killing the avahi-daemon and restarting it. Does anyone have any idea as to what could be causing this behavior?

Thank you,
Denis Kharlamov

_______________________________________________
avahi mailing list
avahi at lists.freedesktop.org<mailto:avahi at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/avahi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/avahi/attachments/20170620/31e52087/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.PNG
Type: image/png
Size: 42604 bytes
Desc: Capture.PNG
URL: <https://lists.freedesktop.org/archives/avahi/attachments/20170620/31e52087/attachment-0001.png>