Bonjour messages not received if one party has global ipv6 address and one doesn't

[Steve Dodd]

Something in the stack - Pidgin or avahi - gets confused if one machine has a global IPv6 address and the other only has a link-local address. Pidgin sees the global address advertised by mDNS, but connections come from the link-local address, and it rejects them because of the address mismatch:

(16:48:32) bonjour: _resolve_callback - name:User@beelink account:0x55f7906b8070 bb:(nil)
(16:48:32) bonjour: _resolve_callback - name:User@beelink ip:IPv6:addr:ess:obsc:ured:5a15 prev_ip:(null)
(16:48:32) blist: Updating buddy status for User@beelink (Bonjour)
(16:48:32) bonjour: _resolve_callback - name:User@beelink account:0x55f7906b8070 bb:0x55f79140a040
(16:48:32) bonjour: _resolve_callback - name:User@beelink ip:192.168.X.Y prev_ip:(null)
[..]
(16:48:41) bonjour: Received incoming connection from fe80::link:locl:addr:hddn%4.
(16:48:41) bonjour: We don't like invisible buddies, this is not a superheroes comic

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: pidgin 1:2.12.0-1ubuntu4
ProcVersionSignature: Ubuntu 4.15.0-58.64-generic 4.15.18
Uname: Linux 4.15.0-58-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
Date: Tue Aug 27 16:56:14 2019
InstallationDate: Installed on 2018-05-31 (453 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
ProcEnviron:
 TERM=screen.xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: pidgin
UpgradeStatus: No upgrade log present (probably fresh install)

[Steve Dodd (anarchetic)]

(For those trying to work around this, just disabling IPv6 through sysctl doesn't necessarily help - some combination of Network Manager and avahi seems to manage to advertise a link-local address even in this instance. v6 support can be turned off separately in avahi-daemon.conf)

[Steve Dodd (anarchetic)]

May be a long-standing avahi problem, but Pidgin may need to work around it:

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

[Steve Dodd (anarchetic)]

https://github.com/lathiat/avahi/blob/1cc2b8e8d62e939b8bd683f795794878863931af/avahi-core/iface.c#L707][1]

[Steve Dodd (anarchetic)]

Looking at the source, when browsing/resolving mdns, we get an interface ID passed to the callback. So it should be possible call if_indextoname() on that, then walk getifaddr() output to find the interface and then its link-local address, and that add that to the list of IPs ...

[Steve Dodd (anarchetic)]

Proof of concept of getting link local address for a specific ifindex.

[Steve Dodd (anarchetic)]

Just realised that the heat had addled my brain - this will get the link local address of target, not the originator. We could enumerate link local addresses on the originator and add a field to the mdns text record, but by definition those addresses are only valid on a particular interface, and the target wouldn't know which was which was which. In reality most LLAs will be formed from the interface MAC address, but unclear how much this should be relied upon. Worst case scenario is a user on one interface could spoof a conversation pretending to be a user on another.

Possibly this is all getting too complicated.

A setting to disable the IP match code might be simpler, though that seems to happen in multiple places in the codebase and obviously has security implications.

[Steve Dodd (anarchetic)]

Just found bug #1102906 raised against avahi for this behaviour years ago..

[Trent Lloyd (lathiat)]

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.

[Steve Dodd (anarchetic)]

Thanks for the explanation. Pidgin probably needs to keep the source address matching partly for security, and also possibly to disambiguate users. Binding to the advertised address probably wouldn't work in this case, as the target wouldn't have a route back for the global address prefix.

I guess it would have to enumerate all interfaces, then process each one at a time, retrieving the link local address and adding it to a new text record in the advertised service description. This also means monitoring for new and deleted interfaces with rtnetlink .. that's a pretty invasive change to the codebase.

At the very least, if Pidgin could raise a visible error with a pointer to an FAQ when this happens, that would be a start!

Would it be possible to add a flag to AvahiPublishFlags to allow the application to request the required behaviour on a per-service basis?

[Launchpad Janitor (janitor)]

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