Opened 8 years ago

Closed 7 years ago

#4369 closed defect (fixed)

XS/jabber gabble: password is not available after reboot

Reported by: greenfeld Owned by: erikos
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: 0.98.x
Severity: Major Keywords: regression, upstream
Cc: dsd, JerryV Distribution/OS: OLPC
Bug Status: Needinfo

Description (last modified by erikos)

When establishing the connection with the jabber server the first time everything works fine, the connection can be made and using the mc-tool the password for that account is shown correctly.

After reboot, the connection can not be established again. Using 'mc-tool show <account name>' does not show the password anymore. One can connect to the jabber server by using 'mc-tool update <Account> string:password=<secret from default-keyring>' and passing the password by hand.

Version: OLPC: 13.1.0 os22

telepathy-mission-control: 5.14
telepathy-glib: 0.20
telepathy-gabble: 0.16.4
gnome-keyring: 3.6
libgnome-keyring: 3.6

This is a regression to 12.1.0.

Attachments (5)

daemon.log (4.7 KB) - added by erikos 8 years ago.
gnome-keyring-daemon log
mission-control.log (121.0 KB) - added by erikos 8 years ago.
mission-control log
gabble-pass.diff (1.2 KB) - added by JerryV 8 years ago.
patch to neighborhood.py
mission-control.2.log (292 bytes) - added by erikos 8 years ago.
log after adding the debug output (second run)
debug.patch (2.1 KB) - added by erikos 8 years ago.
mc patch for debugging

Download all attachments as: .zip

Change History (30)

comment:1 Changed 8 years ago by greenfeld

  • Cc dsd added
  • Component changed from untriaged to sugar
  • Owner set to erikos

comment:2 Changed 8 years ago by erikos

  • Version changed from Unspecified to 0.98.x

Ok, after setting up my environment I was able to debug this. I have found the following. In the mission control log there was the statement "missing mandatory account parameter password". We do set the password when using gabble when we create the account. However, when the account exists already, the password seem to not be known to the server, either not stored/restored correctly or not transferred well.

I verified that this is the case and deleted the telepathy settings (~/.local/share/telepathy/mission-control/) on two machines and restarted them, the next run the account got created again. I could see both buddies in the neighborhood view and shared Chat fine between those two machines. Looks like we are back to the previous behaviour when we sort out the password issue.

comment:3 Changed 8 years ago by erikos

One can use 'mc-tool show <account name>' (the account name can be retrieved with mc-tool list) to show the account details. When I did create the gabble account from new the password was listed there. Then after a restart it is not listed there anymore, and I can not connect to gabble.

comment:4 Changed 8 years ago by JerryV

  • Cc jvonau added

Think the password gets saved in ~/.gnome2/keyrings/default-keyring, not sure how to retrieve it but the password is just a call to: key_hash = get_profile().privkey_hash so it might be easy to recreate it.

comment:5 Changed 8 years ago by JerryV

  • Cc JerryV added; jvonau removed

comment:6 follow-up: Changed 8 years ago by JerryV

in terminal I can bring up gabble by hand with:
'mc-tool update <Account> string:password=<secret from default-keyring>'

the connection is instantaneously switched over to gabble and Neighbourhood View becomes populated.

comment:7 in reply to: ↑ 6 Changed 8 years ago by erikos

Replying to JerryV:

in terminal I can bring up gabble by hand with:
'mc-tool update <Account> string:password=<secret from default-keyring>'

the connection is instantaneously switched over to gabble and Neighbourhood View becomes populated.

Thanks Jerry for that update. Yes the password is there, we need to find out now why the communication between mission-control and the gnome-keyring is not working. I am trying to build gnome-keyring with debug output, but failed until now.

comment:8 Changed 8 years ago by erikos

For debugging I run the gnome-keyring-daemon and mission-control-5:

killall gnome-keyring-daemon mission-control-5

G_MESSAGES_DEBUG=all /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

G_MESSAGES_DEBUG=all MCMC_PERSIST=1 MC_DEBUG=all /usr/libexec/mission-control-5 2>&1 | tee mc.log

Changed 8 years ago by erikos

gnome-keyring-daemon log

Changed 8 years ago by erikos

mission-control log

comment:9 Changed 8 years ago by JerryV

Attached patch allow gabble to connect, think there still is an issue with two gabble dbus instances running.

Changed 8 years ago by JerryV

patch to neighborhood.py

comment:10 Changed 8 years ago by erikos

Thanks Jerry for the patch. I did the same to test some days ago. But if mission-control does talk with the keyring we should fix that and not interfere with passing the password to mc ourself.

comment:11 Changed 8 years ago by erikos

  • Description modified (diff)
  • Summary changed from XS/jabber registration does not switch to gabble from salut to XS/jabber gabble: password is not available after reboot

comment:12 Changed 8 years ago by erikos

  • Description modified (diff)

comment:13 Changed 8 years ago by erikos

As a next step I did downgrade the telepathy stack to our 12.1.0 one where things were working:

telepathy-gabble-0.16.0-1.fc17.armv7hl.rpm  telepathy-mission-control-5.12.1-1.fc17.armv7hl.rpm
telepathy-glib-0.18.1-1.fc17.armv7hl.rpm    telepathy-salut-0.8.0-1.fc17.armv7hl.rpm

We can connect fine now again with the jabber server as well after a reboot. This do suggest that the telepathy stack has changed and we can cross out Sugar and gnome-keyring of the equation.

comment:14 Changed 8 years ago by erikos

Looking at the latest changes in telepathy-mission-control I came across the _get_secrets_from_keyring function in src/mcd-account-manager-default.c Adding some debug logging in the function they point to that recent commit when the machine is rebooted and the machine is trying to establish the connection - no password is found.

Changed 8 years ago by erikos

log after adding the debug output (second run)

Changed 8 years ago by erikos

mc patch for debugging

comment:16 Changed 8 years ago by erikos

We were lucky enough, the fix was easy to do. I have uploaded a new telepathy-mission-control for testing http://dev.laptop.org/~erikos/result_mc/ works fine here for me.

comment:17 Changed 8 years ago by JerryV

revised rpm works for me.

comment:18 Changed 8 years ago by greenfeld

This is fixed in Fedora 18 and OLPC 13.1.0 os28; upstream code review is still pending though.

comment:19 Changed 8 years ago by rihoward

I installed the revised rpm and tested it and it worked for my scenarios.

comment:20 Changed 8 years ago by FGrose

#4289 marked as duplicate.

Confirmed on SoaS 8: Updating from telepathy-mission-control-5.14.0-1.fc18 to telepathy-mission-control-5.14.0-2.fc18 fixes this problem.

comment:21 Changed 8 years ago by erikos

  • Keywords upstream added

comment:22 Changed 8 years ago by dnarvaez

  • Milestone changed from 0.98 to Unspecified

comment:23 Changed 8 years ago by dnarvaez

  • Bug Status changed from New to Unconfirmed

comment:24 Changed 7 years ago by mystery828

  • Bug Status changed from Unconfirmed to Needinfo

comment:25 Changed 7 years ago by godiard

  • Resolution set to fixed
  • Status changed from new to closed

Fixed upstream, I think this can be closed.

https://bugs.freedesktop.org/show_bug.cgi?id=59468

Note: See TracTickets for help on using tickets.