Hell Oh World!

Right now, the cvs version of ayttm looks pretty good. We've been able to get in YMSG16 support, MSNP15 support and a lot of fixes in the GUI and jabber. I finally got rid of the custom dialogs code in ayttm and Piotr has done a lot of work with the state/status messages. The netv2 code also seems to be looking quite good since nothing seems to be breaking in it of late.

There are a few filler functions that remain to be implemented in MSN so that it does not crash. Also, both yahoo and msn need file transfer and invitations -- I am not done with that either. I have been threatening to do a release for some time now, so I might just act out that threat in the coming weeks. So these are busy days.

First goal of getting yahoo working on YMSG16 is done. Read more about it in the ayttm journal. Roadmap for yahoo support is now:

1. Fix the little things
2. File Transfer

That will come in later. Most likely once netv2 merges into trunk. Now I will be shifting focus to MSN and other tiny protocols (livejournal, smtp, etc.) on netv2.

I finally finished writing a working implementation of the YMSG16 authentication as described in this article. The authentication seems to be working quite well, but nothing else does. The server still does not respond to the older binary type messages. So the next thing I tried was to wireshark the windows based yahoo messenger ( my employer provided the windows box for me :D ) and I found out two things:

• The Authentication probably is what is described in the carbonize site, but there looks to be a different way to get the initial challenge string
• All messages go to and from one server in the form of HTTP POST and responses

There some more cookies involved as well, which is what Adrian was probably talking about in the comment to my previous post. Thankfully, since ayttm is on YMSG12, we are still online unlike pidgin, so no need to rush in a fix for this just yet. That said, the popup says I have until August 15th till YMSG12 dies too. I need to see how pidgin has fixed this. Maybe the fix is much simpler than revamping everything to do what the windows YMSGR is doing.

Update: I was wrong. I sent the wrong message to the server after authentication — forgot to add the challenge digest, which is why it barfed on me. Work is on now for stuff after the auth :)

Ayttm needs to go on to YMSG15. So I decided to do a small test to see what could break if we just change the protocol version sent to Yahoo. So I advanced the protocol version from 0x00000c to 0x00000f in libyahoo2. Also, I enabled debugging in libyahoo2 so that it could dump packets that it did not recognize. Here's my brain dump of the little experiment:

• Some packet numbered as 0xef. Don't know what that is
• File transfer will change, as I had seen from the last time I had fixed file transfer for YMSG12
• Gennady Feldman had added some service codes into the libyahoo2 for YMSG13, which seem to be coming in due to the move to YMSG15. The 0xf0 and 0xf1 above are a result of that. Also, messages to rename groups and move contacts between groups seem to have changed
• I got a 0xf0 message, which seems to be a list of buddy statuses, including mine
• A 0xf1 message, which seems to be the complete list of buddies. So I don't really need to fetch them from cab.yahoo.com, do I?
• Another thing that seems changed but did not affect me this time around seems to be the login procedure. I'm planning to move to YMSG16 for that since I have more complete information on how it can be implemented.
• To get YMSG16, I need SSL. To get SSL, I need to update libyahoo2 to move to netv2. So obviously this needs to go into the netv2 branch

netv2 does not seem to be ready just yet, Philip had problems getting gmail to work with netv2. There's a bit of tightrope walking with multiple threads and SSL. Hopefully I can figure out what the deal is since almost everything is starting to use SSL. Does anyone want to get their hands dirty on netv2?

But couldn't I just open up libpurple and get that stuff in? Yes, but it won't be fun enough would it? :)

Finally! Here's how I went about it:

First, I wrote a simple program that downloads a page from http://billing.mahadiscom.in

#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BUF_SIZE 2048

int main(int argc, char *argv[])
{
    char *host="billing.mahadiscom.in";
    char *port="80";

    int n=0, iter=0;

    struct addrinfo hints;
    struct addrinfo *result, *rp;
    int sfd, s;
    char buf[BUF_SIZE];

    memset(&hints, 0, sizeof(struct addrinfo));
    hints.ai_family = AF_INET;
    hints.ai_socktype = SOCK_STREAM;
    hints.ai_flags = 0;
    hints.ai_protocol = 0;

    s = getaddrinfo(host, port, &hints, &result);
    if (s != 0) {
        fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s));
        exit(EXIT_FAILURE);
    }


    for (rp = result; rp != NULL; rp = rp->ai_next) {
        sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
        if (sfd == -1)
            continue;

        if (connect(sfd, rp->ai_addr, rp->ai_addrlen) != -1)
            break;  /* Success */
        else
            perror("connect");

        close(sfd);
    }

    if (rp == NULL) {   /* No address succeeded */
        fprintf(stderr, "Could not connect\n");
        exit(EXIT_FAILURE);
    }

    freeaddrinfo(result);   /* No longer needed */

    if(write(sfd, "GET /billinfo.php HTTP/1.1\r\n", 
            strlen("GET /billinfo.php HTTP/1.1\r\n") ) < 0 )
        perror("write1");

    if (write(sfd, "Host: billing.mahadiscom.in\r\n", 
            strlen("Host: billing.mahadiscom.in\r\n") )<0)
        perror("write2");

    if(write(sfd, "\r\n", strlen("\r\n") )<0)
        perror("write3");

    memset(buf, 0, BUF_SIZE);

    while((n = read(sfd, buf, BUF_SIZE-1)) >0) {
        printf("%s\n\n==========================\n\n"
            "%d bytes received (Iter %d)\n\n"
            "===============================\n\n", 
            buf, n, ++iter);
        memset(buf, 0, BUF_SIZE);
    }

    if (n<0)
        perror("error");

    return 0;
}

On first run, data came in at 1448 bytes per burst and then hung up in about 3 bursts. Then I connected to the UK based VPN and tried again. This time data came in at 1360 bytes per burst and the entire page got downloaded. I discussed this with Ranjith Rajaram at work and he told me about MTU, which affects this window size.

Sure enough, tun0 was configured with an MTU of 1412 while eth0 had an MTU of 1500. I modified the MTU for eth0 and presto! It worked! I'm still wondering how this works for Windows systems without any such interference.

PS: Yes, the code's really dirty... but that's not the point.

Firefox (or is it google?) seems to think that ceo.maharashtra.gov.in is a suspicious site. It apparently hosts malicious software which gets installed without user content.

The site runs on Linux, so surely it couldn't be ActiveX stuff right? Or maybe google going bonkers.

Update: Someone pointed out that I'm an idiot and I need to double-check facts before I post. I agree with him/her.

So I wrote my first upstream patch for something that is not ayttm ;) Let's see if it gets accepted though -- the issue has been rotting for seven years now.

The MSEB billing site opens only when I access it from a UK based proxy. It does not work when I access it from home -- be it from my Airtel connection or from Sify. The same was true for SBI card today, although it is normally accessible from home; unlike MSEB, where I have been trying to pay my bills online unsuccessfully for months before I stumbled on to a UK proxy.

My web host finally got its act together after telling me that RSS feeds not showing up on my website were a programming fault and opened up outgoing connections from my site to my journal. They were quite active in following up -- they even called back when my call got dropped. Quite nice.

Yes, I'll stop with my silly sense of humour now.

I was finally able to commit what I started thinking about and working on during FOSS.in back in November last year. Ayttm now starts its connections in a different thread. This eliminates the hang-ups that one may experience when the application is looking up a hostname. The proxy code was also not really with it. I wonder if anyone has tested to see if it works in the first place. For that matter, after I'm done with it, I hope someone tests it as well ;)

So here's what I did. Every time a connection is requested, The connector creates a gthread for the connection and then adds an idle function source (see g_idle_add() in glib) to see if that connection has completed or not. once the connection thread returns, the idle handler continues and calls the connection callback, thus returning control to the connection requestor.

Like that made a lot of sense ;)

The bigger goal is to make this into a more serious networking wrapper library. Next step now is to add SSL support into the library. Then instead of linking it statically, I wonder if it would be a good idea to make it a separate module altogether. It might be necessary since nothing in the core uses SSL, so statically linking libproxy into the core won't work at all.

Oh, and the name libproxy just doesn't cut it anymore. I guess it should be called libnet or something once I'm through with it :)