[Icecast] Strange behaviour with admin/stats.xsl disappearing

Mon Sep 2 19:55:01 UTC 2024

Greetings with apologies for posting on icecast-kh!  I wasn’t aware about this until now. 

> Are you sure you do not have multiple things listening on the same port, possibly one for IPv4 and the other with IPv6 or your OS set in a way that it would permit multiple listening processed on the same port?
Yes there's only iceast (kh) listening exclusively on its own ip.

> Make sure you actually see the request for which you get the unexpected response in the Icecast access log, if you do not, it never gets to Icecast in the first place.
Thanks will do so!

I've subsequently found these entries in the kern.log:
TCP: request_sock_TCP: Possible SYN flooding on port 8000. Sending cookies.  Check SNMP counters.
Oopsie~! That looks like a DDOS of sorts... and jeepers I have lots to learn still...

BTW - I've not been able to find a list of differences between iceast2 & iceacast-kh yet.
My preference would be to use icecast2 as it's available to Debian dpkg, yet I'm not sure how to go about enabling full ssl support using the chained pem cert that's working fine with icecast-kh.
Can you perhaps point me to a reference describing how to use ssl with icecast2 please?

Is icecast2 more stable than icecast-kh - or what are the advantages of using icecast2 over icecast-kh?

My sincere apologies if this is a tired out question....

I just want things to run smoothly with max stability and enjoy the peace of mind that brings! 😊

Appreciate your response with gratitude. 

Marek

-----Original Message-----
From: Icecast <icecast-bounces at xiph.org> On Behalf Of epirat07 at gmail.com
Sent: Monday, September 2, 2024 1:31 PM
To: Icecast streaming server user discussions <icecast at xiph.org>
Subject: Re: [Icecast] Strange behaviour with admin/stats.xsl disappearing

Hi,

On 2 Sep 2024, at 12:19, Marek Dziembowski wrote:

> Greetings icecasting amigos!
>
>
> I’ve had an incredibly frustrating journey getting a new icecast origin server going to supplant an older machine set for retirement.
>
> The setup is relatively simple – a beefy Debian bookworm host running icecast as a relaying slave pulling the streamlist from an icecast2 2.4.4 ingest server, for mass distribution.
> The ingest / origin server runs fine.
>
> I opted for compiling the latest icecast-kh for the slave, but ran 
> into issues with the host unable to fetch the master streamlist to 
> relay. (I think due to compiling without explicitly including 
> libcurl?)

This list is not for Icecast-kh related matters, at this point Icecast-kh is quite diverged from Xiphs Icecast.

If you need help with that, you should seek it elsewhere, where people are more familiar with that, not on the Xiph Icecast support list.

>
> I then got the prior icecast-kh compiled and it relayed fine, but then 
> I ran into rather bizarre problems consistently displaying the admin/stats.xsl web interface… I then tried with icecast2 installed from Debian dpkg, but got annoyed with ssl shortcomings, going back to latest icecast-kh - now with libcurl - and got the relaying working fine with ssl sorted.
>
> But the same issue with the adminpages persist:
>
> After starting the icecast service, the admin/stats.xsl displays as a webpage perfectly, as does /index.html. When trying to open a bogus path that doesn’t exist, the page with text “The file you requested could not be found” is returned as expected.
> When opening any bogus after /admin in the path eg. /admin/statserf, the <icestats> xml is returned.
>
> All fine after startup / restart - but it doesn’t function correctly this way for very long.
>
> After an indeterminate while the admin/stats.xsl and index pages start 
> to return browser’s 404 not found.  (not the page with text “The file you requested could not be found” as above) However the icecast xml versions are returned fine.
> And any bogus url – random path will return the expected 
> /admin/stats.xml
>
> Nothing I do can restore the normal admin web pages until I restart the icecast service!!

Are you sure you do not have multiple things listening on the same port, possibly one for IPv4 and the other with IPv6 or your OS set in a way that it would permit multiple listening processed on the same port?

Make sure you actually see the request for which you get the unexpected response in the Icecast access log, if you do not, it never gets to Icecast in the first place.

>
> And just as luck of murphy would have it –I cant replicate the problem this morning and it seems to be working normally so far…. But why / how did icecast behave that way before – and how to address the issue if it occurs again?
> I cant just continually restart icecast and kick hundreds of listeners off every time!
>
> Any insight / advise would be greatly appreciated!
>
> Oh and PS: little to nothing substantial to be found in the error.log 
> ☹
>
> Thanks!
> Marek
>
>
>
>
>
>
>
> [cid:image001.jpg at 01DAFD29.32B218F0]
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast