This icq, this damned icq.. doesn't log in! As i expected, though. There is several bugreports about such problem: Debian squeeze Bug #630254 Ubuntu Bug #683076 Though, with disabled both SSL and clientLogin pidgin works for me, but this is not good, right? Error messages and pidgin versions in these two bugreports is not the same, but i suppose the problem is the same: incorrect log in server addresses. And patch mentioned in Ubuntu's bugreport comment 18 (and 21) Pidgin ViewMTN/diff between revisions [98ca3d09..] and [99e26392..] fixes this. But Pidging 2.7.3 from Debian squeeze still uses wrong server addresses - 'api.screenname.aol.com:443' and 'api.oscar.aol.com:443', - when trying to log in with SSL and/or clientLogin enabled: .. (14:09:53) proxy: Attempting connection to 205.188.93.135 (14:09:53) proxy: Connecting to api.screenname.aol.com:443 with no proxy (14:09:53) proxy: Connection in progress (14:09:53) proxy: Connecting to api.screenname.aol.com:443. (14:09:53) proxy: Connected to api.screenname.aol.com:443. .. (14:09:54) proxy: Attempting connection to 205.188.100.136 (14:09:54) proxy: Connecting to api.oscar.aol.com:443 with no proxy (14:09:54) proxy: Connection in progress (14:09:54) proxy: Connecting to api.oscar.aol.com:443. (14:09:54) proxy: Connected to api.oscar.aol.com:443. .. and get the infamous error (14:18:07) oscar: startOSCARSession response statusCode was 401: <?xml version="1.0" encoding="UTF-8"?> <response xmlns="http://developer.aim.com/xsd/aim.xsd"><statusCode>401</statusCode><statusText>Authentication Required. Connection not approved for 239.. . Error code from BOSS 7. statusDetailCode 7</statusText><statusDetailCode>7</statusDetailCode><data><ts>1310379488</ts><upgradeData></upgradeData><betaData></betaData></data></response> (14:18:07) connection: Connection error on 0x98b1e68 (reason: 16 description: You have been connecting and disconnecting too frequently. Wait ten minutes and try again. If you continue to try, you will need to wait even longer.) From the aforementioned patch, seems like for SSL now i should use: --- libpurple/protocols/oscar/oscarcommon.h 0bc9985d11166bdfb5d992dae2a00784269e379e +++ libpurple/protocols/oscar/oscarcommon.h c0c1c79bb1873b915a8e9c90a4d103107d18d257 .. +#define ICQ_DEFAULT_LOGIN_SERVER "login.icq.com" +#define ICQ_DEFAULT_SSL_LOGIN_SERVER "slogin.icq.com" .. and for clientLogin (this is OpenAuth server address, right? (AOL Developer Network/Authentication for Desktop Clients..)): --- libpurple/protocols/oscar/clientlogin.c f66d45ff55ef44bed415ddbd25e47f2d60c8d5ea +++ libpurple/protocols/oscar/clientlogin.c 6e0dab1b983a036019a31a3e89eeaf3f0284df21 .. +#define AIM_LOGIN_HOST "api.screenname.aol.com" +#define ICQ_LOGIN_HOST "api.login.icq.net" +#define AIM_API_HOST "api.oscar.aol.com" +#define ICQ_API_HOST "api.icq.net" .. I don't know how to fix server addresses for clientLogin without patching source code, but, i think, i can simple fix SSL support - with stunnel. Here is proposed way: pidgin will connect to 127.0.0.1:5190 and then stunnel forwards its connection over SSL (terms correct?) to proper server (slogin.icq.com:443). pidgin config (in GUI Accounts/Manage Accounts -> Modify) should look like: server: 127.0.0.1 port: 5190 Unchecked "Use SSL" Unchecked "clientLogin" and stunnel config: ; Protocol version (all, SSLv2, SSLv3, TLSv1) sslVersion = SSLv3 chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 ; PID is created inside the chroot jail pid = /stunnel4.pid ; Some performance tunings socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ;compression = zlib ; Some debugging stuff useful for troubleshooting debug = 7 output = /var/log/stunnel4/stunnel.log ; Use it for client mode client = yes ; Service-level configuration [oscaricq] accept = 127.0.0.1:5190 connect = slogin.icq.com:443 ; vim:ft=dosini There is also a small problem with stunnel - sometimes it can't resolve dns name: 2011.07.11 15:58:49 LOG7[4691:3075046256]: oscaricq permitted by libwrap from 127.0.0.1:53065 2011.07.11 15:58:49 LOG5[4691:3075046256]: oscaricq accepted connection from 127.0.0.1:53065 2011.07.11 15:58:49 LOG3[4691:3075046256]: Error resolving 'slogin.icq.com': Neither nodename nor servname known (EAI_NONAME) 2011.07.11 15:58:49 LOG3[4691:3075046256]: No host resolved 2011.07.11 15:58:49 LOG5[4691:3075046256]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket Here (Jaervosz' Burrow): stunnel unable to resolve hostnames suggested two possible fixes. I can either use 'delay = no' option in the config (/etc/stunnel/stunnel.conf in debian squeeze) to tell stunnel to resolve DNS names _before_ entering chroot, or i can use 'delay = yes' option (see Note2 below) in the config (this is default for stunnel4, it seems) to tell stunnel to resolve DNS names _after_ entering chroot and bind mount /etc (or only required files - resolv.conf) into stunnel's chroot jail (note, that without bind mount stunnel will not be able to resolve DNS names from inside chroot). Here is explanation from stunnel.org/FAQ: How can I delay DNS lookups until connect time? Add the following to your stunnel configuration file: delay = yes And here is bind mount example: root@shilvana:~# touch /var/lib/stunnel4/etc/resolv.conf root@shilvana:~# mount /etc/resolv.conf /var/lib/stunnel4/etc/resolv.conf -o bind root@shilvana:~# /etc/init.d/stunnel4 restart That's it, now enable account in pidgin and all should work. Note1. Note, also, that if you use stunnel with 'delay = no' option and stunnel starts very early when network is not available yet, than it can't resolve DNS names, and you need to restart it later. Note2: Note, that 'delay = yes' option must be in the service section of the config file. Otherwise, it'll not work!UPD4. 'Note2' note added.
UPD3. 'Note1' note added.
UPD2. Some additional clarifications about configuring stunnel to proper resolve DNS names.
UPD1. Update about configuring stunnel to proper resolve DNS names.
Комментариев нет:
Отправить комментарий