Jump to content

Recommended Posts

Posted

I've been asked to look at a problem that one of our teachers has when trying to use 4od. She gets a connection timed out message when trying to run the show she wants to show the kids.

 

I thought it might be something to do with the PC so tried it on my PC, but it came up with the same issue. I even went so far as to try it on a server with a direct connection to the internet, but I got the same issue.

 

Has anyone managed to get this working in the CLEO region? If so how?

Posted

SeeSaw seems to be working, after waiting for a few minutes to buffer. Thanks.

 

I'll take a look at the other thread and see what I can find out.

  • 4 weeks later...
Posted

The problem is that 4OD tries to use RTMPE over port 1935, and if it gets a reject back from a firewall attempts to tunnel the traffic over HTTP.

 

CLEO blackholes traffic on iffy ports, which is a sensible policy. This means however that 4OD never gets it's reject packet (the difference between DROP and REJECT in iptables parlance) and thus never gets around to trying HTTP. It instead just assumes that there isn't a connection, this is really a flaw in 4OD in my opinion.

 

So what's the solution? if you have a local firewall in your control, (i.e. sat before your CLEO edge router), configure it to reject traffic on port 1935. You could even try a 'personal' firewall on the clients being used.

 

WARNING!! This is really just a best guess, and I can't try this for myself... If any one does get around to giving this a shot let us know if it works!

  • Thanks 1
Posted

One more thing! I believe when you traverse the CLEOland proxies you end up getting a number of different source IP's for your traffic depending on the we-cache your traffic hits.

 

I'm told reliably that 4OD cuts you off if your source IP changes during the stream; So another thing to try (in conjunction with the above) is to try using a single web-cache explicitly, although I'm not sure I would recommend this as a permanent solution!

 

There is always the option of looking elsewhere for your internet connection, although I wouldn't dream of recommending anyone specifically!

  • 2 weeks later...
Posted
CLEO blackholes traffic on iffy ports, which is a sensible policy.

 

Just noticed this thread and the RTMPE (1935) explanation looks useful, but unless I've misunderstood I really don't see any value in that policy.

 

The direction has got to be Flash->40d:1935 surely? So where is the significant risk in having the *internal* firewall i/f send a TCP reset for that or any other blocked outbound port?

 

Someone on the inside can figure out an outbound port is blocked = so what.

 

Someone in one school forges a bunch of packets that will result in another getting hit by resets? But why wouldn't the school routers be configured to stop forged addresses getting out? [if not then why not because that very basic sensible concept is older than some of the tech posting here]

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...