Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-09-28T14:05:00Zhttps://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/2187implement event triggers 'client-connect' / 'client-disconnect' to match lega...2019-01-22T06:34:14ZThomas B. Rückerimplement event triggers 'client-connect' / 'client-disconnect' to match legacy url-auth```
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
```
should translate to triggers:
* 'client-connect'
* 'client-di...```
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
```
should translate to triggers:
* 'client-connect'
* 'client-disconnect'
Enables e.g. statistics collection without the potential problems of setting it up as auth.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://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/2125Kicking a source disconnects listeners even if fallback defined2018-03-06T12:49:47ZThomas B. RückerKicking a source disconnects listeners even if fallback definedAs mentioned by ph3-der-loewe, this seems to happen. One would expect that if a source is forcefully disconnected, that the listeners are sent to defined fallbacks.As mentioned by ph3-der-loewe, this seems to happen. One would expect that if a source is forcefully disconnected, that the listeners are sent to defined fallbacks.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2124With <role> every client needs to go thru the stack of auth_ts. This will del...2018-03-06T12:49:47ZPhilipp SchafftWith <role> every client needs to go thru the stack of auth_ts. This will delay client connectionsEvery client is now forced to auth. As currently each <role> is implemented with a independent thread and queue this may take extra time. also some modules such as the static type can tell with like no delay if a user matches and does no...Every client is now forced to auth. As currently each <role> is implemented with a independent thread and queue this may take extra time. also some modules such as the static type can tell with like no delay if a user matches and does not need the asynchronous handling of a thread.
I suggest to build an interface so the type cann tell if they need the asynchronous interface or if a synchronous interface will do.
This would reduce the number of threads by at least one per process plus one per password (non-htpasswd) auth. If htpasswd auth can be converted is to be checked.
I suspect a massive performance improvement by this.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2119Filter based on User Agent2018-11-10T13:31:06ZPhilipp SchafftFilter based on User AgentThere is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds ...There is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds of client data as well.
The module would return `NOMATCH` on no match or `FAILED` on match on deny list. Behaviour on pass should maybe be documented. Defaulting to `NOMATCH` to continue with the processing of other `<role>`s.
Some technical background:
In contrast to the `<allow-ip>` and `<deny-ip>` this check can only happen after the client request has been parsed as it depends on data of exactly this client request. This makes it less suitable for (D)DoS protection in general. It should be considered to use some kind of firewalling of fail2ban to protect against such attacks.
Pros of implementing it the way described above:
- It would match the internal schemata and wouldn't be another alien.
- It could be extended to universally match any configured attributes of the client object.
- Integrates well into usage together with other `<role>`s. E.g. to allow some role access but deny others access depending on this module (admin can always go, listeners only if user agent matches).
- Rejects the client with a `401` according to the standard.
Contra:
- Is much slower than implementing it in a specific and specific way as it happens in the authentication engine and not in before on rejected clients. Slowdown for passing clients will not be significant.
- Rejects clients with a standard conforming `401`. Does not just drop them.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2092Write specification of Icecast specific HTTP protocol features2018-06-07T20:52:20ZThomas B. RückerWrite specification of Icecast specific HTTP protocol featuresUse HTTP 1.0 and 1.1 specs as base, document differences and quirks.
Give guidance what a source client SHOULD, MUST, MUST NOT do, etc.
Explain source and listener HTTP headers, authentication quirks.Use HTTP 1.0 and 1.1 specs as base, document differences and quirks.
Give guidance what a source client SHOULD, MUST, MUST NOT do, etc.
Explain source and listener HTTP headers, authentication quirks.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2087icecast does not only write the stream data into the dumpfile2018-03-06T12:49:47ZSven Herzbergicecast does not only write the stream data into the dumpfileHow to reproduce:
Write a script (e.g. called “test-script.sh”) with this content and set the executable bit:
```
set -e
set -x
echo "stdout"
echo "stderr" >&2
```
Then specify that script in an mount point of the icecast configurat...How to reproduce:
Write a script (e.g. called “test-script.sh”) with this content and set the executable bit:
```
set -e
set -x
echo "stdout"
echo "stderr" >&2
```
Then specify that script in an mount point of the icecast configuration like this (I have this in my mount point defaults):
```
<on-connect>/path/to/test-script.sh</on-connect>
```
The beginning of the dump-file will look like this:
```
# hexdump -C /srv/icecast/test-stream/backup.mp3 | head
00000000 2b 20 65 63 68 6f 20 73 74 64 6f 75 74 0a 2b 20 |+ echo stdout.+ |
00000010 65 63 68 6f 20 73 74 64 65 72 72 0a 73 74 64 65 |echo stderr.stde|
00000020 72 72 0a 2b 20 65 78 69 74 20 30 0a […] |rr.+ exit 0.[…]|
```
This makes the dumpfiles difficult to use as backups of the stream data.
I think the `<errorlog>` target would be more a appropriate target for this output.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2082Require content-type for PUT connections2018-03-06T12:49:47ZThomas B. RückerRequire content-type for PUT connectionsWe should only allow PUT connections if the content-type is explicitly set.
This will avoid breakage such as a source sending a ogg/vorbis stream, but not setting a content-type and then being mis-listed as "audio/mpeg" instead of "audio...We should only allow PUT connections if the content-type is explicitly set.
This will avoid breakage such as a source sending a ogg/vorbis stream, but not setting a content-type and then being mis-listed as "audio/mpeg" instead of "audio/ogg".
This will need to be made very clear in release notes and documentation, so that people are aware when writing new clients or porting old clients to the PUT protocol to properly set content-type.
We can't enforce this for SOURCE connections as there are simply too many broken clients out there.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2081Wrong duration value in access.log on mingw32 builds2018-03-06T12:49:47ZThomas B. RückerWrong duration value in access.log on mingw32 builds34678888 or such (jitter in the last 4-5 digits) for static files from the web interface that were served in under a second is rather unlikely.
On the mailing list someone reported also weird values in case of longer connections.
Teste...34678888 or such (jitter in the last 4-5 digits) for static files from the web interface that were served in under a second is rather unlikely.
On the mailing list someone reported also weird values in case of longer connections.
Tested on Windows 2012 R2Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2080Limit/Filter access types available through a listener socket2018-10-02T08:29:07ZThomas B. RückerLimit/Filter access types available through a listener socketOne thing that might be worth considering is to add another setting to listener sockets that would limit which requests are handled on that port.
Listener clients, POST/sources, admin, STATS, XSLT, static files - come to mind.
Especial...One thing that might be worth considering is to add another setting to listener sockets that would limit which requests are handled on that port.
Listener clients, POST/sources, admin, STATS, XSLT, static files - come to mind.
Especially in case of professional installations there is often the desire to limit exposure to potential attacks to a minimum.
That way there could be a listener client port on public IP, while all advanced functionality would only be available on a firewalled IP/port.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2070openSSL configuration overhaul in Icecast2023-01-03T10:26:01ZThomas B. RückeropenSSL configuration overhaul in IcecastI'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's sy...I'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's systems, but still we should do our part to prevent bad things from happening.
There will be dependent tickets filed for certain aspects.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2054[PATCH] On-Demand relay mount doesn't has on_demand set on startup2018-03-06T12:49:47ZMarvin Scholz[PATCH] On-Demand relay mount doesn't has on_demand set on startupA `<relay>` that has the `on-demand` option set is missing this information on icecast's first startup, when looking at the stats xml
```
<source mount="/diff.mp3">
<listener_peak>0</listener_peak>
<listeners>0</listeners>
...A `<relay>` that has the `on-demand` option set is missing this information on icecast's first startup, when looking at the stats xml
```
<source mount="/diff.mp3">
<listener_peak>0</listener_peak>
<listeners>0</listeners>
<listenurl>http://localhost:8000/diff.mp3</listenurl>
<max_listeners>unlimited</max_listeners>
<public>0</public>
</source>
```
missing the `<on_demand>1</on_demand>` on first startup. When a listener connects and it therefore connects to the relayed stream, it will have this set. The patch makes sure that this is set initially too.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2039Icecast segfault : auth_url.c2018-03-06T12:49:47ZTeddyIcecast segfault : auth_url.cHi !
I'm using Icecast 2.4.0 with stream_auth authentication option.
When Nicecast (OSX streaming client) connects and sends metadata, a segfault occurs.
I investigated a bit, and it seems that _client->username_ and _client->password_...Hi !
I'm using Icecast 2.4.0 with stream_auth authentication option.
When Nicecast (OSX streaming client) connects and sends metadata, a segfault occurs.
I investigated a bit, and it seems that _client->username_ and _client->password_ (auth_url.c, lines 542/543) are both _null_.
My icecast.xml config file is almost genuine (changed the port, and configured a mountpoint with stream_auth). Please see attachments.
Here is a GDB run :
```
(gdb) run -c etc/icecast.xml
Starting program: /home/radioking/icecast-dbg/icecast-2.4.0/build/bin/icecast -c etc/icecast.xml
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7fda700 (LWP 16800)]
[New Thread 0x7ffff7f59700 (LWP 16801)]
[New Thread 0x7ffff7ed8700 (LWP 16802)]
[New Thread 0x7ffff14ca700 (LWP 16803)]
[New Thread 0x7ffff1449700 (LWP 16804)]
[Thread 0x7ffff1449700 (LWP 16804) exited]
[New Thread 0x7ffff083f700 (LWP 16805)]
[New Thread 0x7ffff07be700 (LWP 16806)]
[Thread 0x7ffff083f700 (LWP 16805) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fda700 (LWP 16800)]
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: Aucun fichier ou dossier de ce type.
```
And the backtrace :
```
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x000000000040ba9c in util_url_escape (src=0x0) at util.c:269
#2 0x000000000041e0db in url_stream_auth (auth_user=<optimized out>)
at auth_url.c:542
#3 0x000000000041ac80 in stream_auth_callback (auth=0x64cf20, auth_user=0x684280)
at auth.c:248
#4 0x000000000041a5cf in auth_run_thread (arg=arg@entry=0x64cf20) at auth.c:311
#5 0x0000000000421e77 in _start_routine (arg=0x657550) at thread.c:657
#6 0x00007ffff68c4182 in start_thread (arg=0x7ffff7fda700) at pthread_create.c:312
#7 0x00007ffff65f130d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
```Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2018Add a web interface equivalent of SIGHUP2018-03-06T12:49:47ZwillwhAdd a web interface equivalent of SIGHUPI run icecast2 on windows, and it'd be great to have some HTTP interface I could POST to, to call a reload to add mounts, without kicking any sources or clients from the running mounts.
Thanks guys!I run icecast2 on windows, and it'd be great to have some HTTP interface I could POST to, to call a reload to add mounts, without kicking any sources or clients from the running mounts.
Thanks guys!Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2010Improve Icecast htpasswd hash storage security2023-02-21T23:42:29ZThomas B. RückerImprove Icecast htpasswd hash storage securityCurrently Icecast uses unsalted md5 hashes of passwords.
Once an attacker obtains access to those the risk is high that simple passwords will be broken by simple md5 look-up through web search.
We should move to using bcrypt, as it's li...Currently Icecast uses unsalted md5 hashes of passwords.
Once an attacker obtains access to those the risk is high that simple passwords will be broken by simple md5 look-up through web search.
We should move to using bcrypt, as it's license permits us to incorporate it, also it should allow us to be compatible with the standard htpasswd(1) manipulation tool.
In the meanwhile using forwarded http authentication potentially offers higher security by deferring authentication to another http server.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1973Allow standard HTTP method instead of non-standard "STATS" for opening stats ...2023-01-28T20:46:15ZjA_cOpAllow standard HTTP method instead of non-standard "STATS" for opening stats streamMany HTTP libraries don't support using non-standard HTTP methods, so this can be a blocking issue.
Many HTTP libraries don't support using non-standard HTTP methods, so this can be a blocking issue.
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1959Icecast to accept custom REMOTE IP headers for reverse proxy compatibility.2022-11-10T18:58:16ZYahavIcecast to accept custom REMOTE IP headers for reverse proxy compatibility.Would be nice to be able to set a custom header name in the config in which Icecast will check for the remote ip address.
(<IP-HEADER>X-Forwarded-For</IP-HEADER>)
will be useful with reverse proxying and such.
(Implemented in KH-2.3.3-kh...Would be nice to be able to set a custom header name in the config in which Icecast will check for the remote ip address.
(<IP-HEADER>X-Forwarded-For</IP-HEADER>)
will be useful with reverse proxying and such.
(Implemented in KH-2.3.3-kh1: http://karlheyes.github.io ) Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1939Webinterface shows Login when using just stream_auth2018-03-06T12:49:48ZcatoWebinterface shows Login when using just stream_authA stream is configured just with stream_auth. The webinterface shows an login-link anyway. Clients can still access the stream, if they use the direct link.
This happens because the xsl just looks for an authenticator for the mount, whi...A stream is configured just with stream_auth. The webinterface shows an login-link anyway. Clients can still access the stream, if they use the direct link.
This happens because the xsl just looks for an authenticator for the mount, which is "url" in this case. There is no possibility to check whether the authenticator applies for sources or for clients.Icecast 2.5.0Philipp SchafftPhilipp Schafft