Equipment Support > Hardware By Brand > Linksys > Technical Details about AIM file transfer

Technical Details about AIM file transfer

While hex editing with usage of packet sniffers and editors might be possible for some people as a workaround solution, it certainly isnt convenient or seamless for anyone, and is pretty much beyond the capacity of the average consumer in terms of capability.

ALG code is a possibility, however, its limited essentially to providing a seamless experience to only one client behind the Linksys (or other) NAT gateway with AIM, even if different clients behind the NAT change the connection port (the ALG code would only work on predefined ports, without becoming unduly inefficient and slowing down all traffic), and of course, it requires more firmware coding and code, taking up more firmware space, and, if AOL changes AIM's connection protocol system, the ALG code becomes useless, unless Linksys spends more time fixing it, etc etc.

The "real" solution to this issue, is for AIM to adopt usage of UPnP IGD NAT Traversal.

This will allow the AIM client to get the WAN (internet) IP address from the UPnP IGD (Linksys) and embed it in the packet data, thus allowing the remote AIM client to connect to the local AIM client using the WAN IP address.

Furthermore, multiple clients behind the UPnP IGD will be able to make simultaneous file transfer or other peer to peer connections, assuming the AIM clients are coded so that they use dynamic port allocation and forwarding/reservation through the UPnP IGD.

After all, AOL Time Warner is part of the UPnP Forum.

Where is their UPnP-enabled AIM client at?

C og it ate,
H of b ra u

reply to voidvector
I don't know how to use sniffer.. as you decribed above, I added 5190 in my aim file transfer port and also added to my routers forwarding port.. still I cant get any file transfers.. I also I downloaded the firmware upgrade from linksys website..

Do you have any suggestions?
what can i do about it?
Thanks

reply to voidvector
So.. question. I'm using a BEFW11S4 V2 wireless router, using NAT as well, and I've got it working fine. I can send and receive files from both users out on the internet, and my roomate. I'm using AIM 5.1, with no modification of the port. I am, however, using DMZ for my computer. If your explaination is correct, why would mine be the exception to the rule? I've heard about this AIM problem numerous times, but maybe my router is a model that works with AIM fine.

Why is your BEFW11s4 working fine for AOL IM transfer and mine not? I'm going to upgrade everybody to 5.1 client and see if that helps. I have a V2 router with the latest software. It worked for some people, but not others, and then it just stopped working at all. Very puzzing.

-Bob

reply to voidvector
Hofbrau is right "The "real" solution to this issue, is for AIM to adopt usage of UPnP IGD NAT Traversal."
Linksys Forum FAQ: »Linksys FAQ »Why doesn't AIM work through the router?
--
Evans C, MCP BEFW11S4 Site

reply to bobcov
My AIM screen name is cybrboi2k2, if you want to compare settings.

Thanks for the IM. I'll use it shortly. I took the box off of the NAT and gave it an address directly on the Internet. Clients behind the NAT could still not send files until I set port triggering with 5190-5193 for both in and out. People on direct dial or without nat can get to it fine. Sometimes it just stops in the middle of a transfer. My guess is that the triggering is getting hosed by other people on the network who are also just doing IM chats. THey too would need 5190 and that might be getting in the way. NOt sure.

reply to voidvector
Out of curiosity, which packet sniffer program did you use to edit these packets on the fly? (Please send me a reply at my e-mail address, bhishan@hotmail.com)

Thanks for your help.

reply to xyrx
Becuase it only affects people that are BOTH behind NAT firewalls. As long as one is not, it's all good.

reply to voidvector
On a related note, I have the same problem with other software.... the PC software gets it's IP address from the socket (192.168.1.x) and sends that to a server. Of course it doesn't work....

Fortunately for me, I was using some openSource software and was able to modify the software to be SNMP aware... now what it does is:

Get IP address from socket.
Is it routable?
Yes - Done
No - Get WAN IP address from the MIB-2 SNMP enabled router (which BEFSR81 is)

(192.168.0.0/16 and others are non-routable)

This method should work for other SNMP aware routers, I'm not using Linksys proprietary MIB information.

Now my software correctly tells the other software what the "public" IP address is...

AIM could do a similar thing... and if SNMP fails, it could use an http access to a "give me my address" script. AIM should do that when it's starting up so it only needs to do it once per session.
--
There are 10 types of people in the world; those who understand binary and those who don't.

"On a related note, I have the same problem with other software.... the PC software gets it's IP address from the socket (192.168.1.x) and sends that to a server. Of course it doesn't work...."

Indeed.

"Fortunately for me, I was using some openSource software and was able to modify the software to be SNMP aware... now what it does is:

Get IP address from socket.
Is it routable?
Yes - Done
No - Get WAN IP address from the MIB-2 SNMP enabled router (which BEFSR81 is)

(192.168.0.0/16 and others are non-routable)"

Well, ok, so it requires an MIB-2 SNMP capable NAT gateway.

How pervasive in the gateway market are MIB-2 capable gateways?

Anyway, good so far...you have the WAN IP of your gateway...

"Now my software correctly tells the other software what the "public" IP address is..."

Ok, thats still fine..though a bit complex..

"AIM could do a similar thing... and if SNMP fails, it could use an http access to a "give me my address" script. AIM should do that when it's starting up so it only needs to do it once per session."

Well, ok, you have a way of getting the WAN IP, and thats good.

But you are missing one very important thing.

How do you get AIM, or any other app using your method, to tell the other person, the correct WAN port to connect to?

And for that matter, how do you make sure the correct WAN port in the NAT gateway, is forwarding to the listening port on your LAN device?

You dont. Not without lots of additional manual configuration of the NAT gateway, etc etc.

See the problem?

UPnP IGD NAT Traversal solves BOTH those problems:

1) Allows for LAN devices/applications to automatically obtain/know the correct and current WAN IP address of the NAT Gateway.
2) Allow for the automatic creation of port forwarding/mapping entries in the NAT gateway as required by the application/device.

You can get the WAN IP address all day long using other "automatic" methods, but you still dont get around the port forwarding issues: You will still have to manually access the admin pages of the gateway to setup the appropriate forwarding entries, and then once again, when the connection is done.

UPnP IGD NAT Traversal does all of this seamlessly automatically and efficiently - no user intervention required.

Obviously, the best solution, is that currently developed connectivity apps like AIM, is to start using UPnP IGD NAT Traversal.

However, for legacy apps, personally, i suggest you code an application that uses the UPnP information and functionality present in many NAT gateways now, to enable connectivity for legacy non-UPnP enabled apps.

(Hey, there's a smart business opportunity for someone to ponder. Think about it - you could code an application that uses UPnP to "help" other applications traverse the NAT by providing the app with the correct WAN IP and also create port forwarding/mapping entries in the NAT gateway on behalf of the application. Hint Hint. You could perhaps call the "helper" application "UPnP Now!". Imagine if this "UPnP helper" functionality were built into the OS...after Microsoft bought up your idea..and paid you a nice sum of money for it...assuming they havent already thought of it themselves..)

C og it ate,
H of br au

reply to voidvector
Sorry my last post confused you... as you seem to have seized upon one point, I'll try to explain my position more clearly, using your terminology of client/server/host.

As you no doubt well know, for the initial file transfer connection packet, the trip from the host to the server is where the source IP header field gets automatically translated to the public WAN IP by NAT. Using conventional NAT, an embedded IP would *not* be translated during this time, which is where the problem lies. If the server simply took the address in the source IP header field and sent that to the client instead of the non-translated embedded one, file transfer would work correctly through properly configured conventional NAT.

As for UPnP vs Forwarding/Triggering, there are pros and cons to both methods. Not going to go off topic and start a debate about that here.

Ok that was entertaining. In the future please stick to the topic of this thread. I don't have the time to sit here and split threads apart because certain people do not stick to the topic. Any future off topic posts will be simply deleted. The topic of this thread is Technical Details about AIM file transfer not embedding IP addresses into packets. That discussion as off topic as it is can be found here.
--
Live fast, die without regrets

Lanik,

In that case my apologies, though I believe those posts were very on topic in that we were discussing technical details about AIM file transfer, with one aspect being IP addresses.

My post above would also be 'off topic' in that case, and can be moved to the locked thread. I was posting it at the same time as you were pulling everything apart and I didn't realize what was happening until after it was submitted

reply to voidvector
This is what I have been doing for about 2 years now to make it work....

1. Open netmeeting
2. Enter an IP addy in example 64.108.1.1
3. Hit the phone icon.
4. Hit cancel and close netmeeting
5. Direct connect to anyone.

This method works for me all the time.

I have done it using port forwarding and not using it and it works both ways. Give it a try tell me what happens. If you want to try it on me my aim is eddyis20

reply to voidvector
Also wanted to add that I am not using DHCP DMZ.

Block WAN Request: enabled (works either or)
Multicast Pass Through: Disable
IPSec Pass Through: Disable
PPTP Pass Through: Disable
Remote Management: Disable

doesn;t work for me eddy

i, like bhishanhotmailcom, am wondering what program can do this. a packet sniffer is not enough, because a sniffer doesn't necessarily have the ability to change packets. anyway, can anyone point me in the right direction? thanks.

reply to Coniac
This doesn't work, nor does Trillian.