Icecast Streaming Media Server

[DJ-Zath]

hey hey Karl!

now, you guys know that I've been a happy fun supporter of Icecast and have used it for years... and this forum has been the cornerstone to my happy Icecast experience... but...

now I've got one that may stump ya! (has ME stumped!)

recently, I have gotten myself yet, another new server provider

the server is a dedi with 4 gigs RAM, 1 TB drive, 64-bit, Intel dual-core CPU, gignet NIC... yadda yadda yadda.. running FBSD 7.4-RELEASE

I've done this configuration a million times.. and was expecting it to work, but lone, behold...

I simply could NOT get the Icecast (2.3.2) package to work- even with the firewall completely BYPASSED, so after 2 days of pulling my hair out.. I report a problem to the provider who assigns a Tech and I create an account for said, Tech and give him root and all that.. he comes back and [almost rudely] exclaims "I can find nothing wring with this server, what do you want me to do?" in short, they couldn't find anything...

so, then I decide to try recompiling Icecast from scratch.. so I get the source off the site and compile 2.3.3 and ding- that one kinda works- kinda.. but then the package one starts, kinda, working as well.. puzzling!

then I make a discovery- literally by accident- that setting the Kern-secure-Level to -1 fixes the problem, however setting Kern-secure-level to -1 disables all security, including the firewall itself; that's simply something one CAN NOT do in this day and age.

so after a few more tests, I confirm that the Icecast mounts will NOT connect while "kern.securelevel=3" is set, while the shoutcast mount in Icecast will connect..

this one has me puzzled!

I also discovered that fallback isn't working too hot either.. but I don't know if that related or not.. fallback was hit-or-miss and usually miss (this test was done with kern secure level set to -1)

The configuration layout was tried and tested from other servers and installations.. with only minor changes (such as the server's IP) but no other changes were made or nesessary.

as of last night, I have once again disabled the firewall and just tried setting kern security levels to see.. and sure enough, setting it to anything above -1 prevents Icecast mounts from conneting and/or working, while the Shoutcast mounts appear to be working properly.

I'll keep plugging at it, maybe I'll stumble on the solution... I have done this many, many times in the past- on Linux and FBSD- and even FBSD 7.4 RELEASE and with no problems... the only difference, is this is a 64-bit FBSD install rather than a 32-bit one...

-DjZ-


SOLUTION:

I had to modify one of the firewall rules for LOCALHOST passage from "in" to "out"..

changed:

/sbin/ipfw add 220 pass tcp from any to any 8000 in via lo0 setup keep-state

to..

/sbin/ipfw add 220 pass tcp from any to any 8000 out via lo0 setup keep-state


I'm still running tests, but things are looking promising..



note: I still can't get a REMOTE p5-script to connect, but at least, the local one is connecting.. more details, if requested...

AWESOME!
_________________
-DjZ-

[karlH]

I don't know the full scope of what the higher levels do limit, it may prevent unrecognised http style requests from working in which case the retrieval of the status.xsl page should work but the SOURCE requests from the icecast source clients may not. The shoucast mount approach has 2 port and the secondary port does not initially look like http so may be allowed.

karl.

[karlH]

Having a quick read on it, 3 just prevents firewall rules changes, so there's nothing as specified in security(7) to prevent icecast from running as normal. You could try to get truss output to see what happens when a source client connects, but as a shoutcast compatible client works then it would tend to indicate some sort of http parsing being the cause.

karl.

[DJ-Zath]

hi Karl and thanks for the info!

...and thats exactly the case, too- being that I can get pages served.. but the source/clients from the perl script (libshout and p5-shout) aren't able to get in. Shoutcast mount does work (and fast, too) but, its not "falling back" like its suppose to, however.. (Perl/p5-shout is being used as a translator for a professional hardware encoder which is a UDP output.. so I have to convert that into an Icecast-compatable stream/login)

this morning, I attempted to update the ports to the latest versions, but when I rebooted the box, it never returned (the datacenter tells me the hardware failed.. and I'm currently awaiting an update on that status)

but initial tests still showed that I was unable to log in with the kern security level set to anything other than -1 (off)

and I can't find anything in the ruleset that would cause this issue (technically, I hand-wreote the ruleset and know that there should NOT be anythign that blocks access upon protocol, only connection limit and stuff like that) also, even withthe firewall "bypassed" it still doesn't work when the kern security level is turned on in any mode.

the SAME EXACT ruleset worked on all other boxes in the past.. linux and BSD alike, even a miniITX box running FBSD 7.4.. just not this new box!

so, I'm puzzled..

I'm not sure how to get truss (or, the truss) output.. I can say that icecast may seem to not be receiving the source (or client) logins.. while I can open a web browser to it.. but the browser will report "mount unavailable" on the first hit only- additional hits reports "the file you requested cannot be found" (I'm not sure if that's an Icecast output, or firefox, however)
_________________
-DjZ-

[karlH]

I don't see anything specifically an issue with security for source clients connections or fallback handling. Obviously there may be some issue with privileged ports or changeowner options but then you made no mention of that.

truss -o output -p <pid of icecast>

try to start a source
then ctrl-C truss and the file "output" will a file containing the system calls including any incoming connections via accept

karl.

[DJ-Zath]

Thanks Karl!

you DA man!

I owe ya another 6-er! hehe

but I did find a solution.. had to modify a firewall rule so that it pointed outwards instead of inwards.. one of those strange little quirks..
_________________
-DjZ-