Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2020-10-15T09:24:19Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2180SSL for admin only2020-10-15T09:24:19ZMelvyn SopacuaSSL for admin onlyHi,
I've tried the configuration below to setup SSL for the admn. This doesn't work and the documentation is too tierse to give me any hints.
Goal: Force and use SSL for /admin mountpoint. This needs to be a different URL (certificate ...Hi,
I've tried the configuration below to setup SSL for the admn. This doesn't work and the documentation is too tierse to give me any hints.
Goal: Force and use SSL for /admin mountpoint. This needs to be a different URL (certificate has limited hostnames)
Configuration tried:
```
<mount>
<mount-name>/admin</mount-name>
<ssl>1</ssl>
<stream-url>https://www.example.com:8000/admin</stream-url>
</mount>
```
Result:
1. Admin is accessible through HTTP
2. No secure connection can be established through HTTPS.
Note: firewall is not in play, because of 1), but verified regardless.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2179URL Auth with iOS not working correctly2017-10-05T10:40:40ZSebastianURL Auth with iOS not working correctlyHi guys,
when using an IOS device like iPad or iPhone the function "url_add_client" in the file "auth_url.c" seems not to forward all parameters correctly to the authentication system (in my case verify.php).
The username is missing as...Hi guys,
when using an IOS device like iPad or iPhone the function "url_add_client" in the file "auth_url.c" seems not to forward all parameters correctly to the authentication system (in my case verify.php).
The username is missing as you can see in the example below (PHP_AUTH_USER is empty).
After the initial "HTTP/1.0 401 Authentication Required" three GET requests are sent by mobile clients (Android, as well as iPhones or iPads). I checked that with Wireshark. On Android phones the username is never empty, that's why it is always working there.
On iPhones and iPads we have the result below.
The following data is captured from the requests of Icecast to the authentication system (verify.php).
Have a look at the cut off "HTTP_AUTHORIZATION" and the missing username in "PHP_AUTH_USER"
Do you have any idea what is going on there?
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 349
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic dm9sbDpob3JzdA==
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 349
PHP_AUTH_USER: peter
PHP_AUTH_PW: pan
```
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 340
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic OmhvcnN0
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 340
PHP_AUTH_USER:
PHP_AUTH_PW: pan
```
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 340
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic OmhvcnN0
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 340
PHP_AUTH_USER:
PHP_AUTH_PW: pan
```
Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2175Url auth with HTTPS on Win not working2022-03-21T09:31:08ZSebastianUrl auth with HTTPS on Win not workingHi guys,
i tried url auth yesterday with an https link on windows.
I get this error here:
```
[2015-03-12 16:55:20] WARN auth_url/auth_url.c auth to server https://www.domain.com/auth.php failed with Problem with the SSL CA cert (pat...Hi guys,
i tried url auth yesterday with an https link on windows.
I get this error here:
```
[2015-03-12 16:55:20] WARN auth_url/auth_url.c auth to server https://www.domain.com/auth.php failed with Problem with the SSL CA cert (path? access rights?)
```
With this configuration:
```
<mount type="normal">
<mount-name>/radio</mount-name>
<max-listeners>10</max-listeners>
<username>...</username>
<password>...</password>
<authentication type="url">
<option name="listener_add" value="http://www.domain.com/auth.php"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
</mount>
```
I know that you have tried to make it run for windows. I just wanted to keep it tracked here.
Comments/ideas from tbr to that:
"it is working fine on linux. It might work on windows, but nobody figured out how to feed the CA path or file to the curl/nss combination."
"if someone figures out how OR if I switch to Fedora as the build distro, then it /might/ you're free to build on fedora, then it would link against an openssl curl and that might work, or not."
Thanks.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2174icestats.source in /status-json.xsl is not always an array2020-10-10T11:40:10ZDavid Thompsonicestats.source in /status-json.xsl is not always an arrayWhen there is only one mount, icestats.source is an object. When there is more than one mount, icestats.source is an array. This is quite surprising, and it means that client code has to be careful to test for this case and handle it a...When there is only one mount, icestats.source is an object. When there is more than one mount, icestats.source is an array. This is quite surprising, and it means that client code has to be careful to test for this case and handle it appropriately.
icestats.source should always be an array of objects describing the mounts, even if there is only one of them.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2173Max duration support for stream dumpfiles2022-03-22T17:48:23ZThomas B. RückerMax duration support for stream dumpfilesWe've received a request on this topic:
```
My suggestion is that the dump-file tag have an interval option or tag so
that it creates a new dump file based on this interval, and named based
on some sort of dump-file-name tag which wou...We've received a request on this topic:
```
My suggestion is that the dump-file tag have an interval option or tag so
that it creates a new dump file based on this interval, and named based
on some sort of dump-file-name tag which would use BASH naming variables
to name it.
```
http://lists.xiph.org/pipermail/icecast/2015-March/013209.html
Basically boils down to setting a duration and after that reopening the dump file. We already support strftime patterns in the file name.
I have received a patch for this against 2.3.2 and we'll evaluate if it can be reused or at least used as inspiration.
Optional related feature: dump files triggered / turned on/off through admin request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2171Improve https handling of Icecast web ui and generated files2018-11-09T07:18:34ZThomas B. RückerImprove https handling of Icecast web ui and generated filesCurrently some things break if Icecast runs with HTTPS on the primary port.
We should implement proper handling not to return HTTP URLS in such cases.
Right now this either breaks things or will make them insecure.Currently some things break if Icecast runs with HTTPS on the primary port.
We should implement proper handling not to return HTTP URLS in such cases.
Right now this either breaks things or will make them insecure.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2170Mingw32 is unable to "ignore" a pointer to that points to an incomplete type.2018-03-06T12:49:47ZSebastianMingw32 is unable to "ignore" a pointer to that points to an incomplete type.Hi guys,
i tried to compile with mingw32 on a fresh open suse 13.2 system. In order to get the .exe for Windows.
The result:
http://pastebin.com/dZpP3Dwh
Is it a missing configuration or is it really mingw32 that is unable to compile...Hi guys,
i tried to compile with mingw32 on a fresh open suse 13.2 system. In order to get the .exe for Windows.
The result:
http://pastebin.com/dZpP3Dwh
Is it a missing configuration or is it really mingw32 that is unable to compile it.
Considering the error messages: Is catching the error somehow possible in xslt.c?
Best Regards
SebastianThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2169Improved mountpoint metadata manipulation support through /admin calls2018-11-10T12:59:34ZThomas B. RückerImproved mountpoint metadata manipulation support through /admin callsCurrently we expose this mostly as the old style shoutcast metadata hack requires the data to arrive separate from the stream. This is limited to "title".
We should expose a unified interface that allows updating all mountpoint metadata...Currently we expose this mostly as the old style shoutcast metadata hack requires the data to arrive separate from the stream. This is limited to "title".
We should expose a unified interface that allows updating all mountpoint metadata, including that of the stream/container.
This would make things a lot more flexible and enable new use cases, like adjusting mountpoint information without having to reconnect the source.
Assigned to 2.5.0, pending feasibility checks.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2168Icecast should expose the YP server messages to the admin status pages per mount2018-06-16T22:44:50ZThomas B. RückerIcecast should expose the YP server messages to the admin status pages per mountThere are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simp...There are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simplified status should be also exposed to the XML used for public status.
People don't read the error.log, ever, especially in this case.
We should expose:
* If the YP server accepted the initial touch
* If the server accepted the latest touch
* What was the last status message from the YP server for a failed touch
* What was the latest status message from the YP server, including successful
* Count of YP touches since source connection
* Count of failed YP touches since source connection
Rationale is, that there might be intermittent failures so we should expose both latest message and latest failure. Also latest message, if successful could contain some information like "server outdated and insecure, please update" or otherwise from the YP administration.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2167Icecast should expose the YP listing status to the public status pages2018-06-16T22:44:16ZThomas B. RückerIcecast should expose the YP listing status to the public status pagesThere are hundreds if not thousands of streams that fail to list properly in dir.xiph.org and it's obvious that nobody notices.
/admin/stats should expose a per mount status field if the given mount is set public and directory listings ...There are hundreds if not thousands of streams that fail to list properly in dir.xiph.org and it's obvious that nobody notices.
/admin/stats should expose a per mount status field if the given mount is set public and directory listings are enabled for the server.
Logic could be as follows:
* *OK* - No known errors for this mount
* *WARN* - During the last n yp-touches at least one error was received
* *FAIL* - No successful listing/touch for this mount
Further information, including verbatim messages from YP should be available through the admin interface. Covered in a separate ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2166Customizable .ico file via config2018-03-06T12:49:47ZSebastianCustomizable .ico file via configI want to be able to replace it with my own =) Just a wish...I want to be able to replace it with my own =) Just a wish...Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2164Mime-Type file config option should be in the path section2018-03-06T12:49:47ZMarvin ScholzMime-Type file config option should be in the path sectionThe `<mime-types>` configuration option should be move to the `<paths>` section, to keep the configuration file structured correctly.The `<mime-types>` configuration option should be move to the `<paths>` section, to keep the configuration file structured correctly.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2159RFC 2817 "Upgrading to TLS Within HTTP/1.1" Support2018-03-06T12:49:47ZPhilipp SchafftRFC 2817 "Upgrading to TLS Within HTTP/1.1" SupportRFC 2817 should be supported.
This will also be helpful with libshout. See #2152.RFC 2817 should be supported.
This will also be helpful with libshout. See #2152.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2158No metadata for the listenerer when sourcing with Mixxx on Windows2020-02-14T12:59:17ZSebastianNo metadata for the listenerer when sourcing with Mixxx on Windows2.4.99.1 aka 2.5 beta1 on windows with Mixxx as source client.
Unfortunately the metadata (title and artist) is not visible on iTunes anymore.
In 2.4.1 this was no problem. I tried to use the charset UTF-8 in Mixxx and in Icecast but i...2.4.99.1 aka 2.5 beta1 on windows with Mixxx as source client.
Unfortunately the metadata (title and artist) is not visible on iTunes anymore.
In 2.4.1 this was no problem. I tried to use the charset UTF-8 in Mixxx and in Icecast but it didn't work either.
Maybe someone could have a look at it.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2156Check feasibility of intro functionality for WebM2018-03-06T12:49:38ZThomas B. RückerCheck feasibility of intro functionality for WebMSee #2155 also #1941
We would need to see if an otherwise parameter compatible stream can be spliced seamlessly so that it doesn't cause players to complain/break.
If not feasible we should disable intro if content-type is WebM.See #2155 also #1941
We would need to see if an otherwise parameter compatible stream can be spliced seamlessly so that it doesn't cause players to complain/break.
If not feasible we should disable intro if content-type is WebM.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2155Improve WebM support in Icecast2019-06-26T17:23:33ZThomas B. RückerImprove WebM support in IcecastWe currently don't support the same use-cases as other formats.
This is partly due to the format - WebM doesn't support something like chaining.
We might work around a few things, but this needs to be explored.
This is a tracker ticket.We currently don't support the same use-cases as other formats.
This is partly due to the format - WebM doesn't support something like chaining.
We might work around a few things, but this needs to be explored.
This is a tracker ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2150check if we need to forward port a possible win32 security fix from kh2020-10-15T11:20:19ZThomas B. Rückercheck if we need to forward port a possible win32 security fix from khhttps://github.com/karlheyes/icecast-kh/commit/b50c6374234154ad94b3c3a3e76545601e997739
```
do not use SO_REUSEADDR on windows, breaks the reload handling
MS defined SO_REUSEADDR differently to BSD and linux and have allowed some stupi...https://github.com/karlheyes/icecast-kh/commit/b50c6374234154ad94b3c3a3e76545601e997739
```
do not use SO_REUSEADDR on windows, breaks the reload handling
MS defined SO_REUSEADDR differently to BSD and linux and have allowed some stupid
security issue on it for port stealing. They messed it up, added another option
which doesn't help here and advise not using this option. Luckily the default
behaviour is acceptable. I've also avoided the abort case which should not trigger
but if it does, it reports an error and skips the rest.
```
Needs checking against Windows documentation. There might be some differences in how kh and we use things.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2147Split up Icecast certificate handling into private and public key files2018-06-15T21:17:45ZThomas B. RückerSplit up Icecast certificate handling into private and public key filesThis would make it easier for people who are used to most software requiring two files, also it would make it easier to share certificate files with other server software like e.g. Apache httpd or dovecot imapd.This would make it easier for people who are used to most software requiring two files, also it would make it easier to share certificate files with other server software like e.g. Apache httpd or dovecot imapd.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2146Icecast should send the "admin" field from config to YP2018-03-06T12:49:47ZThomas B. RückerIcecast should send the "admin" field from config to YPThis would allow the YP admins to contact the server administrator in case of problems with the listing/streams.
It would address a very common problem, finding out the contact details for a server admin.This would allow the YP admins to contact the server administrator in case of problems with the listing/streams.
It would address a very common problem, finding out the contact details for a server admin.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2145Adding <outro> file for mountpoints2018-03-06T12:49:38ZJordan EricksonAdding <outro> file for mountpointsHello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are...Hello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are moved to. Thank you for your consideration =)Thomas B. RückerThomas B. Rücker