Problem with iChat AIM - Multiple login, log out

Question

I am having a recurring problem with my iChat. Every time I try to log into AIM when I'm home, it rapidly logs in and logs out, and then tells me that I have loged in too many times and need to wait a few minutes to try again. I have tried the delete .plist file solution, but this did not work. This is a very very annoying problem, because I love using iChat when it actually works.
I have also tried using other IM applications, and they all work flawlessly... whats up iChat? Any Ideas?
R.V.

Answer 1

Hi,
The problem is not limited to Netgears.
In fact I never had the issue with the Netgear I had.
It is an extremely well documented issue with Zyxel devices since iChat 2
134 response to Searching for Zyxel across iChat 2 and 3 forums.
It sort of goes like this.
At one time routing modems or routers could only do Port Forwarding
This involved pointing one port at One IP (Computer)
You could not forward a Port to two computers (IPs)
Since then manufacturers have added in stating Protocols as well as Ports to open.
So as UDP and TCP protocols tend to be the ones on ports above 1024 you have some apps that have both Protocols in use and in some cases on the same port.
It does seem that this business of not being able to Forward a Port twice also effects those were you ow have to state Protocols as well.
iChat uses two ports twice.
Port 5190 is used to do the AIM Log in and basic Text chats on TCP
It used UDP to Send Files, Pics-in-Chats (Direct IMs) and certain Buddy List feedback and Group chats (Chatrooms).
Less effected is the Bonjour Port 5298
The regular posters have long since held the view that the AIM servers sometimes can not handle all the login and text traffic on just port 5190 (ICQ is also owned by AOL and on this same port).
We Suggest port 443 for several reasons.
However it is mainly as this is below the threshold of 1024
There are in fact 65535 ports that could be in use.
Most domestic devices have the port up to 1024 open to all computers connected.
This means Web Browsing (Port 80) and Mail (ports 110, 443, 567, 955 and others) are below this threshold and will work "out-of-the-box"
As any firewall included in the device or on a Mac with Tiger or Earlier the port 443 is likely to be opened for a Mail App (It is also used in Web Browsing to Secure sites like Banks and the Apple Discussions Log in page) so that several apps can use the port.
It is worth noting that the Leopard Firewall works differently in allowing the ports associated with an App on an Certificated (by app) basis so there is no Piggy-backing.
On the SPI (Or if you have DOS) Front.
These features tend to be Threshold based.
DOS comes from the time when so called Hackers got together to all try the same web site/page and repeatedly refresh the page so that the server got lots of incoming requests.
This overloaded the server and brought down the whole web server and the computer it was on lost connection to the internet as a whole.
DOS protection looks to see if this "Too Much Data, Too Quickly" scenario is happening and will cut that one port (In the case of iChat 4) that it is happening on.
(iChat Can send LOTS of data)
SPI tends to try and filter things in a different manner by checking if the data looks valid.
IT seems in some cases it can not keep up with the amount of data iChat can stream and consequently cuts the connection the same as DOS does.
Both are dependent on how fast your Buddies Processor is, how fast their Internet Connection.
(Some Buddies can send only 15fps of a 640 X 480 pixel pic other can manage 30fps or twice as much data)
This is somewhat augmented (or not) by how fast you can accept data both over your Download speeds and your processor dealing with it.
Therefore it can seem to be an intermittent problem depending on the circumstances of the connection of that chat.
My Netgear had DOS and It had it Off (Along with the Ping Blocking)
My Current Sagem Fast 2504 has only the Block to Internet Pings settings which is Off
So on the whole Experience and Practice.
9:44 PM Friday; March 27, 2009