Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2024-01-14T14:15:37Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2472Locking issue with logging2024-01-14T14:15:37ZPhilipp SchafftLocking issue with loggingCurrently the signal handlers as well as the event subsystem's exec backend logs messages. Those seem to be subject to restrictions on the logging code's locking. This can result in the process hanging. It is unclear whether or not this ...Currently the signal handlers as well as the event subsystem's exec backend logs messages. Those seem to be subject to restrictions on the logging code's locking. This can result in the process hanging. It is unclear whether or not this may also corrupt the process in any way.
See also (likely unrelated): #2231https://gitlab.xiph.org/xiph/icecast-server/-/issues/2470Missing documentation for version 'latest'2023-04-06T12:15:53ZJonas L.Missing documentation for version 'latest'Documentation for some versions is missing on the website https://icecast.org/docs/:
- https://icecast.org/docs/icecast-latest
- https://icecast.org/docs/icecast-2.4.4Documentation for some versions is missing on the website https://icecast.org/docs/:
- https://icecast.org/docs/icecast-latest
- https://icecast.org/docs/icecast-2.4.4Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2439HTTP request EOF problem2022-05-07T15:37:59ZCsaba27HTTP request EOF problemHello, i have a problem with icecast 2.4.99 version, after the http response the icecast doesn't close the connection.
There is an example code from PHP:
```
<?php
// ini_set("default_socket_timeout", 5);
$start = microtime(true);
$...Hello, i have a problem with icecast 2.4.99 version, after the http response the icecast doesn't close the connection.
There is an example code from PHP:
```
<?php
// ini_set("default_socket_timeout", 5);
$start = microtime(true);
$fp = fsockopen("icecast-example-host.com", 8000, $errno, $errstr, 5);
if ($fp)
{
$out = "GET /status_json.xsl HTTP/1.1\r\n";
$out .= "Connection: Close\r\n";
$out .= "Host: icecast-example-host.com:8000\r\n";
$out .= "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36\r\n";
$out .= "\r\n";
fwrite($fp, $out);
// stream_set_timeout($fp, 5);
$line_count = 0;
while (!feof($fp))
{
$line_count++;
echo $line_count . " " . fgets($fp);
# echo fread($fp, 1024);
}
fclose($fp);
}
else
{
echo $errstr . " (" . $errno . ")" . PHP_EOL;
}
echo PHP_EOL . " " . round(microtime(true) - $start, 4);
```
Run in console and check the execution time (request time).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/24322.4.99 beta 3 - OPENSSL - still support for TLS 1.0 and TLS 1.1 - compared t...2024-01-20T23:54:11ZTom Zet2.4.99 beta 3 - OPENSSL - still support for TLS 1.0 and TLS 1.1 - compared to 2.4.4The current **2.4.99 beta 3** still offers TLS 1.0 and TLS 1.1. The SSL test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.28.01_PM](/uploads/dfa1d62d8672e72cf0bcb167575ddbff/Image_2022-03-18_at_11.28.01...The current **2.4.99 beta 3** still offers TLS 1.0 and TLS 1.1. The SSL test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.28.01_PM](/uploads/dfa1d62d8672e72cf0bcb167575ddbff/Image_2022-03-18_at_11.28.01_PM.jpeg)
On a Debian sid System with `OpenSSL 1.1.1n 15 Mar 2022` the icecast has been compiled with `./configure --prefix=/home/zumbi/icecast-2.4.99-beta-3 --with-curl --with-openssl`
The following ciphers are configured in the xml. at the end I excluded `!TLSv1:!TLSv1.1`.Even if standard in openssl, this cyphers has not been ignored.
`<ssl-allowed-ciphers>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:!TLSv1:!TLSv1.1</ssl-allowed-ciphers>`
While on a productive Debian 11 with `OpenSSL 1.1.1k 25 Mar 2021` and **icecast 2.4.4** the test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.30.33_PM](/uploads/43b55bf7d48f5dcda944f398c48200b5/Image_2022-03-18_at_11.30.33_PM.jpeg)
The following ciphers are configured in the xml
`<ssl-allowed-ciphers>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256</ssl-allowed-ciphers>`
I tried to change the source code in the file `src/tls.c` on row 91 from `TLS1_VERSION` to `TLS1_3_VERSION` but get a compile error
**Original code**
```
#if OPENSSL_VERSION_NUMBER < 0x10100000L
ctx->ctx = SSL_CTX_new(SSLv23_server_method());
ssl_opts = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3; // Disable SSLv2 and SSLv3
#else
ctx->ctx = SSL_CTX_new(TLS_server_method());
SSL_CTX_set_min_proto_version(ctx->ctx, TLS1_VERSION);
#endif
```
**Compile (make) error**
```
In file included from tls.c:18:
tls.c: In function ‘tls_ctx_new’:
tls.c:91:45: error: ‘TL1_3_VERSION’ undeclared (first use in this function); did you mean ‘TLS1_3_VERSION’?
91 | SSL_CTX_set_min_proto_version(ctx->ctx, TL1_3_VERSION);
^~~~~~~~~~~~
```
**Proposal**
1. Change the code this way, that TLS 1.0 and 1.1 (and older) are not offered anymore. Only offer TLS 1.2 and newer. Same way as in 2.4.4
and/or
2. Implement an option as used in advanced webservers like nginx, that the TLS version can be set in the config.
Example for nginx `ssl_protocols TLSv1.2 TLSv1.3;`. Even if the icecast developers move from openssl to another solution, such a option will be helpful and shows best practice.Icecast 2.5 rc1Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2410URL auth does not work with HTTP/2 servers2023-01-03T10:21:48ZMarvin ScholzURL auth does not work with HTTP/2 serversUsing URL auth with a HTTP/2 capable sever does not work properly:
```text
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "HTTP/2 200 .."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "...Using URL auth with a HTTP/2 capable sever does not work properly:
```text
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "HTTP/2 200 .."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "date: Sun, 25 Apr 2021 11:40:34 GMT.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "server: Apache.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-result: ok.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-alter-action: redirect_permanent.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-alter-argument: https://stream.example.com/hits/highquality.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "content-type: application/json.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: ".."
[2021-04-25 13:40:34] EROR auth_url/handle_returned_header__complete Can not parse auth backend reply.
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2403HTTP 409 on reconnect2024-01-20T23:53:52ZGlenn SimsHTTP 409 on reconnectI recently updated our Icecast software from 2.4.4 to 2.4.99.2 (built via source). The internet at my station goes out sometimes and shuts off the stream. Our program, Broadcast Using This Tool, is designed to automatically reconnect t...I recently updated our Icecast software from 2.4.4 to 2.4.99.2 (built via source). The internet at my station goes out sometimes and shuts off the stream. Our program, Broadcast Using This Tool, is designed to automatically reconnect to the server if the connection dies. However, when the internet comes back on, the log says "server answered with 409!", which means an HTTP conflict.
Icecast is hosted on AWS EC2 running on ports 80 and 443. It is forwarded through my subdomain has an A record with an SSL certificate in the `icecast.xml` file. Since then I have not made any changes to the DNS. This issue had started happening after the upgrade to 2.4.99.2.
This is my BUTT log open in Notepad++ showing the error:
![Screenshot_2020-11-06_191540](/uploads/815c58d23d7cea1510d9fa0184b3d155/Screenshot_2020-11-06_191540.png)Icecast 2.5 rc1Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2400global stats key listeners incorrect after client got dropped from pending_tr...2021-03-22T23:22:29ZPhilipp Schafftglobal stats key listeners incorrect after client got dropped from pending_tree for max_listenersThe global stats key `listeners` is incorrect after a client is dropped from the `pending_tree` as the mount is full. this happens on client move (as per admin request or fallback).
The code can be found looking in source.c for:
```
...The global stats key `listeners` is incorrect after a client is dropped from the `pending_tree` as the mount is full. this happens on client move (as per admin request or fallback).
The code can be found looking in source.c for:
```
ICECAST_LOG_INFO("Client deleted, exceeding maximum listeners for this "
"mountpoint (%s).", source->mount);
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2392Tag for 2.4.4 is missing2024-01-06T20:01:19ZDavid RungeTag for 2.4.4 is missingHi! I package icecast for Arch Linux.
We currently use tarballs from this location: https://www.icecast.org/download/
However, the release for 2.4.4 is not reflected in a tag in this repository: https://gitlab.xiph.org/xiph/icecast-serv...Hi! I package icecast for Arch Linux.
We currently use tarballs from this location: https://www.icecast.org/download/
However, the release for 2.4.4 is not reflected in a tag in this repository: https://gitlab.xiph.org/xiph/icecast-server/-/tags
It would be very awesome if you could add the tag so that reproducibility can be ensured.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2391Found memory leak problems on ubuntu 20.04 tls2024-01-21T02:16:55ZChaichanaFound memory leak problems on ubuntu 20.04 tlsubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applica...ubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applications
https://mediarealm.com.au/articles/icecast-https-ssl-setup-lets-encrypt/
- IMAGE
Top in image ubuntu 18.04 tls
Bottom in image ubuntu 20.04 tls
![ฟ](/uploads/d236d04fa7fc56f7c97c7d47e7937a12/ฟ.jpg)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2365Discussion on the handling of portless Host:-headers2020-10-11T15:59:37ZPhilipp SchafftDiscussion on the handling of portless Host:-headersKarl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port eve...Karl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port even if non-default ports are used. When this header is used this results in invalid playlists to be generated. (Other (future) uses such as vhosting may also be affected).
foobar2000 seems to have fixed this. This was the result of a quick test with @laama. Thanks to him.
Winamp 5.53 1898 Beta from 2008 as well as Winamp 5.8 as downloaded today are still affected.
The following solution and workarounds come to mind:
* Nullsoft fixes their software. (Judge yourself if this is going to happen.) This is the only solution. It is the only correct way to do this.
* Keep ignoring Host:-headers that do not include a port. This may break legitimate clients.
* Try to match Host:-headers against listen sockets. This may break vhosting.
* Implement a way to list valid vhosts and set default vhosts per listen socket.
* Ignore Host:-headers without a port but implement a per listen socket default vhost setting.
Note that we can not accept/reject Host:-headers without port based on if we listen on a default port socket or not without type="virtual" listen sockets. This will otherwise break all kinds of redirects.
This ticket is mostly for discussion.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2361Remove RAWURI values from URL auth2018-11-27T09:57:57ZPhilipp SchafftRemove RAWURI values from URL authCurrently the URL auth system transmits the RAWURI value if available as "mount"-parameter. This includes query strings. However it does not include POST parameters (therefore is inconsistent).
This should be deprecated and only the res...Currently the URL auth system transmits the RAWURI value if available as "mount"-parameter. This includes query strings. However it does not include POST parameters (therefore is inconsistent).
This should be deprecated and only the resource the user connected to should be included.
It must be discussed if it should transmit the original resource name (before `<resource>` processing) if they differ.
See also: #2360.