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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1102906 Title: Cannot broadcast both on global and link address on same interface Status in Avahi: Unknown Status in avahi package in Ubuntu: New Bug description: Avahi seems to be hardwired to not over any link-local addresses on an interface, if there also exists a global (non-link-local) address on the same interface. Unfortunately I have need for this feature. I patched the source accordingly myself, creating a new config option 'publish-local-always' to enable that behavior. It's actually I minimal change, and I would be pleased, if you could integrate it (or something similar). You can find my patch in the attachment below. To manage notifications about this bug go to: https://bugs.launchpad.net/avahi/+bug/1102906/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
