Telepathy works quite bad if I change connection frequently (say, using vpn or change from wired to wireless). Auto reconnect doesn't work in some case, sometimes you need to manually set to online (which will not work) and set back to offline, then set to online to make connection works. network manager is used here. Reproducible: Always Steps to Reproduce: 1. connect to wireless 2. disconnect to wireless 3. connect to wired Actual Results: Sometimes it keeps "online" while it actually not, you can still open chat, but all message will not send. Sometimes an network error appears and reconnect doesn't work. Expected Results: It can quickly detect the network connection change, and reconnect correctly.
Turns out this is a bug As a work around for you: enable Settings->General->Restore last presence on login --- Hijacking this thread for development purposes now. MissionControl being network aware requires the account to have the "connectsAutomatically" flag on the account enabled. Currently this is worded into "connect on login" which is wrong. Tasks: 1) Find out if automaticPresence is saved across sessions 2) see if connectsAutomatically actually causes connect on login. Worst case we simply change it to if(connectOnLogin) { setAutomaticPresence(config.readEntry(...)); } else { setAutomaticPresence(Tp::offline()); } setConnectsAutomatically(true);
Answering my own questions: automaticPresence is persistent as is connectsAutomatically with connectsAutomatically set to true it does seem to connect on login. This is rather annoying as it does mean reconnecting to user requested state, whilst not connecting on login isn't easy. We could setAutomaticPresence to offline if the option isn't ticked, as the kded should load before MC? but that's a bit hacky? Ideas people?
The automaticPresence can't be set to Offline, MC doesn't allow this. @Weng: is your MC compiled with networkmanager support? (it's the compile flag --with-connectivity=nm). If you have this flag enabled MC will set you to offline if the network goes down and if it goes up later it will restore your presence independent from connectsAutomatically and AutomaticPresence. At least it does this for me. I have the connectsAutomatically disabled for all accounts and disconnecting my network and later connecting it again, MC restores my previous status.
@Dominik Cermak Ah... this does the trick! thank you! I'll report this to Chakra pacakger. Would some one mark this as not-bug?
@Dominik >At least it does this for me. I have the connectsAutomatically disabled for all accounts and disconnecting my network and later connecting it again, MC restores my previous status. Not for me. From the MC logs: 11/10/12 23:38:32.670785 - [mcd] connectivity_monitor_nm_state_change_cb: New NetworkManager network state 70 (connected: true) 11/10/12 23:38:32.670808 - [mcd] on_transport_status_changed: Transport i love the internet changed status to 0 (connected) 11/10/12 23:38:32.670813 - [mcd] mcd_master_transport_connected: 11/10/12 23:38:32.670819 - [mcd] mcd_account_would_like_to_connect: gabble/jabber/temp2_40localhost0 does not ConnectAutomatically, and its RequestedPresence (1, 'offline', '') doesn't indicate the user wants to be online I clearly have nm support in MC, and it's not bringing my accounts back online when I reconnect. log implies it's because connectAutomatically is not set. Check it's actually disabled via "mc-tool show" and check your value of "Connects". Whether the kded option is enabled or not, will make no difference.
Of course I used mc-tool, here you have the output before disconnecting: Account: gabble/jabber/xerdomii_40jabber_2exerdomii_2ede0 Display Name: xerdomii@jabber.xerdomii.de Normalized: xerdomii@jabber.xerdomii.de Enabled: enabled Icon: im-jabber Connects: only when requested Nickname: Xerdomii Service: jabber Presences: Automatic: available (2) "" Current: available (2) "" Requested: available (2) "" Changing: no Then I disconnect: Account: gabble/jabber/xerdomii_40jabber_2exerdomii_2ede0 Display Name: xerdomii@jabber.xerdomii.de Normalized: xerdomii@jabber.xerdomii.de Enabled: enabled Icon: im-jabber Connects: only when requested Nickname: Xerdomii Service: jabber Presences: Automatic: available (2) "" Current: offline (1) "" Requested: available (2) "" Changing: no After connecting again: Account: gabble/jabber/xerdomii_40jabber_2exerdomii_2ede0 Display Name: xerdomii@jabber.xerdomii.de Normalized: xerdomii@jabber.xerdomii.de Enabled: enabled Icon: im-jabber Connects: only when requested Nickname: xerdomii@jabber.xerdomii.de Service: jabber Presences: Automatic: available (2) "" Current: available (2) "" Requested: available (2) "" Changing: no Note that the requested presence stays what I have requested at the beginning that's why MC restores it. According to your log your requested presence is offline, and therefor MC doesn't do anything. If I get a connection to eduroam at university I'll be online at IRC after 09:00 AM, else when I'm at home again (approx. 12 PM).
Well this is weird. I'm getting different behaviour if I disconnect the wireless network, and if I just pull out the USB wi-fi adaptor. It does seem in the standard disconnecting case it does work (which isn't what I was doing). This could simply mean that the network management code in MC is simply a bit rubbish. Marking as unconfirmed. I'm going to ask another dev to check, then if they claim it works as expected (without connectsAutomatically enabled), I'll close this bug.
*bump* Can someone else please confirm whether they get reconnected to KTp after a network reconnect with AutoConnect disabled?
For me the autoconnect in kcm is in the "third state" (the half-off), mc-tool shows Automatic: available, though when I go to sleep (get disconnected) and resume (reconnect), I'm not automatically reconnected and I have to manually go online. I'm pretty sure this used to work before I clean-installed my system, now it does not (mc should be with nm support; distro package). Probably unrelated, but the network manager now connects me almost instantly after resume whereas in the old system it took even 20 secs before it started connecting.
(In reply to comment #9) > For me the autoconnect in kcm is in the "third state" (the half-off), > mc-tool shows Automatic: available, though when I go to sleep (get > disconnected) and resume (reconnect), I'm not automatically reconnected and > I have to manually go online. For mission-control to handle suspend/resume correctly it has to be built with upower support (--enable-upower), so maybe that's the reason why it's not working for you. Let's try to get some more information. My observations were: I'm online so the output from mc-tool is this: Current: available (2) "" Requested: available (2) "" Then I disconnect (disabling Wireless in nm-applet): Current: offline (1) "" Requested: available (2) "" Note: Now I'm offline but MC still knows that I want to be available, if possible. Then I get connected again: Current: available (2) "" Requested: available (2) "" So everything works as intended. And all this while the account in question has: Connects: only when requested So if Martin (or someone else) could test with this steps and report back with your output it maybe helps to understand which component doesn't work for you (MC or NM).
Dominik is comment #10 with connectsAutomatically on or off?
(In reply to comment #11) > Dominik is comment #10 with connectsAutomatically on or off? (In reply to comment #10) > So everything works as intended. And all this while the account in question > has: > Connects: only when requested Off, see the line above ^
Ah, I can't read :) I "think" I understand my confusion in the spec now: The spec says: "If true, the account manager SHOULD attempt to put this account online with the AutomaticPresence whenever possible (in the base Account interface this is deliberately left vague). If false, it MUST NOT put the account online automatically in response to, for instance, connectivity changes, but SHOULD still put the account online with the AutomaticPresence if requested by the user (for instance, if the user tries to start a conversation using this account)." ( source http://telepathy.freedesktop.org/spec/Account.html#Property:ConnectAutomatically) Based looking at the MC code, it will still put the account into the _REQUESTED_ presence if that is online regardless of this setting. This only makes a difference if requested presence is offline and you change account status. In our current kded logging in code we set an automatic presence but not a requested one. Behaviour on connection changes at this point is different to if you go online on the presence applet (or even auto-away and back) which is probably why our results are inconsistent.
What I think we should do: - ignore all connectsAutomatically - ignore all automaticPresence - set the connect on login flag in the kded kconfig somewhere. - set the requestedPresence on login where we restore the presences.
As per comment #4