XIFF Connection works on one computer and not others


I have half-resolved my previous trouble with the Error 401 that I posted below, however now I have some new issues with the same errors.

Basically jabber.org was not working properly, so I started logging into usuc.dyndns.org, and that seemed to solve the the Error 401 problem.

However, I now try to login from other computers and it throws me the previous Error 401 on those.

Does anyone know why the connection works with one computer and not with another?

On all computer’s im logging in with the same 2 accounts by the way.

Any help at all would be greatly appreciated, thanks in advance.


A quick update, if this helps at all.

I have tested now on 3 computesr at my place (laptop, comp1, comp2), and someone else’s computer elsewhere.

comp1 and comp2 share a landline, with 2 ip’s. the xiff flash chat connects from comp1, but not comp 2.

comp1 is running winxp pro, and comp2 is running win2000pro.

laptop is on someone else’s wireless connection in my building, and it fully functions.

so i doubt its an ip issue, but still cant figure out why it would work on one computer and not another.

again, any help would be greatly appreciated.


Another update.

I have a new ejabberd server setup now, and am running into the same issues.

I have now tested with 8 different computers located around the place.

The same issue is still present though, as the same 401 Error pops up instantly on the same computers it did before.

I have had friends login from the dominican, hong kong, and canada, and they were all successful.

So far 2 computers, one running XP and one 2Kpro immediately receive an Error 401 message. One of these is in the same house on the same connection as another computer that successfully logs in.

Does ANYONE know what could possibly be causing this?

thanks in advance,


OK I figured it out i think.

There is an incompatibility with Flash Version !!!

The computers that were failing ALL had this version of flash. <----

The one’s that worked that i checked included v9.0.45.0 and v9.0.47.0

Are there any suggestions on how to contact adobe or someone that can fix this problem, or find out exactly what in the new version is causing these errors.


Sorry to keep plastering this post, but its not like anyone else really posts anything :stuck_out_tongue:

Here is an update on the crap adobe has done.


AND one more update.

I have tried everything with these new policy files, and nothing works.

If anyone can test this and get it to work, and let me know, that would be greatly greatly appreciated.

This is driving me nuts.


I’ve had similar issues and it’s based on the flash cross domain configuration for access. The standard port is 5229. If the request takes longer than 3 seconds to download the crossdomain policy then the connection is considered invalid. This is a standard enforced in the flash security sandbox by Adobe. It looks like, based on this post: http://www.igniterealtime.org/community/message/170141#170141, that they’re combining the crossdomain request into the standard socket port.

Thanks for the reply, glad someone is around.

I have spent the past few hours figuring this out, and have gone through basically all the documentation of the socket updates made in version 124 and 115.

And well the conclusion is best explained in a quote from their site.

“These two rules can be summed up in a simple statement: under the strict socket rules, every socket connection requires permission from a socket policy file.”

Those rules are as follows:

1 ) A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file.

  1. HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain.xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host.

Extra Notes:

If a host serves a socket policy file from port 843 (a socket master policy file), strict socket rules will be applied for the entire host. This is true regardless of the contents of the policy file; even if the socket master policy file is empty, or declares the meta-policy all, the host will still use strict socket rules. All socket connections to this host will require permission from a socket policy file, which will most likely be the same socket master policy file that is triggering the transition to strict socket rules. This is the usual mechanism that host administrators should use to opt into strict socket rules.

If an HTTP server on port 80 declares a URL meta-policy in its master policy file at /crossdomain.xml, then that master HTTP policy file will not authorize socket connections to the same host. This configuration activates only one of the two strict socket rules for its host—the rule about SWF files connecting to their own hosts is unaffected.

If a non-master socket port serves a socket policy file, strict socket rules will be applied for that particular port. All socket connections to this port will require permission from a socket policy file, which will most likely be the same socket policy file that is being served from this port. An occasional unintended consequence of this rule is described in the section on immediately strict sockets: if a socket port 1024 or higher serves a socket policy file that does not list its own domain, then SWF files from that domain, which previously were permitted to connect without a policy file, will be unable to connect.

Anyway you kinda get the point. Luckily for openfire users I understand it serves xmlsocket//: policy files no problem now.

As for my ejabberd server…haven’t explored that yet…



For openfire users:

  • Add Security.loadPolicyFile(“xmlsocket://”+ server +":5229"); before xmppSocketConnection.connect() method
  • Make sure to open port 5229 in your firewall settings


Just jumped in to check this out, and noticed people are still replying to my posts. I think I made too many posts, so when in one I said I had resolved all issues, most other posts seemed still open.

I’ve long resolved all socket connection / permission issues. And my Flash CS3 XMPP Chat program has long been complete and fully functional.

I might have some Flash Player 10 compatibility questions coming up soon though… as I’m starting to notice new errors (400) at login for people using FP10.

Cheers, and thanks for the replies anywayz…



I have the same problem as the one you had. I read all your posts. Finally you said that you solved it. Then my question is pretty simple: “how did you do to solve that nasty problem???”

I would really appreciate your help because I tried everything I could and it still doesn’t work properly.

You are basically my last hope!!! :slight_smile:

One thing for sure: on the machine where the socket connection didn’t work, we tried to update the Flash Player to version 10 and THE SOCKET CONNECTION WORKED :wink:

Of course, this is not an ugly solution to the problem but it solves it temporarly.


The problem does revolve around the Flash Player version. As of permission files are no longer permitted to be retrieved via a web server, so your crossdomain.xml file is no longer valid. You must retrieve the permissions file via the socket connection. You can configure your jabber server to do this via a perl script. The base for this script was released by Adobe, however we’ve heavily modified it at this point, so I cannot say for sure how the original will function.

I would suggest looking for this script online in the Adobe help section regarding version 124 changes.

Hope this helps a bit.

The actionscript to request such permissions is as follows:


The port 843 has been registered by Adobe for this purpose, but you can modify the perl script to use 5552 as well, or any other port.

One last note. This change is for people using a ejabberd server. If you use an openfire server, there is much help on that in other posts on this board, so look there.