Following an upgrade yesterday kde-telepathy no longer connects any accounts... the "connect swirl" is there on the presence plasmoid but no network activity is seen and it never connects.

Any suggestions welcome...

Can you run ktp-debugger and see if there are any errors in mission-control or gabble tab? Which accounts you're trying to connect btw?

Just as suddenly it started working this morning... no updates made...

does it have a problem with using ppp (usb mobile) connection? It did not use to have (read 0.5.x) but today I am back on wireless and suddenly it works

Glad it works Hard to say without proper debug, could be anything network related. If you'll get a chance to be on mobile network again, run that debugger and let us know.

mck182 wrote:Glad it works Hard to say without proper debug, could be anything network related. If you'll get a chance to be on mobile network again, run that debugger and let us know.

Was going to (it seems to be ppp related as I now had same behaviour) but today's update of daily ppa kubuntu 12.10 completely broke kde-telepathy... have to wait until it works againg. Problem with version of libktpcommoninternalsprivate4 v 5 (sorry if I got something wrong there in the name)

mck182 wrote:Glad it works Hard to say without proper debug, could be anything network related. If you'll get a chance to be on mobile network again, run that debugger and let us know.

OK I installed the debugger and ran it while at home connecting via 3G usb modem.

A load of different messages but I believe the last one to be most important:

mcd_kludge_transport_account_connection_cb: haze/icq/_3155656320 wants to connect, but we're offline; queuing it up

In short KTP does not see that I am connected. Very likely because I connect via CLI using wvdial. This cause the modem is not well understood by networkmanager, it recognises it but nothing actually happens if I try to connect that way

If networkmanager is running this will check it and block it.

If you're not using NM kill it.

david_edmundson wrote:If networkmanager is running this will check it and block it.

If you're not using NM kill it.

how do I kill NM??

And not to sound like "it was better earlier" but Kopete has no problems, I still have that as "fallback"

I did manage to stop network-manager and then reconnected. No change in behaviour.

ktp-debugger still states:
mcd_kludge_transport_account_connection_cb: haze/icq/_3155656320 wants to connect, but we're offline; queuing it up

And I do not quite see why networkmanager would block? All other "network-aware" software such as browsers, KMail, Choqok, Skype, Kopete and so on works fine after I connect via command line wvdial.

I also think this worked in 0.5 version even though I was only testing using facebook-chat at the time. So to me this is 0.6 "regression".

there is some sort of connection to Networkmanager...

If I, after connecting to internet via wvdial, share my wireless as a "hotspot" this makes networkmanager state that I am "connected". Then kde-telepathy connects my accounts again... although the internet is actually connected via ppp wvdial command.

I think you need to look over this code as all other "network" apps I use do not have this issue

One possibility is that Telepathy itself is using NetworkManager directly, while KDE applications (which includes KMail), are using KDE Network Status. It uses both NetworkManager as well as other sources depending on how your system was compiled.

You can verify this by running the following command with just the wvdial connection open:

Code: Select all

qdbus org.kde.kded /modules/networkstatus status

If it returns '4' then KDE is aware that your system has a active network connection.

The shared backend (used by us, Empathy, Nokia N9s, Nemo) is only NetworkManager (and ConnMan) aware.
This is not under our control.

Even if KDE thinks you're online, if network manager does not you will not connect.

If network manager is not running when mission-control-5 (the IM backend) is started then it will not look at it when deciding whether to connect.

david_edmundson wrote:The shared backend (used by us, Empathy, Nokia N9s, Nemo) is only NetworkManager (and ConnMan) aware.
This is not under our control.

Even if KDE thinks you're online, if network manager does not you will not connect.

If network manager is not running when mission-control-5 (the IM backend) is started then it will not look at it when deciding whether to connect.

This is a weaker solution than doing what bcooksley suggests. I am certain I am not the only one who sits with "odd" usb modems that takes wvdial to connect as Networkmanager can not deal with them for whatever reason.

And it seems a bit strange to chose a solution that no other "network using" KDE software I have installed on my laptop is using. As noted Kopete works just fine, the whole KDEPIM set, any browser and so on. Why look at what Networkmanager thinks instead of KDE itself?

To me this is a bug and I will file one soon as I find time

david_edmundson wrote:The shared backend (used by us, Empathy, Nokia N9s, Nemo) is only NetworkManager (and ConnMan) aware.
This is not under our control.

Even if KDE thinks you're online, if network manager does not you will not connect.

If network manager is not running when mission-control-5 (the IM backend) is started then it will not look at it when deciding whether to connect.

I am just experiencing a very "hands-on" as to why this is not such a good solution as what other network-aware applications use.

Power just went, something that happens frequently here. Since I am on a laptop I can continue working. However, as I am not connected via wifi or networkmanager I will want to switch off wireless to save power.

As I had "tricked" ktp into thinking I am connected via Networkmanager by switching on my shared wireless (and how many users know how to set up the wireless for sharing??) ktp goes "offline" when I do this...

And for me that means in order to stay in touch with IM contacts it is back to Kopete

Just to clarify, the shared backend is something which is not KDE specific, and so it therefore cannot use KDE specific technology (which is what the D-Bus call I mentioned essentially is, as it is dependent on a certain KDE Daemon module being present). It is not directly developed nor under the control of KDE.

I do not know if it possible for KDE Telepathy to override the built in determinations made by the network systems in the shared backend unfortunately.