Broadcasting to internet server from *behind* college firewall.

[Davman99]

Okies, first things first, I *have* searched for stuff related to this, but everything I can see is to do with having the *server* behind the firewall, not the DJ.

The situation is this:

I'm at college , I'm part of a station that has a radio server that's on the internet. My college only has these ports open: 21,22,80,443 and the MSN messenger ports.

When i try do DJ to the server (we set portbase as 80), no joy. It sits there and will not connect. I can listen to the server just fine on port 80, but no outbound connections it seems.

Possibility: I'm stuck behind a transparent proxy. When i try to download stuff off the net, it sits and does nothing for a minute or so, downloads at 1000kb/s, then settles back to 120kb/s until download is finished.

I've SSH'd into one of my boxes at home, and set up a port tunnel for port 9500 on my machine here at college to go through the tunnel and point at port 80 on the shoutcast server, then when i set the shoutcast plugin client to broadcast to 127.0.0.1:9500, again, nothing happens, it just sits there and says "Connecting".

The server logs don't show any incoming connection from me.

Is there a way to tunnel the shoutcast client? Or any other way to fix my problems?

Thanks guys.

Dav.

[djSpinnerCee]

Your college firewall probably allows outgoing port 80 requests, but when the DNAS portbase is 80 the DSP will try to connect on port 81, so that's the port you would need opened. The DSP actually connects to portbase+1.

Try setting the portbase for your remote DNAS to 79 [the DSP would also be set to use 79] -- this would cause it to accept requests on port 80 [and the DSP to connect on 80]. If it does connect that way, you would have the small problem that if 79 is blocked, you and your buddies behind this proxy may not be able to listen on the non-standard port.

You may also want to try to find a different port pair that works -- try to stay away from well known ports that the proxy/firewall may want to block -- especially p2p port numbers.

[Davman99]

Hmmm... interestingly enough...

We tried fiddling around, and if we run the server portbase as 79, i can DJ to it, but I can't listen.

Good old portbase + 1.

lol... Not sure how I'm gonna fix this one without running shoutcast as root :S


------

Edit...

Just read the post above. All ports are closed *except* 21,22,443,80 and the msn messenger ports. I guess msn messenger ports are gonna be the things to try.

------

Edit...

Cheeky bums at my college *dont* have the MSN ports open. Msn is connecting through port 80.

ARGH!

[djSpinnerCee]

Go with portbase=21 -- That's well known as FTP, but it may work.

[Davman99]

Yea, the problem still being having to run shoutcast as root to get access to ports under 1024.

[djSpinnerCee]

I wouldn't worry about that too much [root access] -- on a PC the DNAS server always runs as "root."

The problem you may have is if there is an already running FTP server bound to the port.

It is difficult to find ports that are outright blocked as opposed to just not having a service running on them, as different utilities may report them as the same thing =CLOSED vs STEALTH -- This is especially true if the DNAS host is configured to try and hide by not sending a response when there is no application associated with a port. To properly test for open-ness, you would have to bind an application to the port and look for the tester to visit the service, otherwise you cannot know for sure if the request on an unbound port is actually blocked or just being dropped [not responded to] by the DNAS host.

The online GRC test http://www.grc.com/ allows you to specify arbitrary port ranges, and a program I found useful for running on PCs is LookAtLAN -- http://www.lookatlan.com/ -- this app can do extensive port scans from your context to the DNAS, so you can perform a more direct test that will expose your outbound limitations as well as the inbound capabilities of the DNAS host box.