bitlbee 3.0.3 will not connect to msn

[msoulier@…]

I am using Debian stable. With 1.2.8 I have no problem connecting to MSN, although my current status always shows as available. I tried building 3.0.3 and running that, but it will not connect to MSN. Well, it connects, and then fails to do anything from there.

20:41:17 -!- mode/&bitlbee [-C] by root
20:41:17 <@root> Password accepted, settings and accounts loaded
20:41:17 <@root> Trying to get all accounts connected...
20:41:17 <@root> msn - Logging in: Connecting
20:41:17 <@root> twitter - Logging in: Connecting
20:41:17 -!- twitter_msoulier [twitter_msoulier@twitter] has joined &bitlbee
20:41:17 -!- ServerMode/&bitlbee [+v twitter_msoulier] by bear
20:41:17 <@root> twitter - Logging in: Getting contact list
20:41:17 <@root> msn - Logging in: Connected to server, waiting for reply
20:41:17 <@root> msn - Logging in: Transferring to other server
20:41:17 <@root> msn - Logging in: Connected to server, waiting for reply
20:41:20 <@root> msn - Logging in: Authenticated, getting buddy list
20:41:20 <@root> twitter - Logging in: Getting initial statuses
20:41:20 -!- mode/&bitlbee [+C] by root
20:41:21 <@root> twitter - Logging in: Logged in
20:42:32 <@msoulier> account list
20:42:32 <@root>  0 (msn): msn, msoulier-microsloth@digitaltorque.ca (connecting)
20:42:32 <@root>  1 (twitter): twitter, msoulier (connected)
20:42:32 <@root> End of account list
20:43:17 <@root> msn - Login error: Connection timeout
20:43:17 <@root> msn - Logging in: Signing off..
20:43:17 <@root> msn - Logging in: Reconnecting in 5 seconds..

and so on and so on...

Meanwhile, 1.2.8 from Debian works, and other clients work.

[pezz <bitlbee@…>]

Exact same problem here, just started happening today.

Bitlbee 3.0.3 on Arch Linux.

[nullscan]

Same for me here, as of today bitlbee 3.0.3 times out after authentication but before (or while) getting buddy list from msn. Debian testing.

[luke@…]

Same issue... using 3.0.1-6.fc13

[Wilmer van der Gaast <wilmer@…>]

Yes, I can reproduce it too, which will hopefully make fixing it easier.

[anonymous]

FreeBSD - BitlBee 3.0.1

Happened today. Impossible to reconnect.

Update to 3.0.3

Same problem.

[gcr@…]

Same here, exact same error. Arch Linux, bitlbee 3.0.3-4.

[Wilmer van der Gaast <wilmer@…>]

I think it's safe to say this is a common problem so no need for more AOLing guys and gals. :-) I saw MS is returning a HTTP 405 now for whatever reason. If someone already knows more than that, please do share.

[msoulier@…]

Please note my original comment in the report that 1.2.8 *does* work. msnlib for Python also works.

[lockyc@…]

It was working on the debian package version, but stopped working when i installed 3.0.3

[wchen]

Same problem here.
BitlBee 3.0.3
API version 030003
Linux 2.6.32-34-generic-pae #77-Ubuntu SMP Tue Sep 13 21:16:18 UTC 2011 i686 GNU/Linux

Keeps doing this:
08:37 <@root > msn - Logging in: Connecting
08:37 <@root > msn - Logging in: Connected to server, waiting for reply
08:37 <@root > msn - Logging in: Transferring to other server
08:37 <@root > msn - Logging in: Connected to server, waiting for reply
08:37 <@root > msn - Logging in: Authenticated, getting buddy list
08:39 <@root > msn - Login error: Connection timeout
08:39 <@root > msn - Logging in: Signing off..
08:39 <@root > msn - Logging in: Reconnecting in 900 seconds..

[anonymous]

This issue is also working with jabber and google chat.

Debian/arm

[anonymous]

A temporary workaround is to build with libpurple :

$ ./configure --purple=1

[wilmer]

Yup, 1.2.8 with the old MSN module and libpurple will work. 3.0.x currently do not. I'm on a holiday in Hong Kong now and frankly got better things to do than diving into MSN Messenger internals. This is what I know:

This request, which used to work:

POST /abservice/SharingService.asmx HTTP/1.0
Host: contacts.msn.com
Accept: */*
User-Agent: BitlBee bzr-devel-821
Content-Type: text/xml; charset=utf-8
SOAPAction: http://www.msn.com/webservices/AddressBook/FindMembership
Content-Length: 2173
Cache-Control: no-cache

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <ABApplicationHeader xmlns="http://www.msn.com/webservices/AddressBook">
            <ApplicationId xmlns="http://www.msn.com/webservices/AddressBook">CFE80F9D-180F-4399-82AB-413F33A1FA11</ApplicationId>
            <IsMigration xmlns="http://www.msn.com/webservices/AddressBook">false</IsMigration>
            <PartnerScenario xmlns="http://www.msn.com/webservices/AddressBook">Initial</PartnerScenario>
        </ABApplicationHeader>
        <ABAuthHeader xmlns="http://www.msn.com/webservices/AddressBook">
            <ManagedGroupRequest xmlns="http://www.msn.com/webservices/AddressBook">false</ManagedGroupRequest>
    ....removed lots more XML vomit

And also the other SOAP request done at login time, /abservice/abservice.asmx / ​http://www.msn.com/webservices/AddressBook/ABFindAll , get a HTTP 405 "Method not allowed" response. I can't really find details on what it means and probably it could be anything. Someone (which might be me but only if I'm bored tonight) should see how these requests are done differently by other clients.

[nullscan]

Would it be possible that Microsoft allows the POST you do on the SharingService.amsx URI do be done only via https since yesterday? Using pidgin with MSN protocol (not WLM) and forcing HTTP method on the server i get an https conversation after the name resolution of local-bay.contacts.msn.com.nstatic and right after that before anything else an SSLv2 (instead of v3 i noticed in bitlbee but i guess that is OK) certificate exchange. If i find some spare time later i will try to hack around the bitlbee code to switch the conversation to SSL unless you have found something else and i am way off with my assumptions :)

[valiouk@…]

The problem is with the request that wilmer has shown. MSN is currently responding with a redirect to local-bay.contacts.msn.com for this request. I have fixed it (quickly and dirty) for myself by changing every occurence of contacts.msn.com with local-bay.contacts.msn.com in protocols/msn/soap.h and recompiling.

[anonymous]

Seems that the http_client.c code doesn't handle 301 responses properly. I'm vaguely trying to debug it, but I'm not familiar with that code. Anyone looking into it or shall I proceed further ?

[anonymous]

The quick fix works for me too.

[anonymous]

patch to bitlbee 3.0.3:

diff -rupN bitlbee-3.0.3.old/protocols/msn/soap.h bitlbee-3.0.3/protocols/msn/soap.h --- bitlbee-3.0.3.old/protocols/msn/soap.h 2011-06-12 08:53:51.000000000 -0300 +++ bitlbee-3.0.3/protocols/msn/soap.h 2011-11-09 21:35:56.000000000 -0200 @@ -115,7 +115,7 @@ int msn_soapq_flush( struct im_connectio

"<wst:RequestType>​http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue</wst:RequestType>" \ "<wsp:AppliesTo>" \

"<wsa:EndpointReference>" \

• "<wsa:Address>contacts.msn.com</wsa:Address>" \

+ "<wsa:Address>local-bay.contacts.msn.com</wsa:Address>" \

"</wsa:EndpointReference>" \

"</wsp:AppliesTo>" \ "<wsse:PolicyReference xmlns=\"http://schemas.xmlsoap.org/ws/2003/06/secext\" URI=\"MBI\"></wsse:PolicyReference>" \

@@ -198,7 +198,7 @@ int msn_soap_oim_send_queue( struct im_c

"</soap:Body>" \

"</soap:Envelope>"

-#define SOAP_MEMLIST_URL "​http://contacts.msn.com/abservice/SharingService.asmx" +#define SOAP_MEMLIST_URL "​http://local-bay.contacts.msn.com/abservice/SharingService.asmx"

#define SOAP_MEMLIST_ACTION "​http://www.msn.com/webservices/AddressBook/FindMembership"

#define SOAP_MEMLIST_PAYLOAD \

@@ -233,7 +233,7 @@ int msn_soap_memlist_request( struct im_

int msn_soap_memlist_edit( struct im_connection *ic, const char *handle, gboolean add, int list );

-#define SOAP_ADDRESSBOOK_URL "​http://contacts.msn.com/abservice/abservice.asmx" +#define SOAP_ADDRESSBOOK_URL "​http://local-bay.contacts.msn.com/abservice/abservice.asmx"

#define SOAP_ADDRESSBOOK_ACTION "​http://www.msn.com/webservices/AddressBook/ABFindAll"

#define SOAP_ADDRESSBOOK_PAYLOAD \

[necropresto]

i forgot the code block.

diff -rupN bitlbee-3.0.3.old/protocols/msn/soap.h bitlbee-3.0.3/protocols/msn/soap.h
--- bitlbee-3.0.3.old/protocols/msn/soap.h      2011-06-12 08:53:51.000000000 -0300
+++ bitlbee-3.0.3/protocols/msn/soap.h  2011-11-09 21:35:56.000000000 -0200
@@ -115,7 +115,7 @@ int msn_soapq_flush( struct im_connectio
                "<wst:RequestType>http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue</wst:RequestType>" \
                "<wsp:AppliesTo>" \
                    "<wsa:EndpointReference>" \
-                       "<wsa:Address>contacts.msn.com</wsa:Address>" \
+                       "<wsa:Address>local-bay.contacts.msn.com</wsa:Address>" \
                    "</wsa:EndpointReference>" \
                "</wsp:AppliesTo>" \
                "<wsse:PolicyReference xmlns=\"http://schemas.xmlsoap.org/ws/2003/06/secext\" URI=\"MBI\"></wsse:PolicyReference>" \
@@ -198,7 +198,7 @@ int msn_soap_oim_send_queue( struct im_c
   "</soap:Body>" \
 "</soap:Envelope>"
 
-#define SOAP_MEMLIST_URL "http://contacts.msn.com/abservice/SharingService.asmx"
+#define SOAP_MEMLIST_URL "http://local-bay.contacts.msn.com/abservice/SharingService.asmx"
 #define SOAP_MEMLIST_ACTION "http://www.msn.com/webservices/AddressBook/FindMembership"
 
 #define SOAP_MEMLIST_PAYLOAD \
@@ -233,7 +233,7 @@ int msn_soap_memlist_request( struct im_
 int msn_soap_memlist_edit( struct im_connection *ic, const char *handle, gboolean add, int list );
 
 
-#define SOAP_ADDRESSBOOK_URL "http://contacts.msn.com/abservice/abservice.asmx"
+#define SOAP_ADDRESSBOOK_URL "http://local-bay.contacts.msn.com/abservice/abservice.asmx"
 #define SOAP_ADDRESSBOOK_ACTION "http://www.msn.com/webservices/AddressBook/ABFindAll"
 
 #define SOAP_ADDRESSBOOK_PAYLOAD \

[pezz]

Patch works for me, Arch Linux, bitlbee 3.0.3.

[wilmer]

changeset:devel,823 Many thanks!

No clue if this is going to work forever but it's good to at least have a workaround. I'll try to get this rolled out to testing and im at least.

[Huittinen Massive]

For me it is ​http://local-sn.contacts.msn.com/abservice/SharingService.asmx dunno if this has changed in last 4 hours, but local-bay certainly does not work for me.

[Huittinen Massive]

Plausibly 'bay' is MS DC in bay area and 'SN' maybe in San Antonio. And depending on your source IP, you're redirected to one of them (or maybe even more options). So probably we should continue to use contacts.msn.com and just follow redirects.

[anonymous]

Following the redirects is offcourse the correct implementation. But just to add a data point: from Europe (Belgium) it's also redirecting to local-bay.contacts.msn.com.

[wilmer]

So Mr. anonymous, did you actually see 301s coming in? Because I didn't while debugging this. http_client does support redirects although the code for it *is* a bit crappy..

There's also some SOAP-specific redirect mechanism which may be used here. I do (or used to) have support for it in the Passport auth. code, should be easy to extend that. But I simply haven't seen any redirect..

[Ced]

Freebsd 8.2 amd64, Bitlbee 3.0.3

I have applied the patch above and it doesn't seem to have fixed the issue on my side.

i still get

root: msn - Logging in: Connecting
root: msn - Logging in: Connected to server, waiting for reply
root: msn - Logging in: Transferring to other server
root: msn - Logging in: Connected to server, waiting for reply
root: msn - Logging in: Authenticated, getting buddy list
root: msn - Login error: Connection timeout
root: msn - Logging in: Signing off..

I tried with local-bay and local-sn, no difference. Not sure if it's revelant but im from Belgium.

[PowerKe]

(I posted comment 24) I did see 301's coming in for local-bay.contacts.msn.com and have recompiled my client with that hostname. Unfortunately, my C++ isn't very good to follow the code easily and I also have no IDE installed for C++. It seems that the redirects get re-queried but with a GET request instead of a POST request and a wrong 'Host:' header. I'm also mailing you a tcpdump of the 'getting buddy list'.

[valiouk@…]

my 2 cents

POST /abservice/SharingService.asmx HTTP/1.0
Host: contacts.msn.com
Accept: */*
User-Agent: BitlBee 3.0.3-1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.msn.com/webservices/AddressBook/FindMembership"
Content-Length: 2193
Cache-Control: no-cache

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><ABApplicationHeader xmlns="http://www.msn.com/webservices/AddressBook"><ApplicationId xmlns="http://www.msn.com/webservices/AddressBook">CFE80F9D-180F-4399-82AB-413F33A1FA11</ApplicationId><IsMigration xmlns="http://www.msn.com/webservices/AddressBook">false</IsMigration><PartnerScenario xmlns="http://www.msn.com/webservices/AddressBook">Initial</PartnerScenario></ABApplicationHeader><ABAuthHeader xmlns="http://www.msn.com/webservices/AddressBook"><ManagedGroupRequest xmlns="http://www.msn.com/webservices/AddressBook">false</ManagedGroupRequest>
... lots more XML vomit :)

HTTP/1.1 301 Moved Permanently
Cache-Control: private, max-age=0
Keep-Alive: true
Content-Length: 832
Content-Type: text/xml; charset=utf-8
Location: http://local-bay.contacts.msn.com/abservice/SharingService.asmx
X-MSNSERVER: BAYCDP9011139
X-AspNet-Version: 4.0.30319
Date: Wed, 09 Nov 2011 16:17:15 GMT
Connection: close

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><ServiceHeader xmlns="http://www.msn.com/webservices/AddressBook"><Version>16.02.2225.0001</Version><CacheKey>14r2;dfJeZE6jK/esId6mQ1MTXiR2J8kyQP0lmy1KTYcXt+Kegbp054gCbDuO/4xDEBNOCc+LC2hvsOez6PwYToWcdf8QU69WgJ9e83Ye2y8BeEW9qFn6HE2V6gQTiga9XdndBj0ulGw/w3tJL1ppMDNSQxWZFQLxo2N+oVfA7vPivq4=</CacheKey><CacheKeyChanged>true</CacheKeyChanged><PreferredHostName>proxy-bay.contacts.msn.com</PreferredHostName><SessionId>ABCH.e2788cd7-18f5-4b13-8b16-c1e211b99be5</SessionId></ServiceHeader></soap:Header><soap:Body><FindMembershipResponse xmlns="http://www.msn.com/webservices/AddressBook" /></soap:Body></soap:Envelope>

[Wilmer van der Gaast <wilmer@…>]

Ahh!

I think I get it now. What's happening most likely is that I'm getting a 405 to whatever BitlBee already redirected to. http_client does redirects and the soap module wouldn't even be aware of that fact.

And then probably it's doing some GET/POST mixup..

[wilmer]

Yep, it's switching from post to GET which should not be done for 301s. Okay, we have a root cause, thanks for your 2 cents. :-)

[wilmer]

changeset:devel,156

I already thought I did this differently before. Looks like POST redirection was buggy though, leaving out POST data..

[IvánJr]

The patch given by Señor Necropresto works for me: 3.0.3 on Debian 6.0.3 (i386).

Saludos!

[anonymous]

msn works fine with bitlbee 3.0.3-5 on Arch Linux

[anonymous]

Updated to bzr-823 but still doesn't work unless I configure it with --purple=1.

[Nuno J. Silva <nunojsilva@…>]

Anonymous (c34), wilmer appears to have found the issue (HTTP 301 on GET, POST, BREW, or other request is always followed by GET, while -- I guess -- it should be followed by the same kind of request), but he made no change yet in the codebase to fix the redirect issue (probably because he wants to be sure fixing it does not break anything else).

He added a partial workaround that will fix it for the people who get redirected to local-bay.contacts.msn.com, which is included in revision 823 -- so I guess you're being redirected to another server.

I guess you *can* use the patch, you just need to find out which server are you being redirected to and hardcode its address the same way [1] does.

[1] ​http://bugs.bitlbee.org/bitlbee/changeset/devel%2C823

[anonymous]

MSN drop-kicked me off last night around midnight, and it has been trying to reconnect all day long (every 900 seconds). It says it authenticated, getting buddy list... then login error: connection timeout. Is this problem related?

[bwelmers]

I did the s/contacts.msn.com/local-bay.contacts.msn.com/g thing on soap.h. It works for some MSN accounts but not for all (despite using one outgoing IP address of the server). It the problem indeed resists in the http_client.c functionality, it should be fixed there.

[Nuno J. Silva <nunojsilva@…>]

Anonymous (c36), it is. If you see the log in the report, above, these are the MSN-related messages there. Microsoft changed something on their side and now the buddy list request (a SOAP request) times out.

bwelmers: I did not try it myself (yet?), but keep in mind it's more of a *workaround*. I don't know what's the best way to find the right server address, I guess there's some debugging feature (which was changed in revision 822 to print the headers from SOAP requests), but I'd advise finding out what's the right address for failing accounts.

You can also try reverting the change that enforces GET requests, but I guess there must be some reason why that has not been undone (yet?).

[Ced]

Freebsd 8.2 amd64, Bitlbee 3.0.3

I finaly got it working on my end without the libpurple option. This is what i used.

<wsa:Address>omega.contacts.msn.com</wsa:Address>
#define SOAP_MEMLIST_URL "http://local-sn.contacts.msn.com/abservice/SharingService.asmx"
#define SOAP_ADDRESSBOOK_URL "http://local-sn.contacts.msn.com/abservice/abservice.asmx"

[anonymous]

Same problem here. I have 3 MSN accounts and all of them got disconnected in the past couple of days.

After reading this thread I decided to test the soap.h changes and here is what I noticed:

When changing the 3 contacts.msn.com entries to local-bay.contacts.msn.com I managed to get 1 of my 3 accounts connected. Looking in wireshark logs I noticed some redirect entries to local-sn.contacts.msn.com. So I tried these entries in the soap.h file and now the 2 other accounts got connected. So from what I can see the server to be used depends on the account. Changing the soap.h file will thus not resolve the issue for everyone.

So from my experience I would guess the best way forward is to make the "static" entries in the soap.h entry variable based on the redirect requests send out by the MSN server. However since I'm no developper I'm not sure if this is something that can be easily implemented.

I hope this helps to resolve the issue as I like bitlbee alot ;-)

[Wilmer van der Gaast <wilmer@…>]

Thanks for all your thinking guys. :-) Yes, I already figured the redirection target depends on the account, not on your physical location. It makes sense, apparently your account data is just stored in a specific datacenter instead of magically replicated everywhere. So on the first connection attempt you get forwarded to whatever datacenter has your actual data.

The fix will be to make lib/http_client.c do redirects on POSTs properly. I'm not sure if I'll have time to do this too soon..

[anonymous]

i think that bitlbee should have a config file to change the urls to the msn servers. in this way, a recompiling will be unnecesary. what do you think about that?

[Wilmer van der Gaast <wilmer@…>]

I'm not going to spend time on temporary solutions either. If anyone else is interested in doing that, feel free.

[bwelmers]

The next patch on http_client.c will fix the POST thing and replaces the Host: header in the new request. Without replacing the Host header the MSN servers won't respond properly either. I'm not really familiar with C so the string manipulation won't be the most beautiful one you have ever seen.

--- Downloads/bitlbee-3.0.3/lib/http_client.c	2011-06-12 13:53:51.000000000 +0200
+++ PRJ/bitlbee/bitlbee-3.0.3/lib/http_client.c	2011-11-12 17:35:44.000000000 +0100
@@ -353,6 +353,7 @@ got_reply:
 			/* A whole URL */
 			url_t *url;
 			char *s;
+			char *s2;
 			
 			s = strstr( loc, "\r\n" );
 			if( s == NULL )
@@ -369,12 +370,15 @@ got_reply:
 			}
 			
 			/* Okay, this isn't fun! We have to rebuild the request... :-( */
-			new_request = g_malloc( req->request_length + strlen( url->file ) );
+			new_request = g_malloc( req->request_length + strlen( url->file ) + strlen(url->host) );
 			
 			/* So, now I just allocated enough memory, so I'm
 			   going to use strcat(), whether you like it or not. :-) */
 			
-			sprintf( new_request, "GET %s HTTP/1.0", url->file );
+			if (strstr(req->request, "POST") == req->request)
+				sprintf( new_request, "POST %s HTTP/1.0", url->file );
+			else
+				sprintf( new_request, "GET %s HTTP/1.0", url->file );
 			
 			s = strstr( req->request, "\r\n" );
 			if( s == NULL )
@@ -384,9 +388,19 @@ got_reply:
 				g_free( url );
 				goto cleanup;
 			}
+			new_host = g_strdup( url->host );
 			
+			/* Replace Host: header */
+			s2 = strstr(s, "\r\nHost:");
+			s2 = s2 + 2;
+			*s2 = 0; // terminate string s temporary
 			strcat( new_request, s );
-			new_host = g_strdup( url->host );
+			strcat( new_request, "Host: ");
+			strcat( new_request, new_host);
+			*s2 = 'H'; // restore string
+			s = strstr(s2, "\r\n"); // next header
+			strcat( new_request, s );
+			
 			new_port = url->port;
 			new_proto = url->proto;
 			

[Richard Burnison]

I've included a working patch below; however, it may need some vetting.

It allows Bitlbee to follow HTTP redirects using the original HTTP method, which, as I understand, is a bit closer to the behaviour defined for 301 and 302 HTTP response codes in the RFC specifications.

Further, the patch allows the ability to follow absolute redirections.

=== modified file 'lib/http_client.c'
--- lib/http_client.c   2011-04-18 14:14:28 +0000
+++ lib/http_client.c   2011-11-12 19:34:16 +0000
@@ -368,14 +368,25 @@
                                goto cleanup;
                        }
                        
-                       /* Okay, this isn't fun! We have to rebuild the request... :-( */
-                       new_request = g_malloc( req->request_length + strlen( url->file ) );
+                       /* Okay, this isn't fun! We have to rebuild the request... :-(
+                          The new request will have the same amount of memory as the original,
+                          allowing for a safe reuse of the original HTTP method. Further,
+                          the addition of a new host may change the overall size. */
+                       new_request = g_malloc( req->request_length + strlen( url->file ) + strlen(url->host));
                        
+                       int method_len = strcspn(req->request, " ");
+                       char *method = g_malloc(sizeof(char) * method_len + 1);
+                       strncpy(method, req->request, method_len);
+                       strcpy(method + method_len, "\0");
+
                        /* So, now I just allocated enough memory, so I'm
                           going to use strcat(), whether you like it or not. :-) */
                        
-                       sprintf( new_request, "GET %s HTTP/1.0", url->file );
+                       sprintf( new_request, "%s %s HTTP/1.0", method, url->file );
                        
+                       g_free(method);
+
+                       /* Strip off the first original line. */
                        s = strstr( req->request, "\r\n" );
                        if( s == NULL )
                        {
@@ -385,7 +396,18 @@
                                goto cleanup;
                        }
                        
-                       strcat( new_request, s );
+                       /* Add everything up to Host header. */
+                       char* host_starts = strstr(s, "Host: ");
+                       strncat(new_request, s, strlen(s) - strlen(host_starts));
+
+                       /* Add new Host header. */
+                       strcat(new_request, "Host: ");
+                       strncat(new_request, url->host, strlen(url->host));
+
+                       /* Add everything after original Host header. */
+                       char* host_ends = strstr(host_starts, "\r\n");
+                       strcat(new_request, host_ends);
+
                        new_host = g_strdup( url->host );
                        new_port = url->port;
                        new_proto = url->proto;

[Nuno J. Silva <nunojsilva@…>]

wilmer already fixed it in the source some hours ago, see changeset:devel,824

The fix works here.

[wilmer]

Err. changeset:devel,824 . Maybe I really should've posted a comment here. :-P

Anyway, together with changeset:devel,825 this is now fixed for real. The code's getting messy but it will do for now.

Releasing 3.0.4 would be nice, but I need to fix #838 first. :-/

[Jess]

How do we update the 3.0.3 code to use this new fix? I'm pretty new at bug reporting and patching ;)

[wilmer]

Replying to Jess:

How do we update the 3.0.3 code to use this new fix? I'm pretty new at bug reporting and patching ;)

Hopefully you run Debian or Ubuntu or so, in which case the answer is very simple:

​http://wiki.bitlbee.org/Packages

[Jess]

Thanks for the reply wilmer, but I use a compiled version (got a shell on a gentoo box) so I have to compile manually.

Is this patch now incloded in the 3.0.3 release or do I have to fiddle with SVN?

Jess x

[Wilmer van der Gaast <wilmer@…>]

"bzr branch ​http://code.bitlbee.org/bitlbee/" should download it. But if you don't have bzr available or if you have problems rebuilding the documentation, you can download tarballs from ​http://code.bitlbee.org/tarballs/?C=M;O=D

[anonymous]

Replying to wilmer:

Releasing 3.0.4 would be nice, but I need to fix #838 first. :-/

If that takes too long, could you upload a version with this fix to the debian repositories in the mean time?

Thanks in advance

[anonymous]

Replying to anonymous:

Replying to wilmer:

Releasing 3.0.4 would be nice, but I need to fix #838 first. :-/

If that takes too long, could you upload a version with this fix to the debian repositories in the mean time?

Thanks in advance

I'd love this as well. I've stopped using bitlbee for the last few days because of this bug.

[Wilmer van der Gaast <wilmer@…>]

The whole reason I'm not doing a release is because I do not have time.

Debian users can just use snapshots from ​http://code.bitlbee.org/debian/ so there's certainly no reason to spend time on that.

[anonymous]

Are there any nightly equiv for RPMs?

[Wilmer van der Gaast <wilmer@…>]

Nope.. If someone can give me scripts to build them in a chroot or so I could try that though.

[pezz]

I don't get why a 3.0.4 version based on this fix can't be released due to bug #838 -- a weird Twitter time bug -- not being fixed?

Releasing a 3.0.4 with this official fix (which basically makes an entire protocol work properly - MSN) will help rolling release distros like Arch and others that want a stable release to base on.

[Xelnor]

Replying to Jess:

Thanks for the reply wilmer, but I use a compiled version (got a shell on a gentoo box) so I have to compile manually.

Is this patch now incloded in the 3.0.3 release or do I have to fiddle with SVN?

Jess x

Hi Jess,

For gentoo, the 3.0.3-r1 version (added to portage on monday) contains this exact patch, which fixes the issue :)

-- Xelnor

[wilmer]

@pezz: It's not a time bug, it's a bug where it stops fetching updates entirely.

Distro packagers can release a 3.0.3-2 or something with this fix.

What I don't get is how many more times I have to explain people that I do not have time right now.

[luke@…]

Should be able to get the RPM for FC[15/16/17] at ​http://koji.fedoraproject.org/koji/buildinfo?buildID=273776

Am running bitlbee-3.0.3-6.fc15.i686.rpm and msn works again.

[Jess]

Replying to Xelnor:

Replying to Jess:

Thanks for the reply wilmer, but I use a compiled version (got a shell on a gentoo box) so I have to compile manually.

Is this patch now incloded in the 3.0.3 release or do I have to fiddle with SVN?

Jess x

Hi Jess,

For gentoo, the 3.0.3-r1 version (added to portage on monday) contains this exact patch, which fixes the issue :)

-- Xelnor

I don't have access to portage :(

The latest rzr thingy has fixed it for me. Thanks peeps :) Jess