Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#12629 closed defect (fixed)

bonjour, ipv6 and link-local addresses: Unable to send the message, the conversation couldn't be started.

Reported by: ao2 Owned by: datallah
Milestone: 2.7.4 Component: Bonjour
Version: 2.7.3 Keywords: ipv6 link-local
Cc:

Description

Hi,

when trying to start a new conversation with a buddy on the local network with bonjour, I get the message "Unable to send the message, the conversation couldn't be started." in the conversation window.

Grasping through the log I can see that pidgin (purple) is trying to connect via IPv6, as avahi advertised this address first via the presence service.

(15:57:47) bonjour: Starting conversation with ao2@tp0
(15:57:47) dns: DNS query for 'fe80::290:27ff:fe97:xxxx' queued
(15:57:47) dns: Created new DNS child 20286, there are now 1 children.
(15:57:47) dns: Successfully sent DNS request to child 20286
(15:57:47) dns: Got response for 'fe80::290:27ff:fe97:xxxx'
(15:57:47) dnsquery: IP resolved for fe80::290:27ff:fe97:xxxx
(15:57:47) proxy: Attempting connection to fe80::290:27ff:fe97:xxxx
(15:57:47) proxy: Connecting to fe80::290:27ff:fe97:xxxx:5298 with no proxy
(15:57:47) proxy: Connection attempt failed: Invalid argument
(15:57:47) bonjour: Error connecting to buddy ao2@tp0 at fe80::290:27ff:fe97:xxxx:5298 error: Invalid argument

If I try ping6 on the address it does not work as is:

$ ping6 fe80::290:27ff:fe97:xxxx
connect: Invalid argument

But I expected this because link-local IPv6 addresses need a scope identifier to be considered unique, if I add it, then ping6 works:

$ ping6 fe80::290:27ff:fe97:xxxx%2
PING fe80::290:27ff:fe97:xxxx%2(fe80::290:27ff:fe97:xxxx) 56 data bytes
64 bytes from fe80::290:27ff:fe97:xxxx: icmp_seq=1 ttl=64 time=5.50 ms
64 bytes from fe80::290:27ff:fe97:xxxx: icmp_seq=2 ttl=64 time=1.68 ms

the "%2" does it, I could also have used "%eth1" with ping6.

So I think this is the cause of the problem: the network code in purple is not setting the correct scope id (see "man ipv6" in linux, look for scope_id) when using the ipv6 protocol, this is OK for global and site address but not for link-local addresses.

I also tried telepathy-salut and it works, and looking at its code the scope_id is handled there.

Any hint about where in the purple code this could be fixed? I don't know it yet. Ah, the scope_id value could very well be taken from the _AvahiIfIndex_ value from the mDNS resolution.

Thanks,

Antonio Ospite http://ao2.it

Attachments (2)

purple_ipv6_link-local_addresses.0.patch (1.1 KB) - added by ao2 9 years ago.
just a rough patch to verify the theory
avahi_ipv6_scope.patch (1.1 KB) - added by datallah 9 years ago.

Download all attachments as: .zip

Change History (14)

Changed 9 years ago by ao2

just a rough patch to verify the theory

comment:1 Changed 9 years ago by ao2

Just attached this patch to verify the theory, with this change I can now chat using link-local ipv6 addresses. The scope_id is hardcoded for now, the right value can be derived from the avahi query but I am not comfortable enough with purple code yet to code a proper way of doing it? Anyone willing to help?

Thanks,

Antonio

comment:2 Changed 9 years ago by datallah

Thanks for digging into the code. I don't have an easy way to test IPv6 stuff, but I'll try to come up with a patch that uses the Avahi query to populate the scope and post it here for you to test.

Changed 9 years ago by datallah

comment:3 Changed 9 years ago by datallah

  • Status changed from new to pending

If you revert your patch and apply the one that I have attached, does that work?

comment:4 Changed 9 years ago by mgariepy

I tested the patch on ubuntu maverick and it works great.

I made a package for maverick in my ppa containing your patch. https://launchpad.net/~mgariepy/+archive/ppa

comment:5 Changed 9 years ago by datallah@…

  • Milestone set to 2.7.4
  • Resolution set to fixed
  • Status changed from pending to closed

(In 8921eac26ae21b7e97796bbe7e616d4c4ed0f9c8):
Specify an IPv6 scope on the IP address being used to reference a Bonjour Buddy. Thanks goes to Antonio Ospite for figuring out that this needs to be done.

Fixes #12629

comment:6 Changed 9 years ago by ao2

Thanks datallah, the patch works indeed.

However I am now sure if the change should be rather seen as a workaround than a proper fix, as the problem is more with the IPv6 implementation in purple than bonjour specific, but I acknowledge that bonjour is where it is most likely to be experienced.

If you also think that ideally the fix should be in the low-level network code, would you add at least a comment in the code both in the bonjour workaround and in proxy.c just where I added the dirty fix in the first patch?

Thanks again for you prompt reaction.

Best Regards,

Antonio Ospite http://ao2.it

comment:7 Changed 9 years ago by datallah

I guess I don't know enough about IPv6 to answer that correctly.

In general the network API operates at the hostname level - the bonjour case where an IP address is used directly is somewhat uncommon. I would assume that during hostname resolution, the appropriate scope would be determined transparently by getaddrinfo(). In the case where an IP address is used, presumably the right thing to do there is to include the scope as part of the address like we're doing here.

I'm not sure what a fix in the low-level code would even look like? An optional attribute to a connect host to specify scope?! I hope not.

comment:8 follow-ups: Changed 9 years ago by 245T

I believe this affects the version that is shipped with ubuntu 10.10 Maverick Meerkat - 2.7.3. Is there any work-around that does not need installing a newer pidgin? I don't think I have ipv6 running on my system since it does not show up in lsmod, so disabling ipv6 (which would have seemed like an easy fix) probably will not help at all.

comment:9 in reply to: ↑ 8 Changed 9 years ago by 245T

Replying to 245T:

I believe this affects the version that is shipped with ubuntu 10.10 Maverick Meerkat - 2.7.3. Is there any work-around that does not need installing a newer pidgin? I don't think I have ipv6 running on my system since it does not show up in lsmod, so disabling ipv6 (which would have seemed like an easy fix) probably will not help at all.

Answering myself here: Changing "use-ipv6=yes" to "use-ipv6=no" in /etc/avahi/avahi-daemon.conf did the trick.

comment:10 in reply to: ↑ 8 ; follow-ups: Changed 9 years ago by mgariepy

The patch to fix this issue is already in the pidgin shipped with 10.10. It doesn't seem to work as expected, with the patch I am able to start a bonjour conversation with an older version of pidgin, the one shipped with ubuntu lucid 10.04 but when using the same patched version, it doesn't work. Also I did some tests with empathy and I cannot start a new conversation but if I have one started from the empathy client, it works.

I would suggest reopening this bug.

Replying to 245T:

I believe this affects the version that is shipped with ubuntu 10.10 Maverick Meerkat - 2.7.3. Is there any work-around that does not need installing a newer pidgin? I don't think I have ipv6 running on my system since it does not show up in lsmod, so disabling ipv6 (which would have seemed like an easy fix) probably will not help at all.

comment:11 in reply to: ↑ 10 Changed 9 years ago by datallah

Replying to mgariepy:

The patch to fix this issue is already in the pidgin shipped with 10.10. It doesn't seem to work as expected, with the patch I am able to start a bonjour conversation with an older version of pidgin, the one shipped with ubuntu lucid 10.04 but when using the same patched version, it doesn't work. Also I did some tests with empathy and I cannot start a new conversation but if I have one started from the empathy client, it works.

I would suggest reopening this bug.

It is likely that you're seeing the issue documented in #12657.

I'm not inclined to reopen this particular ticket because it is about a specific problem that has been fixed.

If you like, you may open a new ticket containing a debug log information (generally the debug log from both sides is necessary for Bonjour). If it does prove to be caused by the same issue, we can reopen this ticket at that time.

comment:12 in reply to: ↑ 10 Changed 8 years ago by pjdelport

Replying to mgariepy:

Does #13157 describe the regression you're seeing?

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!