Ghost XO in the presence service

[yani]

The XO had the following characteristics:

1) It showed in avahi-browse with nick "X58"...[check avahilist]

2) It did not show in neighbor view

3) It disaplied as a weird blank entry in analyze activity..[check the screenshot]

4) It was captured with GetBuddies, but crashed GetProperties ...[check sugar xo list]

[gdesmott]

From presence-service.log

1209513614.505599 DEBUG s-p-s.telepathy_plugin: <LinkLocalPlugin object at 0x817793c (telepathy_plugin+TelepathyPlugin at 0x82cb850)>: Contacts now online:
1209513614.507925 DEBUG s-p-s.telepathy_plugin:   12 .../keyid/b79e24ede504c970c50dd12a42285d6d0a09f977
1209513614.510083 DEBUG s-p-s.presenceservice: Handle 12, .../keyid/b79e24ede504c970c50dd12a42285d6d0a09f977 is now online
1209513614.512157 DEBUG s-p-s.presenceservice: Creating new buddy at .../keyid/b79e24ede504c970c50dd12a42285d6d0a09f977

...
1209513988.301973 DEBUG s-p-s.telepathy_plugin: <LinkLocalPlugin object at 0x817793c (telepathy_plugin+TelepathyPlugin at 0x82cb850)>: Contacts now online:
1209513988.304338 DEBUG s-p-s.telepathy_plugin:   17 .../keyid/b79e24ede504c970c50dd12a42285d6d0a09f977
1209513988.306447 DEBUG s-p-s.presenceservice: Handle 17, .../keyid/b79e24ede504c970c50dd12a42285d6d0a09f977 is now online

So we have 2 different contacts sharing the same key. That shouldn't happen.

From telepathy-salut.log

** (telepathy-salut:2541): DEBUG: salut_contact_manager_create_contact: Adding b79e24ed@xo-FF-FF-FF to contacts
** (telepathy-salut:2541): DEBUG: salut_contact_add_service: Contact b79e24ed@xo-FF-FF-FF: Resolver (b79e24ed@xo-FF-FF-FF _presence._tcp intf: 3 proto: 0): added
** (telepathy-salut:2541): DEBUG: contact_resolved_cb: Contact b79e24ed@xo-FF-FF-FF: Resolver (b79e24ed@xo-FF-FF-FF _presence._tcp intf: 3 proto: 0): contact b79e24ed@xo-FF-FF-FF resolved

...
** (telepathy-salut:2541): DEBUG: salut_contact_manager_create_contact: Adding b79e24ed@xo-0D-25-8F to contacts
** (telepathy-salut:2541): DEBUG: salut_contact_add_service: Contact b79e24ed@xo-0D-25-8F: Resolver (b79e24ed@xo-0D-25-8F _presence._tcp intf: 3 proto: 0): added
** (telepathy-salut:2541): DEBUG: contact_resolved_cb: Contact b79e24ed@xo-0D-25-8F: Resolver (b79e24ed@xo-0D-25-8F _presence._tcp intf: 3 proto: 0): contact b79e24ed@xo-0D-25-8F resolved

...
** (telepathy-salut:2541): DEBUG: browser_removed: Browser removed for b79e24ed@xo-FF-FF-FF
** (telepathy-salut:2541): DEBUG: browser_removed: Activity b79e24ed@xo-FF-FF-FF no longer advertised
** (telepathy-salut:2541): DEBUG: salut_contact_remove_service: Contact b79e24ed@xo-FF-FF-FF: Resolver (b79e24ed@xo-FF-FF-FF _presence._tcp intf: 3 proto: 0): remove requested
** (telepathy-salut:2541): DEBUG: contact_drop_resolver: Contact b79e24ed@xo-FF-FF-FF: Resolver (b79e24ed@xo-FF-FF-FF _presence._tcp intf: 3 proto: 0): removed, 0 left for b79e24ed@xo-FF-FF-FF
** (telepathy-salut:2541): DEBUG: contact_lost: Contact b79e24ed@xo-FF-FF-FF: disappeared from the local link

b79e24ed@xo-FF-FF-FF has handle 12 and b79e24ed@xo-0D-25-8F has handle 17.

xo-FF-FF-FF seems a bit weird. Is that an expected name? Any reason with these 2 laptops could share the same key?

[yani]

xo-FF-FF-FF is definetely false

the characters in the name belongs to the last 3 byte of the users MAC.

is there any possible explanation on why this happened?

[mstone]

Collabora - any theories on this one?

[gdesmott]

According logs, I'd say something was broken in one XO's configuration. No idea why.

[mstone]

There are a couple of problems here.

First, avahi & friends are capable of receiving information insufficient to constitute a valid contact with an OLPC Buddy. Yani managed to find an XO transmitting such invalid data.

Second, the current presence service assumes that the relation between contacts and keys will, at every moment of time, be one-to-one. This is a faulty assumption because there are many ways situations in which two XOs could come to share the same key -- intentional pseudonymity, malicious disclosure and use of the key, simple accidents with save-nand/copy-nand, or the representation of multiple routes to the same XO as multiple contacts with that XO.

It's probably not urgent to revise this design decision but it seems hard to fix this bug without doing so. Fortunately, the bug does not seem urgent at present.

[mstone]

#7581 is caused by the same design defect.