Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2023-02-21T23:42:29Zhttps://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/2094YP protocol documentation / revision2018-03-06T12:49:38ZThomas B. RückerYP protocol documentation / revisionWe should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https...We should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https://wiki.xiph.org/Icecast/YP-protocol-v2Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2008A hang in send_ogg_headers()2020-02-14T13:10:21ZartemA hang in send_ogg_headers()I've recently had the following hang of icecast2 server. Not sure if it's the first time, but it's pretty rare anyway, so i can't reliably reproduce, but this time i managed to debug a little.
I'm running on ubuntu 12.04 vps with defaul...I've recently had the following hang of icecast2 server. Not sure if it's the first time, but it's pretty rare anyway, so i can't reliably reproduce, but this time i managed to debug a little.
I'm running on ubuntu 12.04 vps with default package (icecast2-2.3.2-9ubuntu1), didn't try to pull the latest svn version yet.
```
$ tail /var/log/icecast2
...
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
...
```
```
$ strace -p `pidof icecast2` -f 2>&1 | grep send
...
[pid 26113] send(14, 0x5ff8e559, 2406954578, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e558, 2406954579, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e557, 2406954580, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e556, 2406954581, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e555, 2406954582, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e554, 2406954583, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e553, 2406954584, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e552, 2406954585, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e551, 2406954586, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e550, 2406954587, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54f, 2406954588, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54e, 2406954589, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54d, 2406954590, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54c, 2406954591, 0) = -1 EPIPE (Broken pipe)
...
```
You may notice how buffer address decreases by 1 and buffer length increases by 1 on every line; no other `send()` calls happen, so i could easily backtrace them:
```
$ gdb -p `pidof icecast`
...
Breakpoint 1, 0xb7461e40 in send () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
(gdb) bt
#0 0xb7461e40 in send () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
#1 0x08067c40 in sock_write_bytes (sock=14, buff=0x5f08fe9d, len=2422676750) at sock.c:360
#2 0x0804f9aa in connection_send (con=0x9748ac8, buf=0x5f08fe9d, len=2422676750) at connection.c:303
#3 0x08058d20 in client_send_bytes (client=0x9740a38, buf=0x5f08fe9d, len=2422676750) at client.c:202
#4 0x0805e6c2 in send_ogg_headers (headers=0xb666e848, client=0x9740a38) at format_ogg.c:500
#5 write_buf_to_client (client=0x9740a38) at format_ogg.c:534
#6 0x08054f57 in send_to_listener (deletion_expected=0, client=0x9740a38, source=0xb647c7d8) at source.c:544
#7 source_main (source=0xb647c7d8) at source.c:716
#8 0x0805564f in source_client_thread (arg=0xb647c7d8) at source.c:1225
#9 0x08068b2f in _start_routine (arg=0xb6674970) at thread.c:655
#10 0xb745ad4c in start_thread () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
#11 0xb7398ace in clone () from /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6
...
```
Thomas B. RückerThomas B. Rückerhttps://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/2004calls to abort() should be removed and checks for memory allocation failture ...2018-10-18T08:03:57ZPhilipp Schafftcalls to abort() should be removed and checks for memory allocation failture to be addedicecast calls abort() 3 times. All 3 times are related to memory allocation. It is used to avoid the need to handle errors on memory allocation. In many other places memory allocation is not checked to be successful.
* all calls to abor...icecast calls abort() 3 times. All 3 times are related to memory allocation. It is used to avoid the need to handle errors on memory allocation. In many other places memory allocation is not checked to be successful.
* all calls to abort() should be removed.
* all calls to malloc(), calloc() and realloc() should be checked handling errors correctly.
* There should be a policy on what happens on memory allocation failure (icecast dropping clients/resources OR dieing?)
* icecast should (at high/all cost) try to inform the user about this problem.
* memory failure can have many reasons. Not just the system being out of memory.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2091Fix up ogg serial numbers for incoming streams in Icecast2018-03-06T12:49:38ZThomas B. RückerFix up ogg serial numbers for incoming streams in IcecastWe should do this server side, there are too many broken things out there.
Ices has some code for this if we need a reference.We should do this server side, there are too many broken things out there.
Ices has some code for this if we need a reference.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2003refbuf should be replaced2018-10-18T08:03:57ZPhilipp Schafftrefbuf should be replacedrefbuf is a type of objected used to store binary data. As the name suggest it has an internal reference counter that allows it to be freed automatically when no longer in use.
the old refbuf objects aren't well designed and allow direc...refbuf is a type of objected used to store binary data. As the name suggest it has an internal reference counter that allows it to be freed automatically when no longer in use.
the old refbuf objects aren't well designed and allow direct access to internal data structures. This became abused.
The new object type MUST:
* be well designed,
* not allow access to internal data structures,
* have a well designed API to access the object's content in a secure way.Icecast 2.6Philipp 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/2085Removal of <threadpool>2018-11-09T14:06:15ZPhilipp SchafftRemoval of <threadpool><threadpool> should be removed as it is no longer in use.
I suggest to add a ERROR level message on usage in 2.4.2 informing the user about this.
Then I suggest that we remove the setting completely in 2.5.0, not before in about one year.<threadpool> should be removed as it is no longer in use.
I suggest to add a ERROR level message on usage in 2.4.2 informing the user about this.
Then I suggest that we remove the setting completely in 2.5.0, not before in about one year.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://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/2084Add support for ANSI streaming2021-10-26T09:40:29ZPhilipp SchafftAdd support for ANSI streamingStreaming in Text+ANSI Codes should be added to icecast. This would allow to to send shows of e.g. text adventures or other text games and applications.Streaming in Text+ANSI Codes should be added to icecast. This would allow to to send shows of e.g. text adventures or other text games and applications.Icecast 2.6https://gitlab.xiph.org/xiph/icecast-server/-/issues/1944Rework STATS interface2018-10-18T08:01:51ZcatoRework STATS interfaceThe current STATS interface which can be accessed via "curl -X STATS http://server:8000/" lacks some features:
1) Not compliant with HTTP spec:
- method needs to be changed from STATS to GET and with
that the target URL has also ...The current STATS interface which can be accessed via "curl -X STATS http://server:8000/" lacks some features:
1) Not compliant with HTTP spec:
- method needs to be changed from STATS to GET and with
that the target URL has also to be changed
- Sent HTTP-Response headers, define mime-type
2) Add lines for mount add/remove, for example "ADD /test.ogg" and "REMOVE /test.ogg"
3) Remove spurious "null null" entries
Philipp 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/1941fallback support in webm2019-06-26T17:23:34Zocxfallback support in webmDear Community,
We noticed that the fallback stream for webm is not working fine, we included a file named fallback.webm in /usr/local/share/icecast/web
if we try to access the stream when no source is connected we get the following err...Dear Community,
We noticed that the fallback stream for webm is not working fine, we included a file named fallback.webm in /usr/local/share/icecast/web
if we try to access the stream when no source is connected we get the following error:
[2013-03-28 00:14:45] INFO source/source_main listener count on /fallback.webm now 1
[2013-03-28 00:14:45] EROR format/format_check_http_buffer internal problem, dropping client
[2013-03-28 00:14:45] INFO source/source_main listener count on /fallback.webm now 0
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2074symlink icecast docs into web dir during install2018-03-06T12:49:39ZThomas B. Rückersymlink icecast docs into web dir during installThis would make the docs much more discoverable for the average user.
We could then simply link to them from the status page and the admin pages.
Docs are already HTML as we also expose them through http://icecast.org/docs/ for each ver...This would make the docs much more discoverable for the average user.
We could then simply link to them from the status page and the admin pages.
Docs are already HTML as we also expose them through http://icecast.org/docs/ for each version
On Windows it would be a full copy instead.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1938timelimit_header is not considered for stream_auth2018-03-06T12:49:39Zcatotimelimit_header is not considered for stream_authProblem:
A url is configured for stream_auth to limit the authentication for sources. The configured URL returns a "icecast-auth-timelimit: 600"-header, but the source does not get disconnected after 10 minutes.Problem:
A url is configured for stream_auth to limit the authentication for sources. The configured URL returns a "icecast-auth-timelimit: 600"-header, but the source does not get disconnected after 10 minutes.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2073Turn on Forward Secrecy in openSSL support2022-03-21T09:33:34ZThomas B. RückerTurn on Forward Secrecy in openSSL supportThis would further improve security in case of HTTPS usage.
This will need a patch to configure the curve to be used.
cf.
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
https://github.com/bumptech/stud/pull/61/...This would further improve security in case of HTTPS usage.
This will need a patch to configure the curve to be used.
cf.
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
https://github.com/bumptech/stud/pull/61/filesIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1880Join video streams on keyframes2018-03-06T12:49:39ZGregory MaxwellJoin video streams on keyframesFor keyframe based video (as opposed to rolling intra refresh) clients can't display output (correctly at least) until they hit a keyframe.
So it would be useful if streams started on keyframes. There are a couple options for this.
If ...For keyframe based video (as opposed to rolling intra refresh) clients can't display output (correctly at least) until they hit a keyframe.
So it would be useful if streams started on keyframes. There are a couple options for this.
If latency is unimportant and the server doesn't mind the memory usage it could buffer the span between keyframes and when a client attaches attach them back at the last keyframe. This would be like a keyframe adaptive preburst.
Alternatively, if latency matters more the server could reencode.
The best way to do this would be to constantly reencode with a very short keyframe interval (e.g. 1-12 frames) and play this out to new clients until a real keyframe comes. Optionally a 'loading' spinner could be displayed to avoid confusion from the low quality during this span. This is O(N) in the number of streams and O(1) in the number of users.
For some formats it would be possible to do some format specific smartness. E.g. in theora You could retransmit the prior keyframe timestamped as NOW-2, then reencode the prior frame (using all intra blocks at high quality) as NOW-1. Then splice in the stream. There will be some corruption until the next keyframe but it should be very minor. Unfortunately it would cause a jump in the visible output because the first frame is an old one.
Alternatively, alternatively, a pre-encoded short GOP "loading" video stream could be sent to users before the first new keyframe. Audio could be spliced in instantly however. This would avoid encoding in the icecast server.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1936Add <audio> and <video> elements to supported streams on status page.2018-06-16T22:37:50ZThomas B. RückerAdd <audio> and <video> elements to supported streams on status page.Now that Firefox will ship with fixed chaining we can push this much more.
By supported I mean at least: vorbis, Opus, theora, WebMNow that Firefox will ship with fixed chaining we can push this much more.
By supported I mean at least: vorbis, Opus, theora, WebMIcecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1877Binding to IPv6 broken on win32 Icecast?2020-02-14T13:01:05ZThomas B. RückerBinding to IPv6 broken on win32 Icecast?This was reported first by mharris on IRC.
He's running WinXP SP3.
I then tried to reproduce it on Win7 64bit with both Icecast 2.3.2 and Icecast 2.3.2-kh33.
On the official build icecast2console.exe will fail to start when given an IPv6...This was reported first by mharris on IRC.
He's running WinXP SP3.
I then tried to reproduce it on Win7 64bit with both Icecast 2.3.2 and Icecast 2.3.2-kh33.
On the official build icecast2console.exe will fail to start when given an IPv6 bind-address (both :: and [::] and also explicit address in both forms). On the KH build it starts but doesn't bind to a port.
I didn't manage to get useful logs out on the official build.
The KH build though complains in the form:
EROR connection/connection_setup_sockets Could not create listener socket on port 8000 bind ::
PS: Unless there is an instant fix, this will miss the window for 2.3.3.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1902Icecast should implement RFC 5334 / 4281 support ("codecs" Media Type parameter)2021-10-30T09:39:38ZThomas B. RückerIcecast should implement RFC 5334 / 4281 support ("codecs" Media Type parameter)Just stumbled into this while working on Opus support in the YP server code.
Proper support for "; codecs=" as specified in RFC 5334 / 4281 in the content-type would be desireable. This could then be used to present proper information i...Just stumbled into this while working on Opus support in the YP server code.
Proper support for "; codecs=" as specified in RFC 5334 / 4281 in the content-type would be desireable. This could then be used to present proper information in the web interface and when submitting to YP. It would also provide hinting for listener clients.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1860[PATCH] Send credentials when doing master-relay2018-11-10T13:05:22Zcato[PATCH] Send credentials when doing master-relayWhen using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentia...When using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentials to the master-icecast. The natural choice would be to send the `<master-username>` and `<master-password>`.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1900Icecast errors in name resolution2020-10-02T11:59:15ZWaitman GobbleIcecast errors in name resolution(seen in Icecast 2.3.99.0 (Beta-2.4) and -HEAD)
the user _may_ see error messages such as the following in /usr/local/share/icecast/log/error.log (default location)
[2012-09-06 02:54:40] EROR yp/send_to_yp connection to http://dir.xip...(seen in Icecast 2.3.99.0 (Beta-2.4) and -HEAD)
the user _may_ see error messages such as the following in /usr/local/share/icecast/log/error.log (default location)
[2012-09-06 02:54:40] EROR yp/send_to_yp connection to http://dir.xiph.org/cgi-bin/yp-cgi failed with "Could not resolve host: dir.xiph.org; Unknown error"
This error _appears_ to be related to using the default libcurl resolver, which is blocking, in an application using pthreads. (seen in curl -v 7.27.0, *may also be an issue in other versions)
The error does *not* appear to be caused by Icecast, HOWEVER an Icecast user _may_ experience this error (which seems to be /lightly/ reported). The user may presume that Icecast has an issue. (So it might be good to mention in the documentation somewhere, or at least appear somewhere in public, such as this space, if somebody else runs into the problem and resorts to a search engine query.) Therefor, perhaps a 'documentation enhancement'.
A solution is to build curl with the c-ares resolver, which is non-blocking and asynchronous.
```
install c-ares, ie
# git clone git://github.com/bagder/c-ares.git
# cd c-ares
# ./buildconf
# ./configure
# make -j7 && make install
```
(http://c-ares.haxx.se/)
install curl
```
./configure --with-ssl=/usr/local/ssl/ --enable-ares=/usr/local
```
to check your curl install for the c-ares resolver: (note c-ares and AsynchDNS)
```
# curl --version
curl 7.27.0 (x86_64-unknown-linux-gnu) libcurl/7.27.0 OpenSSL/1.0.0g zlib/1.2.3 c-ares/1.10.0-DEV libidn/0.6.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz
```Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1853Update graphics for Icecast documentation2018-03-06T12:49:39ZThomas B. RückerUpdate graphics for Icecast documentationRedoing some screenshots and graphics in a lossless format like PNG is desireable. Currently some are JPEG.
Please check back with dm8tbr as to when the web layout is final.
Target 2.3.3 if possible.Redoing some screenshots and graphics in a lossless format like PNG is desireable. Currently some are JPEG.
Please check back with dm8tbr as to when the web layout is final.
Target 2.3.3 if possible.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1892Allow transient reconfiguration of all mount point parameters2018-03-06T12:49:39ZThomas B. RückerAllow transient reconfiguration of all mount point parametersgive the source user more freedom in controlling mount point options through admin requests.
How do we split control of <mount> options?
We could have XML tag attributes to control outside access: <stream-name allow-override="no">fooba...give the source user more freedom in controlling mount point options through admin requests.
How do we split control of <mount> options?
We could have XML tag attributes to control outside access: <stream-name allow-override="no">foobar</stream-name>
where override could be:
* yes - allow setting this value externally
* no - only the xml config file value may set this
* 'unset' - a default value is used if the attribute is not set. The default should be documented though!
Also, we should check the life-cycle for this. Do the settings get reset to the XML defined settings and defaults upon disconnection of the source client or do they persist until either the config is reloaded or the server restarted? I'd tend towards the latter and give an option to 'reset' from source side both during connect and at arbitrary points in time.Icecast 2.6Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1851Should Icecast use $hostname instead of the value from the GET request for re...2018-11-10T12:44:08ZThomas B. RückerShould Icecast use $hostname instead of the value from the GET request for replies?Icecast uses the hostname supplied by the client in HTTP headers for replies. Should it use the hostname set in the config instead?
Target is 2.4.0
_after some discussion on IRC:_
It is apparent that the current behaviour is well suit...Icecast uses the hostname supplied by the client in HTTP headers for replies. Should it use the hostname set in the config instead?
Target is 2.4.0
_after some discussion on IRC:_
It is apparent that the current behaviour is well suited as general purpose default. (This e.g. prevents breaking in LAN/NAT/Internet setups or when the server is being accessed on different IPs and or different host names)
I am still of the opinion that there are several cases where being able to *optionally* override the hostname used in dynamic replies by the one set in the config does make sense.
* reverse proxies (although not recommended) might access the icecast server by only internally resolving host-names. This would deliver the client a broken generated playlist file.
* some server admins want to force a _single_ and _specific_ host name to be returned by the server (e.g. to ensure RRDNS, to avoid unauthorized 3rd parties defining FQDN for the server and having the server _return_ that unauthorized FQDN in dynamic playlists)
* http vs. https scenarios might break things too (e.g. different server/proxy/request-routing per port). _listenurl_ is *always* httpThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1655OggFLAC metadata not supported in Icecast2022-03-16T01:33:34ZJim CollinsonOggFLAC metadata not supported in IcecastAs a business we would really like to start streaming in lossless OggFLAC, but Icecast does not support metadata from OggFLAC. So this is a no-go for us at the moment.
FLAC uses Vorbis comments, so surly this wouldn't be difficult to ac...As a business we would really like to start streaming in lossless OggFLAC, but Icecast does not support metadata from OggFLAC. So this is a no-go for us at the moment.
FLAC uses Vorbis comments, so surly this wouldn't be difficult to achieve?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1606default station description for shoutcast source2018-11-10T15:54:39Zmoodefault station description for shoutcast sourcefor shoutcast source, description is not submited because there's no such thing in shoutcast world.
it would be nice if icecast server can "default" not "force" station description for shoutcast source (or even other source that has empt...for shoutcast source, description is not submited because there's no such thing in shoutcast world.
it would be nice if icecast server can "default" not "force" station description for shoutcast source (or even other source that has empty station description)
the same may applies to station name, which is not needed most of the caseMarvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1296Freeze Metadata2018-11-08T14:02:57ZGitlab BotFreeze Metadatait will be cool if i can myself determine artist or title that will be seen in winamp while streaming it can be done for example
<mount>
<mount-name>/Mount</mount-name>
<password>password</password>
<artist-name>...it will be cool if i can myself determine artist or title that will be seen in winamp while streaming it can be done for example
<mount>
<mount-name>/Mount</mount-name>
<password>password</password>
<artist-name> Artist name </artist-name>
</mount>
and in winamp i will see "Artist name" (current song that is playing) it is very usefull when u don`t want listeners to see names of tracks and ur streaming program can`t off sending metadata for example virtual dj or tractor
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1272Moving clients on authentication failure2020-10-18T16:15:17ZmuelliMoving clients on authentication failureI want to move a client if she didn't pass my url authentication.
e.g.
```
<mount>
<mount-name>/mount</mount-name>
<authentication type="url">
<option name="mount_add" value="http://some/url"/>
...I want to move a client if she didn't pass my url authentication.
e.g.
```
<mount>
<mount-name>/mount</mount-name>
<authentication type="url">
<option name="mount_add" value="http://some/url"/>
<option name="mount_remove" value="http://some/url"/>
<option name="listener_add" value="http://some/url"/>
<option name="listener_remove" value="http://some/url"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
<!-- 1st example. Moving to other mount -->
<on-authentication-failure>/othermount</on-authentication-failure>
<!-- 2nd example. Playing pre-recorded file -->
<on-authentication-failure>/sorry.ogg</on-authentication-failure>
<!-- 3rd example. Firstplaying pre-recorded file, then play the stream anyway (or move to other mount) -->
<on-authentication-failure>sorry.ogg+/othermount</on-authentication-failure>
</mount>
```
Especially the 3rd example looks difficult, but I'd say it's a legitimate use-case to tell the listener that she didn't authenticate properly and is now getting e.g. a lower quality stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1195StreamTitle Template for Icecast 22018-11-08T14:02:03ZscratchStreamTitle Template for Icecast 2In Icecast 1 it seemed to be possible to append or prepend a string to a title using a StreamTitle template (this is also possible in shoutcast):
for example:
[yourRadioName] %s
became
[yourRadioName] Some Artist - Some Title
I am not ...In Icecast 1 it seemed to be possible to append or prepend a string to a title using a StreamTitle template (this is also possible in shoutcast):
for example:
[yourRadioName] %s
became
[yourRadioName] Some Artist - Some Title
I am not a coder, and i think icecast2 is Great (good work),
but since it was possible before, I think it shouldn't be so hard
to be able to modify that metadata before icecast sends it to the listeners.
I know you can set such options in a source client, but as you have many djs or channels with their own setups, it provides a standard in the title format. Also, when you would want to set up a commercial service, all stations could be marked with your "powered by".Icecast 2.5.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/920limit of bitrate for each mountpoint2023-01-03T19:11:52ZGitlab Botlimit of bitrate for each mountpointI would like to host an icecast server on my PC and my friends could broadcast with it. But I want to limit the bitrate. The DJ cannot broadcast at more than 128 kbps. How to limit the bitrate for every mountpoint ? or for all mountpoints ?I would like to host an icecast server on my PC and my friends could broadcast with it. But I want to limit the bitrate. The DJ cannot broadcast at more than 128 kbps. How to limit the bitrate for every mountpoint ? or for all mountpoints ?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/887[PATCH] Multiple master servers for Icecast relay2018-06-15T21:32:52Zjcyr[PATCH] Multiple master servers for Icecast relayAt any time during the day there are 4 or 5 PCs or IP radios tuned to a common MP3 internet stream. In order to alleviate the traffic on my internet broadband link, I use an Icecast relay on my local network. It retrieves a single Shoutc...At any time during the day there are 4 or 5 PCs or IP radios tuned to a common MP3 internet stream. In order to alleviate the traffic on my internet broadband link, I use an Icecast relay on my local network. It retrieves a single Shoutcast stream from the Internet and all the local clients get their streams from it.
Icecast has worked very well in that capacity but has always suffered from a minor shortcoming. Many popular Shoutcast stations provide the same stream through multiple servers. Unfortunately, Icecast 2.3.1 only allows the specification of a single master server for each relay section. So if that master server refuses the connection there is no way to tell Icecast to try an alternate. I've coded a patch to the Icecast 2.3.1 source that allows the specification of multiple master servers. For each relay, Icecast will try each of the multiple servers that can now be specified till a connection is achieved.
The relay section in the icecast.xml file now looks like this:
<relay>
<servers>
<server>
<ip>64.236.34.196</ip>
<port>80</port>
</server>
<server>
<ip>64.236.34.4</ip>
<port>80</port>
</server>
</servers>
<mount>/stream/1048</mount>
<local-mount>/stream.mp3</local-mount>
<on-demand>0</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
If anybody's interested and in the spirit of open source development I've made the patch available as a contribution to the community. It can be downloaded at http://www.dillobits.com/icecast-2.3.1-patch.txt .
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/807Viewing the last X number of lines from logfile in Icecast Web Admin2020-10-02T11:46:58Zdj_transidViewing the last X number of lines from logfile in Icecast Web AdminIn the Icecast web admin is it possible to have it show say X number of lines from the errors.log just so that the admin doesnt need to have shell access to know what is going on the background, shoutcast has the same thing where it tail...In the Icecast web admin is it possible to have it show say X number of lines from the errors.log just so that the admin doesnt need to have shell access to know what is going on the background, shoutcast has the same thing where it tails the log file. just a thought.
Thanks,
~BrianIcecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/794[PATCH] Autotools and header fixes2018-06-15T21:35:52Zgtgbr[PATCH] Autotools and header fixes* Improve autotools handling of sys/time.h and time.h -- it should be checked whether both may be included simultaneously.
* Actually use the XIPH_C__FUNC__ macro, since #ifdef __SUNPRO_C was removed from src/compat.h
* A bit of header...* Improve autotools handling of sys/time.h and time.h -- it should be checked whether both may be included simultaneously.
* Actually use the XIPH_C__FUNC__ macro, since #ifdef __SUNPRO_C was removed from src/compat.h
* A bit of header/includes cleanup. Icecast sources search for support libs locally first, not in system include paths.
* Remove spurious CRs
* Do not let Windows include <stdio.h> twice in src/util.cMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/791[PATCH] More type related cleanups2018-11-10T13:05:43Zgtgbr[PATCH] More type related cleanupsMore type related cleanups:
* Add casts where implicit casting would happen otherwise (covers all, except those int->char casts that are harmless.)
* Resolve accuracy issues, mostly by changing long to int (except in one case in source...More type related cleanups:
* Add casts where implicit casting would happen otherwise (covers all, except those int->char casts that are harmless.)
* Resolve accuracy issues, mostly by changing long to int (except in one case in source.c where it's the other way round)
* More int -> size_t changes when buffer sizes are involved. While doing so, slightly rewrite get_line() in auth_htpasswd.c to not shadow the len parameter.
* While in httpp.h, remove prototype for nonexistent function httpp_parse_icy()
* Adjust sanity checks to not test whether an unsigned variable is < 0
* In net/sock.c, use sizeof(ip) instead of MAX_ADDR_LEN
* Do not forget to #include <sys/types.h> and "compat.h" whenever _t types are usedIcecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/778[PATCH] video preview patch2018-03-06T12:49:39ZGitlab Bot[PATCH] video preview patchHere it is a patch allowing to see a preview of a theora stream in status.xsl page.Here it is a patch allowing to see a preview of a theora stream in status.xsl page.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/635icecast 2.2.0 bugz2018-11-10T12:58:03ZGitlab Boticecast 2.2.0 bugz1) The XSL parser has some unchecked buffers (local),but they dont seem
to be exploitable. If they are, they can be used for priviledge escalation,
under the user that the server runs.
```xslt
<xsl:when test="<lots of chars>"></xsl...1) The XSL parser has some unchecked buffers (local),but they dont seem
to be exploitable. If they are, they can be used for priviledge escalation,
under the user that the server runs.
```xslt
<xsl:when test="<lots of chars>"></xsl:when>
<xsl:if test="<lots of chars>"></xsl:if>
<xsl:value-of select="<lots of chars>" />
```
2) Cause XSL parser error "Could not parse XSLT file". (Not very useful).
```
GET /status.xsl> HTTP/1.0
GET /status.xsl< HTTP/1.0
GET /<status.xsl HTTP/1.0
```
3) XSL parser bypass. (Useful to steal customized XSL files, lol).
```
GET /auth.xsl. HTTP/1.0
GET /status.xsl. HTTP/1.0
```
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/595fallback management in /admin/ interface2018-06-15T21:35:14ZMike Altrionfallback management in /admin/ interfaceIt would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.It would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/593Tracking mountpoint bandwidth usage (from mailing list)2023-01-03T10:28:03ZAaron PaulleyTracking mountpoint bandwidth usage (from mailing list)Karl asked me to submit this to trac.xiph.org, from the mailing list.
I exclusively use mountpoints to setup my clients' streams. What would be absolutely amazing is if Icecast could log bandwidth usage per mountpoint, so I can better s...Karl asked me to submit this to trac.xiph.org, from the mailing list.
I exclusively use mountpoints to setup my clients' streams. What would be absolutely amazing is if Icecast could log bandwidth usage per mountpoint, so I can better see which mountpoints are using more or less of the bandwidth. I'm using mrtg to monitor the whole server, but it, and every stats program I've tried, has no way of differentiating the various mountpoints.
Thanks!Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/591Bandwidth stats2023-01-03T19:11:54ZGitlab BotBandwidth statsIn icecast1 it was possible to fetch the current used/maximum bandwidth on the server. It seems like these stats got lost in the icecast2 rewrite, and it would be neat to have them back.
It's not anything critical, but it's good to be ab...In icecast1 it was possible to fetch the current used/maximum bandwidth on the server. It seems like these stats got lost in the icecast2 rewrite, and it would be neat to have them back.
It's not anything critical, but it's good to be able to see how much bandwidth the server uses.Icecast 2.6Philipp SchafftPhilipp Schaffthttps://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/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/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/2086[PATCH] Send final status code only after the source data was received2018-03-06T12:49:47ZMarvin Scholz[PATCH] Send final status code only after the source data was receivedIcecasts new PUT support should comply with the HTTP protocol, currently this isn't the case since it sends the status line (`200 OK`) right after the source clients connects, but should only send it at the end of the request. Error code...Icecasts new PUT support should comply with the HTTP protocol, currently this isn't the case since it sends the status line (`200 OK`) right after the source clients connects, but should only send it at the end of the request. Error codes can be sent earlier, since they indicate that transmission of data is finished.
> An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body.
With the success code 200 (and others like 201) this is not the case, since it would indicate Success until all data is received which makes no sense.
If a source client needs a indicator when to start sending data, it should set the `Expect: 100-continue` header and wait for the `100 Continue` reply from the server.
Here is an example what Icecast currently sends:
```
> PUT /testsendung.mp3 HTTP/1.1
> Authorization: Basic REDACTED=
> Host: example.com:8001
> Accept: */*
> Content-Type: audio/ogg
> Ice-Public: 1
> Ice-Name: Teststream
> Ice-Description: This is just a simple test stream
> Ice-URL: http://example.org
> Ice-Genre: Rock
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
> [ Some stream data sent by client ]
< HTTP/1.0 200 OK
> [ More stream data sent by client ]
```
Instead Icecast should send:
```
> PUT /testsendung.mp3 HTTP/1.1
> Authorization: Basic REDACTED=
> Host: example.com:8001
> Accept: */*
> Content-Type: audio/ogg
> Ice-Public: 1
> Ice-Name: Teststream
> Ice-Description: This is just a simple test stream
> Ice-URL: http://example.org
> Ice-Genre: Rock
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
> [ Stream data sent by client ]
< HTTP/1.1 200 OK
< Content-Length: 0
< Connection: close
<
* Closing connection 0
```
(Additionally note that Icecast mixes HTTP Protocol)
This patch fixes the behavior so that it matches the second one. I am not completely sure if I fixed it the right way, since the file server internals are not 100% clear to me.
I marked it was critical since I think we should address this asap, so that (new) source clients do not start to rely on this (wrong) behavior.Philipp 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/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/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/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/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/2077Stats data in iso8601 fields on mingw32 builds is wrong.2018-03-06T12:49:47ZThomas B. RückerStats data in iso8601 fields on mingw32 builds is wrong.We're using %z, which isn't consistent with other platforms. It depends on system configuration but could be a textual representation of the time zone or the time zone offset. The latter is what we want.
There is a workaround in our log...We're using %z, which isn't consistent with other platforms. It depends on system configuration but could be a textual representation of the time zone or the time zone offset. The latter is what we want.
There is a workaround in our logging code for this, which should be applied here too.Icecast 2.5.0https://gitlab.xiph.org/xiph/icecast-server/-/issues/2144Icecast might hang with 100% cpu use upon failed startup2018-10-27T11:17:45ZThomas B. RückerIcecast might hang with 100% cpu use upon failed startupI just ran into it again. It looks like it gets caught up in waiting for something.
Example output when trying to bind to inexistent IPv4 address:
```
$ /usr/bin/icecast -c /etc/icecast.xml
[2015-01-08 05:21:48] EROR connection/connec...I just ran into it again. It looks like it gets caught up in waiting for something.
Example output when trying to bind to inexistent IPv4 address:
```
$ /usr/bin/icecast -c /etc/icecast.xml
[2015-01-08 05:21:48] EROR connection/connection_setup_sockets Could not create listener socket on port 8000 bind 203.0.113.23
[2015-01-08 05:21:48] EROR connection/connection_setup_sockets No listening sockets established
Server startup failed. Exiting
```
"strace -f" doesn't produce any output after writing that last message.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2072Update default SSL cipher list to be more secure2018-03-06T12:49:47ZThomas B. RückerUpdate default SSL cipher list to be more secureCurrently: "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"
Proposed: "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:
DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
This was taken from: https://...Currently: "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"
Proposed: "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:
DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
This was taken from: https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/#fnref2 (scroll up 2 lines)
I've tested this successfully against https://www.ssllabs.com/ssltest/ in combination with the patch for #2071. The only OS/Browser combination failing is: IE 6 / XPIcecast 2.4.1Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2143Regresion: reloadconfig* got de-linked on redesign of admin intrerface2018-03-06T12:49:47ZPhilipp SchafftRegresion: reloadconfig* got de-linked on redesign of admin intrerfaceLinks to the reloadconfig-admin command got lost on update of the design. Those should be re-linked.Links to the reloadconfig-admin command got lost on update of the design. Those should be re-linked.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2071disable SSLv3 and SSL compression explicitly2018-03-06T12:49:47ZThomas B. Rückerdisable SSLv3 and SSL compression explicitly** SSLv3 is broken.
* Disabling compression mitigates the CRIME attack.
see attached patch** SSLv3 is broken.
* Disabling compression mitigates the CRIME attack.
see attached patchIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2133Regression: Role management not possible via admin interface2018-03-06T12:49:47ZPhilipp SchafftRegression: Role management not possible via admin interfaceRole management via admin/ interface is currently not possible as there is no lists of roles displayed. listings of roles must be implemented so user can find the right link to the management page.Role management via admin/ interface is currently not possible as there is no lists of roles displayed. listings of roles must be implemented so user can find the right link to the management page.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2063Go through compiler warnings and such2018-03-06T12:49:47ZThomas B. RückerGo through compiler warnings and suchThere are a couple build time warnings from e.g. gcc that might need to be addressed.
This is the top level ticket for such issues. If you create tickets about build time warnings, please put the ID of this ticket: #2063 into the "Paren...There are a couple build time warnings from e.g. gcc that might need to be addressed.
This is the top level ticket for such issues. If you create tickets about build time warnings, please put the ID of this ticket: #2063 into the "Parent Tickets" field of your ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://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/2059[PATCH] Better code style consistency2018-03-06T12:49:47ZMarvin Scholz[PATCH] Better code style consistencyThis patch makes the overall code style more consistent.This patch makes the overall code style more consistent.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2123Support management of multiple <role>s2018-03-06T12:49:47ZPhilipp SchafftSupport management of multiple <role>sAs with <role> support there can be multiple per <mount> and global <role>s management support in the admin/ interface needs update.
there are 3 most major parts of this:
1. defining format and outputting information about those <role>s...As with <role> support there can be multiple per <mount> and global <role>s management support in the admin/ interface needs update.
there are 3 most major parts of this:
1. defining format and outputting information about those <role>s on a given (mount or global) object.
1. update the admin/*.xsl files to reflect the new interface.
1. update command_manageauth() to reflect the changes.
Please define a format for the output and reassign to me after that.
Examples:
```
<authentication>
<role id="xxx" name="yyy" />
<role id="xxx" name="yyy" />
<role id="xxx" name="yyy" />
</authentication>
```
```
<authentication>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
</authentication>
```
The first example mimics the config file format. The second is more to how stuff in admin/* has been.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2058[PATCH] Replace logging macros2018-03-06T12:49:47ZMarvin Scholz[PATCH] Replace logging macrosReplace the old logging macros with variadic argument macros.
`ERROR0`, `ERROR1`, `ERROR2`, `ERROR3`, `ERROR4` are replaced with `LOG_ERROR`
`WARN0`, `WARN1`, `WARN2`, `WARN3` are replaced with `LOG_WARN`
`INFO0`, `INFO1`, `INFO2`, `INF...Replace the old logging macros with variadic argument macros.
`ERROR0`, `ERROR1`, `ERROR2`, `ERROR3`, `ERROR4` are replaced with `LOG_ERROR`
`WARN0`, `WARN1`, `WARN2`, `WARN3` are replaced with `LOG_WARN`
`INFO0`, `INFO1`, `INFO2`, `INFO3` are replaced with `LOG_INFO`
`DEBUG0`, `DEBUG1`, `DEBUG2`, `DEBUG3`, `DEBUG4` are replaced with `LOG_DEBUG`
Additionally a bit formatting was done, to match common c code style (only where it really shouted for attention, while looking through the files)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2122README.md needs minor fixes2018-03-06T12:49:47ZThomas B. RückerREADME.md needs minor fixese.g. webm and opus missing
Also this ticket will serve for testing git to trac hooks.e.g. webm and opus missing
Also this ticket will serve for testing git to trac hooks.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://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/2121doc subdirectories don't work if packaging overrides "docdir"2018-03-06T12:49:47ZThomas B. Rückerdoc subdirectories don't work if packaging overrides "docdir"Case in point: debian
Patch is in the works as I need it also for my deb/RPM packaging on OBS.Case in point: debian
Patch is in the works as I need it also for my deb/RPM packaging on OBS.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2047Icecast 2.4.0 - status-json.xsl - parse error2018-03-06T12:49:47ZGhost UserIcecast 2.4.0 - status-json.xsl - parse errorHello,
The attached status json file does not parse.
The file is here:
http://www.noizeukradio.com:8000/status-json.xsl
This topic looks similar:
http://icecast.imux.net/viewtopic.php?t=8240
Thanks,
DavidHello,
The attached status json file does not parse.
The file is here:
http://www.noizeukradio.com:8000/status-json.xsl
This topic looks similar:
http://icecast.imux.net/viewtopic.php?t=8240
Thanks,
DavidIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2106Pull vorbis comments (metadata) and send to stats2018-03-06T12:49:47ZMarvin ScholzPull vorbis comments (metadata) and send to stats> Pull out vorbis comments and send to stats. This seems to be being done, but it isn't working right.
Icecast should pull [vorbis comments](http://de.wikipedia.org/wiki/Vorbis_comment) and make them available in stats.> Pull out vorbis comments and send to stats. This seems to be being done, but it isn't working right.
Icecast should pull [vorbis comments](http://de.wikipedia.org/wiki/Vorbis_comment) and make them available in stats.Philipp 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/2102Make strcmp in main.c#_start_logging explicit2018-03-06T12:49:47ZMicheil SmithMake strcmp in main.c#_start_logging explicitCurrently the don't pipe to standard output options are in the else branch, because of usage of `strcmp` such as `if ( strcmp(a, b) ) { `.
This gist https://gist.github.com/miksago/cfb3f41784bff197facc includes changes to make the comp...Currently the don't pipe to standard output options are in the else branch, because of usage of `strcmp` such as `if ( strcmp(a, b) ) { `.
This gist https://gist.github.com/miksago/cfb3f41784bff197facc includes changes to make the comparison of strings explicit as well as changes the logic to be:
```
if config->access_log == '-'; then
handle standard output
else
handle logging
```
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2037Check if Icecast returns HTTP 200 on disallowed metadata updates2018-03-06T12:49:47ZThomas B. RückerCheck if Icecast returns HTTP 200 on disallowed metadata updatesWe've had a report that some version of Icecast might be doing this.
http://lists.xiph.org/pipermail/icecast/2014-August/012905.html
We should check if this is the case and if so consider changing it to a 403, accompanied by a sensible ...We've had a report that some version of Icecast might be doing this.
http://lists.xiph.org/pipermail/icecast/2014-August/012905.html
We should check if this is the case and if so consider changing it to a 403, accompanied by a sensible error message.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2098TAGs for comments in all icecast projects2018-03-06T12:49:47ZPhilipp SchafftTAGs for comments in all icecast projectsI suggest to define the following tags in comments for more easy finding stuff that needs to be reviewed or handled in future release. Those tags should be added as part of the coding style guide to define some standard for the Icecast p...I suggest to define the following tags in comments for more easy finding stuff that needs to be reviewed or handled in future release. Those tags should be added as part of the coding style guide to define some standard for the Icecast project and be used by all components handed by the project including but not limited to the Icecast server, Ices2 and the library subprojects. I'm unsure if/how it will match the stream directory subproject.
The following tags should be defined:
Actions:
- REVIEW: ask for a review of this.
- REWRITE: ask for a rewrite of this section.
- TODO: ask for implementation of a feature.
- FIXME: ask correcting an implementation.
- REMOVE: remove a block or feature.
- DOCUMENT: documentation for this block or feature is missing, incomplete or wrong and needs update.
Conditions:
- [BEFORE|AFTER|IN] RELEASE $version: This is relevant to release $version. $version can also be NEXT.
- [BEFORE|AFTER|IN] YEAR $yyyy: This is relevant to (4-digit) year $yyyy
Extra Tags:
- IMPORTANT: This is an important problem.
- SECURITY: This is security critical.
- LEAK: This leaks some resource (memory, file descriptors, ...).
Syntax:
```
/* [CONDITION[ CONDITION[...]]] [EXTRA TAGS] ACTION [#TICKET]: DESCRIPTION
* [LONG DESCRIPTION]
*/
```
Examples:
```
/* BEFORE RELEASE 2.5.3 REVIEW #1234: Should we convert A to B?
* A is according to standard REF0. This standard was superseded by
* standard REF1 which could be implemented with option B.
* This may break early clients of standard REF0 not being aware of SOMETHING.
*/
/* IN YEAR 2022 REWRITE: Change copyright statement as license expires. */
/* LEAK FIXME #1234: Fix case object can not be added to queue. */
/* BEFORE RELEASE NEXT IMPORTANT SECURITY FIXME #1234: Do not expose passwords on authentication failure of backend server */
/* AFTER RELEASE 2.5.3 REMOVE: Remove support for icecast 1.x style SOURCE requests */
```Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2033Json output fails parser lint2018-03-06T12:49:47ZKompilerJson output fails parser lintStrange json output that fails the json lint test and php fails to parse. Here's a sample output that is broke.
sample broken json:
{"icestats":{"admin":"icemaster@localhost","host":"localhost","location":"Earth","server_id":"Icecast ...Strange json output that fails the json lint test and php fails to parse. Here's a sample output that is broke.
sample broken json:
{"icestats":{"admin":"icemaster@localhost","host":"localhost","location":"Earth","server_id":"Icecast 2.4.0","server_start":"Tue, 29 Jul 2014 00:53:00 +0200","server_start_iso8601":"2014-07-29T00:53:00+0200","source":[{"audio_info":"bitrate=256;channels=2;samplerate=44100","bitrate":256,"channels":2,"genre":"Various","listener_peak":0,"listeners":0,"listenurl":"http://localhost:8000/User","samplerate":44100,"server_description":"User live in the mix on server.tv!","server_name":"server.tv - User","server_type":"audio/mpeg","server_url":"http://server.tv/live/index/User","stream_start":"Tue, 29 Jul 2014 00:53:01 +0200","stream_start_iso8601":"2014-07-29T00:53:01+0200",,{"audio_info":"bitrate=256;channels=2;samplerate=44100","bitrate":256,"channels":2,"genre":"Various","listener_peak":0,"listeners":0,"listenurl":"http://localhost:8000/autodj","samplerate":44100,"server_description":"server.tv Replays","server_name":"server.tv Radio","server_type":"audio/mpeg","server_url":"http://server.tv/","stream_start":"Tue, 29 Jul 2014 00:53:01 +0200","stream_start_iso8601":"2014-07-29T00:53:01+0200","title":"server.tv Radio: User - M”ix,]}}Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2097In <listener> in some tags are camelcase that should be converted to lowercase.2018-03-06T12:49:47ZPhilipp SchafftIn <listener> in some tags are camelcase that should be converted to lowercase.in <listener> the following tags are camelcase: <ID>, <IP>, <UserAgent> and <Connected>. Those should be converted to lower case.
XML tells that tag names are case sensitive.
This needs to be documented before we can change it and be cha...in <listener> the following tags are camelcase: <ID>, <IP>, <UserAgent> and <Connected>. Those should be converted to lower case.
XML tells that tag names are case sensitive.
This needs to be documented before we can change it and be changed with a major release. I suggest to document it as 'Parsers MUST be case insensitive for ALL tags in ANY admin/-command output.'
```
09:51 <+tbr> as a broad statement, I'd not expect this change to happen before 2.6
09:52 < ph3-der-loewe> I haven't thought about a timeline for that already.
09:52 < ph3-der-loewe> I'm fine with <= 3.0.0 :)
09:53 < ph3-der-loewe> with 3.0.0 the question that arise is if the interface still exist ;)
```
Please review this before 2.5 to check if we are on-track on this.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2031Admin functions do not accept URL encoded values2018-03-06T12:49:47ZBradAdmin functions do not accept URL encoded valuesThe admin functions should accept/decode the mount GET value since / is a reserved character.
This works:
http://192.168.1.10:8000/admin/metadata?mount=/mystream&mode=updinfo&song=ACDC+Back+In+Black
This doesn't:
http://192.168.1.10:80...The admin functions should accept/decode the mount GET value since / is a reserved character.
This works:
http://192.168.1.10:8000/admin/metadata?mount=/mystream&mode=updinfo&song=ACDC+Back+In+Black
This doesn't:
http://192.168.1.10:8000/admin/metadata?mount=%F2mystream&mode=updinfo&song=ACDC+Back+In+Black
Response is: 400 - Source does not exist
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2096use setresuid()/setresgid() instead of setuid()/setgid()2018-03-06T12:49:47Zd26264b9use setresuid()/setresgid() instead of setuid()/setgid()We should be dropping privileges with setresuid()/setresgid() when requested as recommended by "Setuid Demystified" (http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf).
Also, chdir("/") after chroot() and actually check for pro...We should be dropping privileges with setresuid()/setresgid() when requested as recommended by "Setuid Demystified" (http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf).
Also, chdir("/") after chroot() and actually check for proper return values on both. This was modelled after OpenSSH's chroot() logic.
Tested on OpenBSD. Someone should try compiling/testing on Linux to verify. As far as I can tell, the proper syscalls are implemented on Linux as well.
```
--- src/main.c Mon May 5 18:29:06 2014
+++ src/main.c Thu Nov 27 18:55:34 2014
@@ -377,7 +377,7 @@
fprintf(stderr, "WARNING: Cannot change server root unless running as root.\n");
return;
}
- if(chroot(conf->base_dir))
+ if(chroot(conf->base_dir) == -1 || chdir("/") == -1)
{
fprintf(stderr,"WARNING: Couldn't change server root: %s\n", strerror(errno));
return;
@@ -398,7 +398,7 @@
}
if(uid != (uid_t)-1 && gid != (gid_t)-1) {
- if(!setgid(gid))
+ if(!setresgid(gid, gid, gid))
fprintf(stdout, "Changed groupid to %i.\n", (int)gid);
else
fprintf(stdout, "Error changing groupid: %s.\n", strerror(errno));
@@ -406,7 +406,7 @@
fprintf(stdout, "Changed supplementary groups based on user: %s.\n", conf->user);
else
fprintf(stdout, "Error changing supplementary groups: %s.\n", strerror(errno));
- if(!setuid(uid))
+ if(!setresuid(uid, uid, uid))
fprintf(stdout, "Changed userid to %i.\n", (int)uid);
else
fprintf(stdout, "Error changing userid: %s.\n", strerror(errno));
```
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2028Non-existing community link on server information page2018-03-06T12:49:47ZRoland HermansNon-existing community link on server information pageClicking on the Community link of the Server Information web page /server_version.xsl results in a 404 error: "The requested URL /community.php was not found on this server.".
Steps to reproduce:
1. Open the Icecast web interface in a b...Clicking on the Community link of the Server Information web page /server_version.xsl results in a 404 error: "The requested URL /community.php was not found on this server.".
Steps to reproduce:
1. Open the Icecast web interface in a browser
2. Click on Version in the menu
3. Click on the community link (http://icecast.org/community.php)
Actual result:
404 error
Expected result:
Web page with information on the Icecast community is shown.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2089[duplicate] icecast sends output of <on-connect> script to source client2018-03-06T12:49:47ZSven Herzberg[duplicate] icecast sends output of <on-connect> script to source clientPlease look at #2087 instead.
----
Using the on-connect script from #2087, a client which does not close the connection immediately after receiving the 200 response, has a chance of reading “stdout” after stopping to send any data.
If...Please look at #2087 instead.
----
Using the on-connect script from #2087, a client which does not close the connection immediately after receiving the 200 response, has a chance of reading “stdout” after stopping to send any data.
If this is unintentional, this data should end up in e.g. the `<errorlog>` target.
If this is intentional, the length of the data should be indicated by a `Content-Length` header, or should be properly encoded as `Transfer-Encoding: chunked` (which would then be required as a header in the response).Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2020[PATCH] Fix autogen.sh to work properly on Mac OS2018-03-06T12:49:47ZMarvin Scholz[PATCH] Fix autogen.sh to work properly on Mac OSThis patch fixes autogen.sh, so it will not exit with the error that libtool is not installed on Mac OS.
The command `libtoolize` on Mac OS is called `glibtoolize`, this patch makes it check for both versions.
This patch fixes autogen.sh, so it will not exit with the error that libtool is not installed on Mac OS.
The command `libtoolize` on Mac OS is called `glibtoolize`, this patch makes it check for both versions.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2088accept data with “Transfer-Encoding: chunked”2018-03-06T12:49:47ZSven Herzbergaccept data with “Transfer-Encoding: chunked”Many HTTP frameworks will automatically encode data streams using the aforementioned method. I propose this behavior for Icecast:
* check if the protocol is not `HTTP/1.1` or there is no `Transfer-Encoding` header, continue as in the pa...Many HTTP frameworks will automatically encode data streams using the aforementioned method. I propose this behavior for Icecast:
* check if the protocol is not `HTTP/1.1` or there is no `Transfer-Encoding` header, continue as in the past (i.e. assume `identity` encoding)
* if the `Transfer-Encoding` header is present and it is `identity`, continue as in the past
* if the `Transfer-Encoding` header is present and it is `chunked`, accept the data and strip the encoding information both from the output stream and from the dumpfile
* if the `Transfer-Encoding` header is present and has a different value, terminate the request with 501 (Unimplemented) and provide an HTTP response body listing the supported encodings (in case developers need to debug this).
That behavior in compliant with RFC2616 (Section 3.6) and RFC7230 (Section 3.3.1).Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2019[PATCH] Add PLS Playlist Format2018-03-06T12:49:47ZMarvin Scholz[PATCH] Add PLS Playlist FormatThis patch adds support for the pls playlist format.This patch adds support for the pls playlist format.Thomas B. RückerThomas B. Rückerhttps://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/2016Add IP address of the source in error.log2018-03-06T12:49:48ZFrancois LafontAdd IP address of the source in error.logHere is typical content of error.log during a source connection:
```
[2014-05-02 13:43:49] INFO connection/_handle_source_request Source logging in at mountpoint "/test1.mp3"
[2014-05-02 13:43:49] INFO format-vorbis/initial_vorbis_pa...Here is typical content of error.log during a source connection:
```
[2014-05-02 13:43:49] INFO connection/_handle_source_request Source logging in at mountpoint "/test1.mp3"
[2014-05-02 13:43:49] INFO format-vorbis/initial_vorbis_page seen initial vorbis header
[2014-05-02 13:43:49] INFO source/source_main listener count on /test1.mp3 now 0
[2014-05-02 13:43:57] INFO source/get_next_buffer End of Stream /test1.mp3
[2014-05-02 13:43:57] INFO source/source_shutdown Source "/test1.mp3" exiting
```
It will be great if the IP source address was indicate in error.log. For example, something like that:
```
[2014-05-02 13:43:49] INFO connection/_handle_source_request Source (IP=192.168.0.26) logging in at mountpoint "/test1.mp3"
[2014-05-02 13:43:49] INFO format-vorbis/initial_vorbis_page seen initial vorbis header
[2014-05-02 13:43:49] INFO source/source_main listener count on /test1.mp3 now 0
[2014-05-02 13:43:57] INFO source/get_next_buffer End of Stream /test1.mp3
[2014-05-02 13:43:57] INFO source/source_shutdown Source (IP=192.168.0.26) "/test1.mp3" exiting
```
Isn't it? ;-)
Francois LafontIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1995Icecast server configure fails on ibm AIX 72018-03-06T12:49:48ZAlexandruIcecast server configure fails on ibm AIX 7Hello Team,
I'm having trouble compiling the Icecast server version 2.3.3 on IBM AIX version 7100-02-01-1245.
./configure script fails while checking for libvorbis installation with the following message:
"checking for libvorbis......Hello Team,
I'm having trouble compiling the Icecast server version 2.3.3 on IBM AIX version 7100-02-01-1245.
./configure script fails while checking for libvorbis installation with the following message:
"checking for libvorbis... configure: error: must have Ogg Vorbis v1.0 or above installed"
The following libraries have been installed without issues in /opt/freeware/lib:
root@aiiics02:/>rpm -qa|egrep 'vorbis|ogg'
libogg-1.3.0-1
libogg-devel-1.3.0-1
libvorbis-1.3.3-1
libvorbis-devel-1.3.3-1
root@aiiics02:/>rpm -ql libvorbis-1.3.3-1
/opt/freeware/doc/libvorbis-1.3.3
/opt/freeware/doc/libvorbis-1.3.3/AUTHORS
/opt/freeware/doc/libvorbis-1.3.3/COPYING
/opt/freeware/doc/libvorbis-1.3.3/README
/opt/freeware/lib/libvorbis.a
/opt/freeware/lib/libvorbisenc.a
/opt/freeware/lib/libvorbisfile.a
/usr/lib/libvorbis.a
/usr/lib/libvorbisenc.a
/usr/lib/libvorbisfile.a
I'm can send the configure.log file in case it helps and also
help test this on all current AIX versions (5.3, 6.1 & 7.1) so you can add AIX to the supported platforms.
Thanks in advance and best of regards!
-Alex
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1994Icecast server configure fails on ibm AIX 72018-03-06T12:49:48ZAlexandruIcecast server configure fails on ibm AIX 7Hello Team,
I'm having trouble compiling the Icecast server version 2.3.3 on IBM AIX version 7100-02-01-1245.
./configure script fails while checking for libvorbis installation with the following message:
"checking for libvorbis......Hello Team,
I'm having trouble compiling the Icecast server version 2.3.3 on IBM AIX version 7100-02-01-1245.
./configure script fails while checking for libvorbis installation with the following message:
"checking for libvorbis... configure: error: must have Ogg Vorbis v1.0 or above installed"
The following libraries have been installed without issues in /opt/freeware/lib:
root@aiiics02:/>rpm -qa|egrep 'vorbis|ogg'
libogg-1.3.0-1
libogg-devel-1.3.0-1
libvorbis-1.3.3-1
libvorbis-devel-1.3.3-1
root@aiiics02:/>rpm -ql libvorbis-1.3.3-1
/opt/freeware/doc/libvorbis-1.3.3
/opt/freeware/doc/libvorbis-1.3.3/AUTHORS
/opt/freeware/doc/libvorbis-1.3.3/COPYING
/opt/freeware/doc/libvorbis-1.3.3/README
/opt/freeware/lib/libvorbis.a
/opt/freeware/lib/libvorbisenc.a
/opt/freeware/lib/libvorbisfile.a
/usr/lib/libvorbis.a
/usr/lib/libvorbisenc.a
/usr/lib/libvorbisfile.a
I'm also attaching the config.log file in case it helps.
I can help test this on all current AIX versions so you can add AIX to the supported platforms.
Thanks in advance and best of regards!
-Alex
https://gitlab.xiph.org/xiph/icecast-server/-/issues/1993Icecast server configure fails on ibm AIX 72018-03-06T12:49:48ZAlexandruIcecast server configure fails on ibm AIX 7Hello Team,
I'm having trouble compiling the Icecast server version 2.3.3 on IBM AIX version 7100-02-01-1245.
./configure script fails while checking for libvorbis installation with the following message:
"checking for libvorbis... co...Hello Team,
I'm having trouble compiling the Icecast server version 2.3.3 on IBM AIX version 7100-02-01-1245.
./configure script fails while checking for libvorbis installation with the following message:
"checking for libvorbis... configure: error: must have Ogg Vorbis v1.0 or above installed"
The following libraries have been installed without issues in /opt/freeware/lib:
root@aiiics02:/>rpm -qa|egrep 'vorbis|ogg'
libogg-1.3.0-1
libogg-devel-1.3.0-1
libvorbis-1.3.3-1
libvorbis-devel-1.3.3-1
root@aiiics02:/>rpm -ql libvorbis-1.3.3-1
/opt/freeware/doc/libvorbis-1.3.3
/opt/freeware/doc/libvorbis-1.3.3/AUTHORS
/opt/freeware/doc/libvorbis-1.3.3/COPYING
/opt/freeware/doc/libvorbis-1.3.3/README
/opt/freeware/lib/libvorbis.a
/opt/freeware/lib/libvorbisenc.a
/opt/freeware/lib/libvorbisfile.a
/usr/lib/libvorbis.a
/usr/lib/libvorbisenc.a
/usr/lib/libvorbisfile.a
I'm also attaching the configure.log file in case it helps.
I can help test this on all current AIX versions so you can add AIX to the supported platforms.
Thanks in advance and best of regards!
-AlexThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1977check mime-type file handling in win32 build2018-03-06T12:49:48ZThomas B. Rückercheck mime-type file handling in win32 builduser reported a vague problem.
Seems we open a mime-types file from fserve.c
Also there seems to be an undocumented config option when parsing xml.
So might be enough to include a file and point to it in the win32 default config.
Unless ...user reported a vague problem.
Seems we open a mime-types file from fserve.c
Also there seems to be an undocumented config option when parsing xml.
So might be enough to include a file and point to it in the win32 default config.
Unless mingw provides some magic in its libc.Icecast 2.4.1https://gitlab.xiph.org/xiph/icecast-server/-/issues/1963icecast crashes if some XML config settings are empty2018-03-06T12:49:48Zmaepicecast crashes if some XML config settings are empty
## new description:
If you leave a tag empty, our config parsing code using libxml2 will set the variable to NULL, something that we try to prevent by prepopulating vital variables with defaults.
This needs a well thought out fix after ...
## new description:
If you leave a tag empty, our config parsing code using libxml2 will set the variable to NULL, something that we try to prevent by prepopulating vital variables with defaults.
This needs a well thought out fix after understanding our code and where the NULL comes from and what it should be instead (possibly case by case?).
*Workaround:* _Don't set anything in the config to empty tags like <tag></tag>, because bad things will happen!_
## Initial report:
icecast version 2.3.3. when i have this in my config
<accesslog></accesslog>
<errorlog></errorlog>
icecast segfaults. my intention was to turn off logging.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1878[PATCH] This patch adds the possibility to put full urls in the list of strea...2019-01-03T16:34:53ZPhilipp Schafft[PATCH] This patch adds the possibility to put full urls in the list of streams fetched from the master server.(reposted from IRC, cato in #icecast)
This patch adds the possibility to put full urls in the list of streams fetched from the master server. When pointing the <master-relay-*> options to a script instead of an icecast this allows to se...(reposted from IRC, cato in #icecast)
This patch adds the possibility to put full urls in the list of streams fetched from the master server. When pointing the <master-relay-*> options to a script instead of an icecast this allows to setup relays of arbitrary streams easily.Icecast 2.4.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1953auth.xsl m3u filename is wrong2018-03-06T12:49:48Zrasiauth.xsl m3u filename is wrongauth.xsl generates the link for usermanaged servers.
but the file it sends out to the browser is hardcoded:
<form method="GET" action="/admin/buildm3u">
Since this file is missing a file extension it wont work with some mediaplayers tha...auth.xsl generates the link for usermanaged servers.
but the file it sends out to the browser is hardcoded:
<form method="GET" action="/admin/buildm3u">
Since this file is missing a file extension it wont work with some mediaplayers that expect a "m3u" extension.
Version is icecast-2.4-beta3.tar.gzIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1951IceCast2 Mountpoint switchover buffer2018-03-06T12:49:48ZDarrenIceCast2 Mountpoint switchover bufferHi.
I've recently changed my SHOUTcast over to IceCast to stop any dead air and use mount points.
I have one little issue.
When the Auto DJ is connected, the music plays perfectly fine but when a source connects then that's when the ...Hi.
I've recently changed my SHOUTcast over to IceCast to stop any dead air and use mount points.
I have one little issue.
When the Auto DJ is connected, the music plays perfectly fine but when a source connects then that's when the stream starts to buffer, yet the listeners successfully transfer from the /autodj mount to the /live mount and vice versa when a source disconnects.
Now.. when listening via the Centova Cast player at the top, the stream doesn't buffer.. it only buffers when using flash players or any other player for that matter which are outside Centova Cast.
Do you know a way around this? Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1873[PATCH] icecast does not read arbitrary capitalized headers2018-03-06T12:49:48ZPhilipp Schafft[PATCH] icecast does not read arbitrary capitalized headers(Forwarded from cato on IRC because of #1871)
the YP-Interface does not work according to the http rfc. To be specific icecast does not read arbitrary capitalized headers from the answer as the standard says.
I have written my own impl...(Forwarded from cato on IRC because of #1871)
the YP-Interface does not work according to the http rfc. To be specific icecast does not read arbitrary capitalized headers from the answer as the standard says.
I have written my own implementation of the server-side yp-interface. when I return for example "Ypmessage: 1" instead of "YPMessage: 1" icecast doesn't find the header and the submission to my directory fails
Section 4.2 of RFC 2616 says: "Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
the error is in http://svn.xiph.org/icecast/trunk/icecast/src/yp.c in handle_returned_header(..) where instead of strncmp a case-insensitive comparison should be madeIcecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1942Spurious dots inside http request line logged to access log2018-03-06T12:49:48ZThomas B. RückerSpurious dots inside http request line logged to access log*"GET./status.xsl.HTTP/1.1"
vs
"GET /status.xsl HTTP/1.1"*"GET./status.xsl.HTTP/1.1"
vs
"GET /status.xsl HTTP/1.1"Icecast 2.4.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1648[patch] [kh] improve support for shoutcastsource by using ICY instead of HTTP...2018-03-06T12:49:48Zmoo[patch] [kh] improve support for shoutcastsource by using ICY instead of HTTP/1.0mpc/mpc-hc will use it's own http client, "User-Agent: shoutcastsource" try to handle http:// url, but only if the server returns ICY not HTTP/1.0 response
afaik, shoutcast server return ICY
with shoutcastsource client, mpc/mpc-hc will...mpc/mpc-hc will use it's own http client, "User-Agent: shoutcastsource" try to handle http:// url, but only if the server returns ICY not HTTP/1.0 response
afaik, shoutcast server return ICY
with shoutcastsource client, mpc/mpc-hc will work perfect as if it know the server is steam not file
without using shoutcastsource client, they still work, with different handler, maybe a directshow source transformer or something. the source become a file not a stream, mpc/mpc-hc will show a progress indicator, and when you seek it, for example, to 02:00, you'll have to wait for 2:00 for the buffer to finish the seeking
the patch is simpleKarl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1870icecast should send 'expires' in all cases2018-03-06T12:49:48ZThomas B. Rückericecast should send 'expires' in all casescurrently it only sends it in a flash special case.
We should probably do this in all cases unless someone thinks it would break existing clients?currently it only sends it in a flash special case.
We should probably do this in all cases unless someone thinks it would break existing clients?Icecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://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 Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1273<relay> ignores <authentication> elements2018-03-06T12:49:48Zmuelli<relay> ignores <authentication> elementsIf you just relay streams and want users to authenticate in order to get the stream, I'd expect to extend my <relay> definition by a `<authentication type="">` stanza. However, this does not work.
A rather counter-intuitive solution is...If you just relay streams and want users to authenticate in order to get the stream, I'd expect to extend my <relay> definition by a `<authentication type="">` stanza. However, this does not work.
A rather counter-intuitive solution is to set up a `<mount>` with the same name and define authentication there.
I'd expect an `<authentication>` inside a `<relay>` to work.
Example configuration which I expected to work:
```
<relay>
<server>some.server.net</server>
<port>8000</port>
<mount>/remotemount</mount>
<local-mount>/relay-auth</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
<authentication type="url">
<option name="mount_add" value="http://myauthserver.net/notify_mount.php"/>
<option name="mount_remove" value="http://myauthserver.net/notify_mount.php"/>
<option name="listener_add" value="http://myauthserver.net/notify_listener.php"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="listener_remove" value="http://myauthserver.net/notify_listener.php"/>
</authentication>
</relay>
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1929HTTP Content-Type doesn't autodetect and it ignores <type> and <subtype>2018-10-24T14:29:17ZEvan CarrollHTTP Content-Type doesn't autodetect and it ignores <type> and <subtype>I have a `Ogg/Opus` stream, if I don't statically put in the `<type>` and `<subtype>` into my icecast conf file `/admin/stats.xsl shows`,
```
server_type application/ogg
```
And, the HTTP header shows `application/ogg` for Content-Typ...I have a `Ogg/Opus` stream, if I don't statically put in the `<type>` and `<subtype>` into my icecast conf file `/admin/stats.xsl shows`,
```
server_type application/ogg
```
And, the HTTP header shows `application/ogg` for Content-Type. If I statically put in the `<type>` and `<subtype>` `/admin/stats.xsl` shows,
```
server_type audio/ogg
subtype opus
```
However, even statically entered the HTTP Content-Type is `application/ogg`.
Per the Opus wiki [https://wiki.xiph.org/OggOpus#Content_Type], the Content-Type should be `"audio/ogg; codecs=opus"`
> The recommended mime-type for Ogg Opus files is audio/ogg, defined in RFC 5334. If more specificity is desired, one can distinguish Opus files as 'audio/ogg; codecs=opus'. The recommended filename extension for Ogg Opus files is .opus.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1271missing comprehensive list of configuration directives2018-03-06T12:49:48Zmuellimissing comprehensive list of configuration directivesI just wanted to lookup the semantic of a configuration directive and couldn't find it easily. A comprehensive list like on http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives would be nice.I just wanted to lookup the semantic of a configuration directive and couldn't find it easily. A comprehensive list like on http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives would be nice.Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/16462.3.2-kh20 content-length is before http status for flash/MSIE2018-03-06T12:49:48Zmoo2.3.2-kh20 content-length is before http status for flash/MSIE```
$ LANG=C svn info .
URL: http://svn.xiph.org/icecast/branches/kh/icecast
Repository Root: http://svn.xiph.org
Repository UUID: 0101bb08-14d6-0310-b084-bc0e0c8e3800
Revision: 16886
Last Changed Rev: 16858
Last Changed Date: 2010-01-31...```
$ LANG=C svn info .
URL: http://svn.xiph.org/icecast/branches/kh/icecast
Repository Root: http://svn.xiph.org
Repository UUID: 0101bb08-14d6-0310-b084-bc0e0c8e3800
Revision: 16886
Last Changed Rev: 16858
Last Changed Date: 2010-01-31 14:22:46 +0800 (Sun, 31 Jan 2010)
```
for flash/MSIE client, icecast returns
```
Content-Length: 221183499
Expires: Mon, 26 Jul 1997 05:00:00 GMT
HTTP/1.0 200 OK
```
expected result:
```
HTTP/1.0 200 OK
Content-Length: 221183499
Expires: Mon, 26 Jul 1997 05:00:00 GMT
```
suggested fix: call create_client_data after HTTP/1.0 200 OK is setKarl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1867Icecast shared sources in 'httpp', 'net', 'thread' and 'timing' directories n...2018-03-06T12:49:48ZThomas B. RückerIcecast shared sources in 'httpp', 'net', 'thread' and 'timing' directories need license header update (to LGPLv2)As just noticed on #icecast, among others the timing.c and httpp.c files seem to imply GPLv2 while COPYING in that directory says LGPLv2.
Those are also used by e.g. libshout which is LGPLv2...
Suggestion: track down authors, double che...As just noticed on #icecast, among others the timing.c and httpp.c files seem to imply GPLv2 while COPYING in that directory says LGPLv2.
Those are also used by e.g. libshout which is LGPLv2...
Suggestion: track down authors, double check that changing to LGPL is OK.
This would make them compatible with both GPLv2 and LGPLv2 if I understand correctly.
affected files relative to [icecast/trunk/](../tree/master/icecast/trunk/) and who touched them (since tagging GPL):
* [icecast/trunk/timing/timing.c](../tree/master/icecast/trunk/timing/timing.c) giles, karl
* [icecast/trunk/timing/timing.h](../tree/master/icecast/trunk/timing/timing.h) giles, karl, moritz
* [icecast/trunk/net/sock.h](../tree/master/icecast/trunk/net/sock.h) (oddly not sock.c) karl, oddsock, giles, brendan, msmith, jack. plus changes predating https://trac.xiph.org/browser/trunk/net/sock.h?rev=1997
* [icecast/trunk/httpp/httpp.c](../tree/master/icecast/trunk/httpp/httpp.c) msmith, giles, oddsock, karl, ph3-der-loewe
* [icecast/trunk/httpp/httpp.h](../tree/master/icecast/trunk/httpp/httpp.h) msmith, giles, karl, ph3-der-loeweThomas B. RückerThomas B. Rücker