Cannot broadcast both on global and link address on same interface

I found a mailing list post which mentioned this, but no replies:

https://lists.freedesktop.org/archives/avahi/2010-March/001863.html

It actually causes problems for Pidgin in certain circumstances, see bug #1841621.

Part of the reason this behavior exists in Avahi is that many applications do not correctly retrieve the scope ID (interface index) when doing hostname resolution, and if not supplied then connection to such a link local address will fail. Applications are likely to receive such an address at random.

Also until very recently nss-mdns didn't actually support passing through that scope ID, though it now does in the latest versions.

So changing Avahi to always return these link local IPs is much more likely to break pretty much every other application except Pidgin. To my mind what Pidgin should do to resolve this issue is to explicitly either not block based on the incoming IP address, or, bind explicitly to the IP address that is being advertised to prevent the connection being sourced from the link local address.

Would it be possible to add a flag to AvahiPublishFlags to allow the application to request the required behaviour on a per-service basis? I can't see any options for Pidgin that don't require pretty radical restructuring of its codebase (more discussion at https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1841621/comments/10)

When I say bind, I actually meant to bind the outgoing connection from Pidgin (not related to Avahi). So when creating the socket, specify the source IP address.

The problem is that when you connect (without specifying a source) then at least for IPv6 due to the routing table specification of the src address the outgoing connection ends up choosing the source address as the link local address (which pidgin doesn't know about).

More generally though this method of blocking a connection based on the source IP is problematic and will also cause problems in other scenarios, such as for example if a user is connected to the same network from two network cards (e.g. wired + wireless) - and pidgin wants to connect to the IP for the interface without the route preference.

It would perhaps make more sense to do connector authentication using either a list of all subnets on that interface, i.e. check and ensure that the connection is from any local subnet on that interface or otherwise using some kind of public-private key scheme. The "subnet check" could also be simplified by simply always allowing connections from the link-local subnet regardless of the IP of the user.

Does Pidgin use the IP address to identify which user is connecting, or does it do some kind of username authentication in the socket after connection? Remember that because mDNS itself is very un-authenticated; you're not really gaining any "security" by the authentication. At best I imagine it's the most convenient way to map a user to the incoming connection if theres no metadata of such inside the connection itself.

Otherwise circling back to the original suggestion of changing to always advertise the link local address. If we wanted to go down that route, I think first we would need to modify both libnss-mdns and Avahi to re-order the list of IPs returned during hostname resolution to list the "closest" IP first; i.e. the IP we are more likely to be able to connect to - and also to list global ahead of local. So that at least most applications will get the global IP first and won't need the scope_id so won't fail once we add this feature.

Status changed to 'Confirmed' because the bug affects multiple users.