Tag Archives: networking

ccent

So… I just finished the first half of my CCNA today.

I never really cared about networking much beyond that needed to make sure clients on a lan can talk to their dns server… but we’ve been growing enough here at work that the needs quickly outpaced my prior skillset. And since I was the closest thing we had to a network admin, I got signed up for classes 😉

It’s been fun and profoundly enlightening. I didn’t expect to have my way of thinking so radically altered, but I’m hardly complaining.

I’ll be starting up the second class in a week or two. This’ll include such topics as VLANs, IPv6, and fancy routing protocols. I’m stoked.

It’s funny. I never finished college (though I took classes for roughly 10 years), so this is actually the first certificate of education I’ve received since highschool.

The comment was made at work that I’d dinged as a sysadmin. I haven’t. I’m just cherry picking my next few levels in netadmin 😉

flash policy service daemon

Sorry it took me so long to post this, but WordPress 2.5 doesn’t seem to like me trying to upload gz/zip files, so I had to upload the source manually.

Well, it’s been months since I promised to post some usable socket policy service code, so I will.

The script here is meant to serve as a good starting point for people whose servers need to allow flash clients to make socket connections. I have not actually used this exact code in a production environment, but I have been using code that is 99% identical for a while now. I am confident that any blatant flaws are the result of simple copy-paste errors as I compiled the package. Please let me know if you find any.

I have however, stress tested the heck out of this service. One instance successfully served up over 16000 policy file requests fed into it as rapidly as I could send them. The same networking code has also handled requests from at least 100 different hosts at roughly the same time.

Everything has been combined into a single cli php script that requires no special installation. Just plop it down on the server and run it as root. It will take care of the rest. The config defaults should be safe, but you probably want to specify them more clearly – just to be safe.

The daemon is made of three classes:

  • Logger – A rudimentary log file management class that I copy from project to project in one form or another. The included version is stripped down from some of the other versions I’ve written, and I’m planning on releasing a more feature-rich version in the future.
  • Daemon – A simple class for daemonizing a process. Adapted and re-adapted countless times from an original php4 class I found on the net a few years ago by some guy named Seth (whose email domain no longer exists).
  • FlashPolicyService – The meat and potatoes, a child of Daemon. Mostly, this is just the requisite networking code and glue to make everything work together.

As with any of my other code, this is licensed under CC Attribution 3.0.

Download:

Source code after the jump.
Continue reading flash policy service daemon

flash socket policies update

I’ve been getting a lot of positive feedback recently on the post I made last December on this topic, so it’s probably time to post an update.

Last week, Adobe finally released some help for people who need to provide socket policy services. They’ve got python and perl versions of the socket policy daemon that look like they can run either standalone or through xinetd. They don’t claim that the code is production quality yet… but it’s at least something.

Of course, I released sample PHP code 5 months ago… shrug.

My confederates and I have spent the intervening months sniffing packets, yelling at flash, rewriting daemons, etc… until settling upon a version of the service that appears to function reliably now. I am currently running it on 6 different servers and have seen it successfully handle requests from >100 simultaneous users during stress tests.

The biggest problem with my previous versions of the code was how I handled closing of connections. Previously, I had simply accepted connections and fired off the policy xml without waiting for a request from the client.

This worked 95% of the time over a good net connection, and more like 80% of the time over a poor connection.

The reason it didn’t work consistently was because of weird tcp ordering issues. Connections would be closed out of order, the response would be received before the request was dispatched, etc..

My new version is much more robust and actually waits for flash to submit the request before sending the XML. I consider it release candidate beta quality code and hope to be able to release it later today.

update

Version 0.9.b is available now.

new flash security policies

So… I am not happy with Adobe right now. With the push of Flash Player 9,0,115,0 “moviestar”, which included such awesome features as H.264 and AAC codec support and improvements to fullscreen mode, they kind of ambushed me with some sweeping changes to their security policy.

I’d been running pre-release nightly builds of the player since 9,0,60,x… and had noticed some strange warnings. Mysterious “Socket Security Error #2048” exceptions that were being thrown at random – even though I was serving an appropriate (for the time) crossdomain.xml file, unexplained timeouts attempting to talk to an xml socket server when I was very clearly not attempting to do any such thing, etc… My regularly repeated attempts to find documentation on what the warnings actually meant proved fruitless. I believe that is because the appropriate document was not actually released to the public until 9,0,115,0 was released.

Now, the bit where they improved the format for crossdomain.xml files doesn’t really affect me one way or the other. I approve of the improvements but could really care less in this case. They don’t really affect anything I’m doing.

The part that really chaps my hide is the fact that they’ve completely redone the way that socket security policies are handled. The important parts:

  • 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.
  • 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.

That’s right. Your socket policy data can’t live in the sitewide crossdomain.xml file that Apache serves any more.

Flash Player 9,0,115,0 introduces a concept of socket master policy files, which are served from the fixed TCP port number 843.

Socket policy files may be obtained from the same port as a main connection (the socket connection being made by ActionScript, which is authorized by a socket policy file), or from a different port, separate from the main connection. If you opt to serve a socket policy file from the same port as a main connection, the server listening on that port must understand socket policy file requests (which are indicated by a transmission of from Flash Player), and must respond differently for policy file requests and main connection requests.

  • When a SWF file attempts to make a socket connection, even to its own domain, Flash Player will first attempt to contact port 843 to see if the host is serving a socket master policy file.

So… regardless of whether you’re even using a custom port 843 client, the Flash Player is going to try to hit it. What if your firewall doesn’t allow/route traffic to sub-1024 ports w/o special configuration? What if you don’t have the access to bind to a sub-1024 port and can’t rewrite your other server process to serve the policy data on its port?

  • Socket meta-policies can only be declared in a socket master policy file. The syntax is the same as for declaring a meta-policy in an URL master policy file, using the <site-control> tag. Socket meta-policies cannot be declared in HTTP response headers, as HTTP is not involved.

This implies that you can’t even tell apache to listen to port 843 and serve up the data. You HAVE to either maintain a separate server process specifically for the purpose of serving this policy data, or you have to edit the process that SWF’s are connecting to and make them serve the data..

As of the time of this writing (10 days after moviestar’s release), they have yet to release promised help on how to deploy a solution to these new changes. Granted, the one article they did release explains what needs to be done in high level terms. It was sufficient to help me out. I wrote a server that simply listens on port 843 and spews the required xml. But… I’d have really appreciated specific examples, and I suspect plenty of people would appreciate drop-in solutions to the issue.

A 5-minute skeleton implementation (not recommended for production use by any means) written as a PHP cli script might look something like this:

I’ll try to make my production version of this a bit more suitable for public consumption and release it as soon as I can.

The random #2048 security errors continue, despite having deployed my port 843 policy xml server. Granted, they happen less than before… but they still happen. And even when my policy server isn’t running, the errors aren’t thrown 100% of the time. This just baffles me. If they were consistent, that would be one thing. But when you get a security error 1 time in 20… that’s not security, that’s not even a lame deterrent. It’s just incentive to hammer the same port over and over again until something finally gives.

Now, I admit that I could be wrong here… but I’ve re-re-read the documentation on these policies a few times now, and cannot find any reason for the behaviors I’m seeing.

update

On April 22nd, 2008, I released a much better, much more reliable version of this daemon. Head over there for more details and source code.

php post method

Yes, I know you can do this via cURL. This was explicitly written for a case when that particular luxury was not available to me.

So… it’s been a while since I’ve written a post, and I’m feeling the withdrawals. I’ve got 16 half-written posts waiting in the queue and two more that I want to write but haven’t even started. It’s also time for another round of anime reviews; I’ve got two video games I want to review…

And I am having to play the “too busy with RL” card.

In stead, I present a function that I wrote this morning. It’s been done countless times before, and you can probably find incredibly similar code out there already, but it’s the first time I’ve ever actually needed something quite like this.

This method could easily be modified to send GET data or to talk over a different port. It could also probably actually do something with the response buffer (check for 200, etc…). It could be a bit more fault tolerant, etc… but that’s not what I need for the application at hand.

For other examples of how people have done similar/related things, take a look at the comments on the fsockopen() documentation page.

udp in flash

This is a memo to myself more than anything else… but there has got to be a way to use UDP from a SWF running through your web browser.

Pieces of the puzzle:

  • Flash 9 has binary TCP socket support, but no UDP.
  • Standalone projectors like MDM Zinc can add UDP capabilities to the mix.
  • A projector and a SWF in the browser can communicate together very happily via the LocalConnection interface.

But web browsers are understandably reluctant to download and run a 3rd party UDP proxy application for you 😉 It’s also not terribly platform independent to require something running in userspace outside of the VM.

Java has UDP support. You could write a UDP proxy in Java that uses a standard local TCP socket to talk to the SWF – both the SWF and the applet would have to load from the same page. Don’t know whether Java’s and Flash’s security policies would allow this sort of behavior… probably not. I know applets have difficulties connecting to anything but the originating server – so they probably can’t listen for traffic on the local host either. And if they can, there’s probably some big security certificate you have to sign in blood and offer to the Sun gods or something…

Of course, the dumb option would be to have a remote TCP->UDP proxy… but that eliminates any sort of performance gain that might have been achieved by using UDP in the first place, so that’s only valid in the weird case where you honestly need to talk to a UDP server for whatever reason and don’t care about the lag.

No, the proxy must run locally, somehow.