This morning I finally got a chance to sit down with a CVS manual and learn enough about the system to successfully commit the ability to send files over ICQ into Gaim 1.4.0 (oldstatus) as well as the HEAD branch. (For those of you who are very experienced with CVS, please don't laugh too hard at my ignorance).

Then the fun began. I decided to compile Gaim version 2cvs. After gcc had done it's thing, I opened up Gaim 2 (which is looking very good, by the way) and attempted to send a file. Result: Nothing. No. Thing. Apparently, the code I just committed to two different branches of Gaim and announced as working, did not in fact work. Not cool. After doing a packet capture to try to see what was happening, I noticed that all the protocol messages were getting churned out correctly, but the connection still wasn't happening. I decided to take a look at my local network. As it turns out, my Linksys Wireless B router (actually, one I borrowed from my friend Matt) had decided that there was no reason to retain the DHCP client tables for more than about 30 seconds. Ocassionally, it would just forget which IP went with which computer. What does it matter where all those packets go anyway? I made a quick run to Best Buy and grabbed a D-Link Wireless G router. Oddly enough, it can retain DHCP client tables indefinitely. File sending over AIM and ICQ worked again. (Deep sigh of relief.)

Another up for today: OSCAR file transfers for two parties on the same subnet should be up and running soon. An OFT file transfer makes 3 IP addresses available to the file receiver: verified, proxy, and client. Currently, Gaim makes use of the verified IP. For a party behind a firewall, this is usuall the address of their router. The client IP address is the address the client thinks it has. For instance, on my network, my router is 69.150.254.186 (the verified IP for a file transfer), but my Linux box is assigned an address of 192.168.0.3 by the router (the client IP). Likewise, my Windows box has an IP of 192.168.0.101. Using the verified IP in this situation fails since the router doesn't know anything about a file transfer. However, using the client IP address works since both computers are on the same network. So far, this has only been tested by replacing the code referencing the verifiedip with the clientip. The next step is to change the code so that it first attempts to connect with the verified IP and then uses the client IP only as a backup. This should be good news for all those on corporate and campus networks.