Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#8545 closed defect (invalid)

Pidgin 2.5.4 Always says "waiting for network connection"

Reported by: Deagon Owned by: lschiere
Milestone: Component: unclassified
Version: 2.5.4 Keywords:
Cc:

Description (last modified by Deagon)

Whenever I open pidgin it will always say "available - Waiting for network connection" but won't sign my qq or msn accounts in. I have to go to manage accounts, disable both accounts and then re-enable both accounts before i can sign in. Status will still remain the same though.

Additional info I use a proxy (Telefónica O2 UK) my "network connection" is a Sony ericsson W880i. I have never had this issue before with any other pidgin version.

OS. Is Windows Xp professional SP3

Change History (14)

comment:1 Changed 10 years ago by Deagon

  • Description modified (diff)

comment:2 Changed 10 years ago by odyssey

I have the similar problem with Pidgin 2.5.5 (ICQ account) on Windows XP SP2 and PPPoE-based Internet connection (without proxies). However I failed to find a reliable workaround. Disabling and re-enabling an account does not work for me at all. Deleting an accound and re-creating it helps sometimes, sometimes it requires to restart Pidgin to help and sometimes it doesn't help. It became a major obstacle to the use of Pidgin for me.

When the problem happens, both network monitor and firewall report no network activity and no outbound connections from Pidgin though the status changes from "Offline - Waiting for network connection" to "Available - Waiting for network connection".

comment:3 Changed 10 years ago by PhobosK

This issue is really very annoying :( I confirm this behavior on Ubuntu Intrepid and Pidgin 2.5.6 also. I know on Unix it has to do with the Network Manager configuration but the suggested "workarounds" (in other bug reports, that strangely are in state closed) are unacceptable because:

  1. Using NM for network handling is not always possible. There are some situations that require the network connection to be handled manually without the NM.
  2. Removing totally NM breaks a lot of things on Ubuntu, so this is not an option.
  3. Having Pidgin compiled without NM support is tricky and requires some knowledge of howto do such things on Linux. Besides it has to be done in a way that the native package system is not affected which needs even more knowledge. Not all users have all that knowledge and they do not need to have it.

So this NM "aware" code in Pidgin should be improved and I think there should be an option in the preferences dialog for the user to enable/disable this support.

comment:4 follow-up: Changed 10 years ago by deryni

Most users don't want or need to know what NM is, so an option is just going to be confusing.

The fact that NM sucks, the fact that NM doesn't support all possible networking configurations, etc. are all not pidgin issues, we don't make your distro build with NM support. If you don't want it built that way complain to them about it.

There isn't anything we can do (as far as I know, nor in any way I might imagine) about the case where NM knows about one connection and not another but you are using the secondary connection it doesn't know anything about. It would seem reasonable to me to ignore NM entirely when it knows about no connections at all (if we can ask it to tell us that, which I have to imagine we can).

The fact that removing NM breaks Ubuntu is also not our problem nor is it something we can do anything about, again talk to Ubuntu if you don't like that.

I have more than once rejected the suggestion from people that we need to fix pidgin to always honor the NM status (even for manual status changes) because it would completely break pidgin for people for whom NM is broken. I would be more than happy to yank all NM support as well, but when it works people like it so we can't really do that either.

There really isn't much we can do to make this better for many of the cases where it currently fails.

comment:5 follow-up: Changed 10 years ago by PhobosK

Well actually i did expect a bit different answer... smth like "It's not our fault at all, so if you do not like the way Pidgin works, do not use it" :D ... Anyway... To be constructive: Though i am not familiar with the NM part of Pidgin's code i think it should be not so hard to disable it via a hidden option at runtime. Because making an app's behavior dependent on compile time options is a bit inconvenient. Anyway... it is really up to you... just like resolving other "small" problems like the one with the custom gif smilies in which case the problem is not in you again :)

comment:6 Changed 10 years ago by PhobosK

BTW for users that experience the described problem there is a dirty workaround that can be implemented via a script (and depending on the implementation probably you will need a small change in the /etc/sudoers file):

You need to restart NM first: sudo /etc/init.d/NetworkManager restart And then run Pidgin: pidgin

comment:7 in reply to: ↑ 5 Changed 10 years ago by darkrain42

Replying to PhobosK:

Though i am not familiar with the NM part of Pidgin's code i think it should be not so hard to disable it via a hidden option at runtime. Because making an app's behavior dependent on compile time options is a bit inconvenient.

Pidgin 2.6.0 will, I believe, support ignoring NM at startup via a command-line option ("-f, --force-online force online, regardless of network status")

comment:8 follow-up: Changed 10 years ago by deryni

True, I had forgotten about that argument, but that is as effective a solution as "change status manually". The force_online function should also be available via DBus for people who want to tweak it during a pidgin instance, but there is no way to undo it currently and it still will require a status change (which should currently already work to ignore NM, though will possibly not cover disconnections).

It isn't hard to allow people to disable dependence on NM at runtime, it just makes little sense and works around the problem rather than trying to make people want to fix it.

comment:9 in reply to: ↑ 8 Changed 10 years ago by PhobosK

Replying to deryni:

It isn't hard to allow people to disable dependence on NM at runtime, it just makes little sense and works around the problem rather than trying to make people want to fix it.

Yes I agree with that, but still it is a kind of solution till it is fixed. And btw changing the status manually in this particular case (the described bug) doesn't work at all. Right now the situation is very funny. I am using a stun server in the config, and in the logs pidgin states: account-no network connection, dns-resolved stun server, got public IP address... Maybe a kind of solution is to check connectivity via periodically trying to get a HEAD answer from some urls like google etc...

comment:10 follow-up: Changed 10 years ago by deryni

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

It is rather amusing that we appear not to check the network availability before trying to resolve a configured stun server, but not particularly relevant to the current discussion.

What do you mean changing status doesn't work at all? pidgin does not try to connect your accounts even when it had been previously "waiting for network" when you change to an online status? Hm... it would appear that you are correct, apparently we made status changes check the network availability before connecting an account in October of last year. I have no idea why we did that (other than that we definitely should not ignore NM there but doing so was a convenient NM-sucking workaround).

Polling for a network connection is not an option.

It would appear that in 2.5.6 the only option for people who cannot get rid of NM and do not have NM working correctly is to trick pidgin into not seeing the DBus system bus (by emptying the appropriate environment variables) and that 2.6.0 will provide the -f flag to pidgin which tells pidgin to ignore NM.

Unfortunately what that means is I still don't believe there is any actual bug here that we can do anything about and as such I am going to close this ticket.

comment:11 in reply to: ↑ 10 Changed 10 years ago by PhobosK

Replying to deryni:

What do you mean changing status doesn't work at all? pidgin does not try to connect your accounts even when it had been previously "waiting for network" when you change to an online status? ....


Yes this is exactly what i mean and what happens if you try manually to change the status after a "waiting for network" problem is detected..

Polling for a network connection is not an option.


Yeah i agree it is quite bad as a workaround. Bad that other tools that can give a status for a connection require root privileges on most platforms also.

It would appear that in 2.5.6 the only option for people who cannot get rid of NM and do not have NM working correctly is to trick pidgin into not seeing the DBus system bus (by emptying the appropriate environment variables) and that 2.6.0 will provide the -f flag to pidgin which tells pidgin to ignore NM.


It seems a reasonable enough way to "fix" this problem, though i suppose it will bring other problems in pidgin too, but i will give it a try.

comment:12 in reply to: ↑ 4 Changed 10 years ago by odyssey

Replying to deryni:

The fact that NM sucks, the fact that NM doesn't support all possible networking configurations, etc. are all not pidgin issues

I still don't believe there is any actual bug here that we can do anything about and as such I am going to close this ticket.

The problem is, the reporter faced this issue on Windows XP that has nothing to do with both NM and DBus. So closing this issue means that

  • Ubuntu users should consider it an NM issue
  • Windows users should consider it a Windows issue

Do I get it right? :)

comment:13 Changed 10 years ago by Deagon

Ohh wow, I completely forgot about this ticket. It was Corrupt TCP/IP Stack that caused the issue for Pidgin on my Netbook.

And I completely agree with you 'odyssey' "Windows users should consider it a Windows issue"

I haven't personally encountered the Network Manager issue on my Debian 5.0 Machine at home. Funny how overall I have had less that one 6th the issues with DEB than XP ;)

comment:14 Changed 10 years ago by deryni

I believe our NLA (Network Location Awareness) code for Windows is less well tested (by virtue of being newer if nothing else) than our NM code is, so it is possible that there may be an actual issue there (but I don't know nearly enough to say and Deagon seems to indicate at least his problem was a Windows problem). Other than that, yes, the issue lies with NM and NLA/Windows.

I realize that isn't exactly the sort of resolution one might hope for and that is unfortunate, but I really just don't see what more we can do (other than by making the NM/NLA code into plugins which would then require distributions to force/default them to loaded and let people unload them to disable them).

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!