Opened 6 years ago

Last modified 6 years ago

#6943 new defect

Ghost XO in the presence service

Reported by: yani Owned by: Collabora
Priority: normal Milestone: Opportunity
Component: presence-service Version:
Keywords: 8.2.0:- 9.1.0:? Cc: daf, Collabora, kimquirk
Blocked By: Blocking:
Deployments affected: Action Needed: design
Verified: no

Description

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]

Attachments (4)

logs.CSN74400049.2008-04-30.19-22-10.tar.bz2 (107.2 KB) - added by yani 6 years ago.
buddylist.png (79.2 KB) - added by yani 6 years ago.
sugar xo list (680 bytes) - added by yani 6 years ago.
avahi list (868 bytes) - added by yani 6 years ago.

Download all attachments as: .zip

Change History (11)

Changed 6 years ago by yani

Changed 6 years ago by yani

Changed 6 years ago by yani

comment:1 Changed 6 years ago by 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?

comment:2 Changed 6 years ago by yani

  • Cc kimquirk added; kim removed

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?

comment:3 Changed 6 years ago by marco

  • Keywords 8.2.0:? needs-testing added
  • Milestone changed from Never Assigned to 8.2.0 (was Update.2)

comment:4 Changed 6 years ago by mstone

  • Action Needed set to diagnose
  • Keywords needs-testing removed

Collabora - any theories on this one?

comment:5 Changed 6 years ago by gdesmott

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

comment:6 Changed 6 years ago by mstone

  • Action Needed changed from diagnose to design
  • Keywords 8.2.0:- 9.1.0:? added; 8.2.0:? removed
  • Milestone changed from 8.2.0 (was Update.2) to Opportunity
  • Priority changed from high to normal

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.

comment:7 Changed 6 years ago by mstone

#7581 is caused by the same design defect.

Note: See TracTickets for help on using tickets.