[avahi] Bug when advertising service on both IPv4 and IPv6

[Patrick Oppenlander]

Hi,

I recently ran into a bug when advertising a service on both IPv4 and 
IPv6. In this particular instance the application (for legacy reasons) 
opens v4 and v6 sockets separately, and hence ends up with different ports.

I then attempted something like this (excuse the pseudo code):

===

group4 = avahi_s_entry_group_new(s, callback, ctx);
group6 = avahi_s_entry_group_new(s, callback, ctx);

avahi_server_add_service_strlst(
     s, group4, AVAHI_IF_UNSPEC, AVAHI_PROTO_INET, AVAHI_PUBLISH_NO_COOKIE,
     name, service_type, NULL, NULL, port4, list
);

avahi_server_add_service_strlst(
     s, group6, AVAHI_IF_UNSPEC, AVAHI_PROTO_INET6, AVAHI_PUBLISH_NO_COOKIE,
     name, service_type, NULL, NULL, port6, list
);

avahi_s_entry_group_commit(group4);
avahi_s_entry_group_commit(group6);

===

Note that everything is the same in the two services except for the 
protocol and port.

The services advertise with no errors and everything works until the 
services need to be removed.

===

avahi_s_entry_group_free(group4);
avahi_s_entry_group_free(group6);

===

Upon removal only one of the protocols is unregistered. In this case the 
v6 entries are goodbye'd. I traced through the code and came to the 
conclusion that send_goodbye_callback considers the v4 entries (as we 
free the v4 group first) to be duplicates in is_duplicate_entry and 
suppresses some goodbyes.

The problem appears to be that in this case some records that should be 
unique aren't.

Is this use case supported? If so, what would be an appropriate fix? 
Adding a 'protocol' field to AvahiRecord?

If it's fairly straight forward I'm happy to do the work.

         Patrick