Opened 5 years ago

Closed 19 months ago

Last modified 14 months ago

#14917 closed patch (fixed)

"1 account was disabled because you signed on from another location"

Reported by: ngroot Owned by: MarkDoliner
Milestone: 2.10.12 Component: AIM
Version: 2.10.1 Keywords:
Cc: rnoltemy

Description

When attempting to log on to AIM, I frequently get the error message in the summary: "1 account was disabled because you signed on from another location". I am logged in briefly (~1 sec) when I re-enable the account (if I have offline messages, they will come through), and then kicked off with the error.

Looking at Wireshark captures of this vs. the AIM client (which works), I notice that it only makes two connections to the BOS (one of which has no traffic), while Pidgin makes 5 (one of which also has no traffic).

As a note, I am accessing an AIM proxy (compliance, don't you know) via an HTTP proxy (yay corporate networks). I don't believe either of these is the issue (since the official client works), but that's why there are sanitized names and IP addresses in the debug log, as well as SSL warnings.

Any idea how this might be fixed? The official client, Miranda, and Trillian can all connect, so I'm tempted to say this is a defect.

Attachments (2)

purple-debug.log (16.1 KB) - added by ngroot 5 years ago.
oscar_connection_fix.patch (1.5 KB) - added by kakaroto 2 years ago.
Commit fix for AIM connection issue

Download all attachments as: .zip

Change History (13)

Changed 5 years ago by ngroot

comment:1 Changed 5 years ago by MarkDoliner

The debug log looks fairly normal to me. Or, as normal as I would expect, considering the proxy funkiness. I see it using old-style login (non-client login). I see the stuff you described: AIM connections proxied through your HTTP proxy and then through your AIM gateway thing. SSL certs being rewritten.

I only see 1 connection for the BOS server type. There are also 4 other connections to other server types (auth, buddy art, chat nav, and alert). It seems likely to me that this problem IS caused by a weird interaction between Pidgin and your AIM gateway, but I don't know what. Maybe your AIM gateway doesn't like that Pidgin connections to these other server types? I would expect official AIM clients to connect to at least the buddy art server. I could see how maybe chat nav and alert are extraneous.

comment:2 Changed 5 years ago by ngroot

Sorry for the terminology confusion; I was using "BOS server" in the sense that it's used here: http://iserverd.khstu.ru/oscar/login.html . I.e., the server to which we connect after we get authorized. In the log, that's the one with address OURAIMBOSIP, rather than OURAIMPROXYIP, to which we connect initially.

Is there a reason that new TCP connections are created over which data for different SNAC families are passed? Like I said, the official clients don't appear to do this; there are only two connections to the BOS server, and one doesn't have any data passing over it.

Looking at the logs, I'm wondering if it's the second connection of type 0x10 (SSBI) that's triggering the "logged in from elsewhere" disconnect. Is there a way to have it only make one of these connections at a time, or pass multiple families of SNAC data over the same FLAP connection?

comment:3 Changed 5 years ago by MarkDoliner

The reason for multiple TCP connections for different SNAC families is that not all servers support all types of requests. Different classes of requests require connections to different servers. Rr at least, that's how it has been historically--it's possible this has changed and Pidgin is making extra connections when it doesn't need to. For each connection that we make, the server tells us what SNAC families it supports by sending us a 0x0001/0x0003 SNAC.

comment:4 Changed 5 years ago by ngroot

Empirically, it would seem that Pidgin is making connections when it doesn't need to, since other clients have full functionality with only two active connections (one to the login server, and another to the BOS). Moreover, it seems to be connecting to the same server twice for the same family of SNACs; see lines 127 and 173 in the debug log.

comment:5 Changed 5 years ago by MarkDoliner

I agree, it does seem like the extra connections might not be necessary, and connecting to the same server twice seems wrong.

comment:6 Changed 3 years ago by rnoltemy

This is an old ticket, but I would like to add a comment. Our company uses Pidgin and likes it, but our requirements to archive by the SEC is paramount. We use Symantec IM archive tool which they stopped supporting two years ago. Very few players in the IM Archive space, but each of them has a problem with this second connection to the same server. Is there any way to get an option, or some sort of advanced setting in the config file to prevent that second connection from occurring ?

Changed 2 years ago by kakaroto

Commit fix for AIM connection issue

comment:7 Changed 2 years ago by kakaroto

I've found the bug that's causing the connection issue and I've just attached a patch for it. I've explained in length the bug and reason for the disconnection to happen in the commit description of the patch above.

This was done against the tip of the 3.0 development tree but it should apply just the same to the 2.x branch. I hope this gets fixed for 2.10.12.

Thanks.

comment:8 Changed 2 years ago by Robby

  • Milestone set to 2.10.12
  • Type changed from defect to patch

comment:9 Changed 19 months ago by salinasv

  • Milestone changed from 2.10.12 to Patches Needing Review

Moving to Patches Needing Review so we can take a look at kakaroto's patch.

comment:10 Changed 19 months ago by Youness Alaoui <kakaroto@…>

  • Milestone changed from Patches Needing Review to 3.0.0
  • Resolution set to fixed
  • Status changed from new to closed

(In [0ddd5118b8eb]):
Fix for AIM when using gateway proxies

The issue here is that smoe gateway proxies (such as smarsh.com) will terminate a connection to some services (such as the BART service in the case with the Smarsh proxy) at which point the flap_connection gets scheduled for termination and will then check if there are any LOCATE services connections available, if there are none, it will sign out. The problem is that the flap_connection_getbytype call will only return connections that are 'connected' (passed auth) but since the MD5 authentication method, it never sets any connection to connected, so it thinks there are no LOCATE connections and signs out. This should fix other bugs that might be affected by the API call flap_connection_getbytype returning NULL when it shouldn't. This should fix issue #14917 : https://developer.pidgin.im/ticket/14917

Reviewed by Jorge Villasenor <salinasv@…> Fixes #14917

comment:11 Changed 14 months ago by Robby

  • Milestone changed from 3.0.0 to 2.10.12

This was also went into 2.10.12.

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!