Opened 12 years ago

Closed 12 years ago

#1452 closed defect (duplicate)

networkmanager integration broken

Reported by: PierreOssman Owned by: seanegan
Milestone: 2.2.0 Component: libpurple
Version: 2.0.0 Keywords:
Cc:

Description

This is copied from the sourceforge tracker. The issue still remains in 2.0.0.

I really like this new integration with NetworkManager. It makes using gaim on a laptop really fantastic.

In beta 6 however, things stopped working. It communicates with NM (I see "waiting for network") but it doesn't really do anything. So it doesn't reconnect when I move from one connection to another, meaning I have to wait for a connection reset/timeout or manually disconnect and reconnect.

Problem is for all protocols.

Also:

This broke in revision 17811, as backing out that change fixes the problem:

http://gaim.svn.sourceforge.net/viewvc/gaim?view=rev&revision=17811

I think the new code added in that revision is supposed to keep the connection alive in case network detection mistakenly detects a disconnect. However, it doesn't work for me under linux with networkmanager.

And:

Ok, I think I understand. The idea behind the new code was "If we get told that our network connection has been disconnected, we'll try to actually use the connection to make sure. If we've really been disconnected, we'll get an error. If not, it's a false alarm and we shouldn't do anything".

Unfortunately this logic doesn't work under linux because send() on a TCP socket will succeed even if there's no network connection. So the error doesn't occur and gaim gets stuck thinking it has a connection when it actually doesn't. Even re-establishing the network connection does not fix this, so gaim stays in a zombie state until you reconnect manually.

This code should be backed out or #ifdef'd out under linux.

Change History (3)

comment:1 Changed 12 years ago by MarkDoliner

  • Owner set to seanegan

Sean, this guy's logic seems reasonable to me. What do you think?

comment:2 Changed 12 years ago by lschiere

  • Milestone set to 2.1.2

comment:3 Changed 12 years ago by seanegan

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

Closing as a dupe of #181

send() will succeed, but the OS will timeout it out when it doesn't get its ack. I don't think we want to force the connections closed for people who have flaky wireless, for instance.

The main problem was that the UI reflected a connected state, which is probably bad. We'll think of a better way to handle this when 181 is addressed.

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!