RNAT (Routable NAT)

Hi everybody,

Here I am again to show you another stuff which I’ve been spending some time to develop.  The RNAT, or Routable NAT.

This post is just an introduction to the RNAT project, since it is a very long subject.

Summarizing, I’ve started the RNAT development about one year ago. The main purpose was use it as my graduation final project. But after the presentation I realized that I could keep the project alive and turn it into a real and useful thing.

The real RNAT goal is to provide direct communication between hosts which are behind NAted networks by using two IP’s instead one. Like people say, one image is better than one thousand words:

[root@localhost ping]# ./ping
usage: ping [-LRdfnqrv] [-c count] [-i wait] [-l preload]
        [-p pattern] [-s packetsize] [-t ttl] [-I interface address]
        [-a RNAT Address] host

[root@localhost ping]# ./ping 200.200.200.200 -a 10.0.4.143
PING 200.200.200.200 (200.200.200.200 10.0.4.143): 56 octets data
64 octets from 200.200.200.200 - 10.0.4.143: icmp_seq=0 ttl=63 time=96.9 ms
64 octets from 200.200.200.200 - 10.0.4.143: icmp_seq=1 ttl=63 time=52.7 ms
64 octets from 200.200.200.200 - 10.0.4.143: icmp_seq=2 ttl=63 time=49.8 ms
64 octets from 200.200.200.200 - 10.0.4.143: icmp_seq=3 ttl=63 time=41.9 ms

--- 200.200.200.200 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 41.9/60.3/96.9 ms
[root@localhost ping]#

It is just a small piece of the RNAT project. To get more information visit the official project site.

http://rnat.sourceforge.net

Tiago

Playing with libmsn

The story:

I used to be fan of gaim (now pidgin) IM. It was my main IM software for years and every morning I used to checkout the bleeding edge version from svn to see the current development status. This daily procedure started to not happen anymore when I decided to try kopete at least once. The end of the story is that now I use only kopete to chat. (Yes, I know other IM clients, mercury, kmess, amsn, etc).

The big problem is that msn protocol version used in kopete is MSNP11, which is compatible with the current (MSNP15) protocol, is too old and does not support too many features, like Offline Messaging and Direct Connection on File Transfer.

The lack of features sometimes turns the use of kopete into a bad experience. The file transfer works too bad. It is common to not finish a started file transfer without even an error message to inform the user about the fail. We cannot blame msn protocol, since Mercury messenger works very well.

All I’ve described above have encouraged me to code a msn library, both to learn the msn protocol and exercise my programming skills which I’ve lost due to the lack of time to practice.

Using the open source principle, to not reinvent the wheel, I’ve downloaded libmsn from sourceforge site and started to study the protocol. Unfortunately the libmsn is MSNP8, which is highly deprecated, so I started porting it to the MSNP15 protocol. Now I want to see how far I can go in this porting process.

The current status is: Authenticating, Sending and receiving messages and nudges, Sending display pictures (not receiving yet), notifying the buddies status changes (current media, friendly name, and personal message), set own friendly name, sending messages while in hidden status, among others. Last week I started to develop the file transfer part. It is not working yet, but I’m almost there. As long as I progress the development I intend to create new posts. Probably the second stage is try to integrate libmsn to kopete. I know that there is someone coding it to kopete, but I don’t mind because I’m developing it to myself just to improve my knowledge in this area.

My thoughts about the msn protocol aren’t good up to now. The protocol is messy. Some commands are sent through notification server, some through soap requests to msn sites. The p2p protocol, used to send data through switchboard server, is hard to track. Some fields are in little endian form, some in big endian, some fields are not set on some packets, the communication stream changes depending the kind of data field, etc..

All these issues turn the coding a hard process, because it is not easy to find a logical way to classify the incoming p2p packets.

Anyway, I’m having a good time playing with libmsn and I hope I can release it as soon as possible. 🙂

Cheers

Tiago

First post!

Hi all,

this page was created in order to register my current researches involving computing and maybe a little bit of other subjects I like. I don’t know how often I’ll update it, but I hope I can do it frequently.

Thank you for visiting.

————————————–

Tiago