Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2023-01-03T10:08:01Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2441Icecast 2.5 beta 3 stops after 3 seconds2023-01-03T10:08:01ZMichelIcecast 2.5 beta 3 stops after 3 secondsThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
MichelThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2406Icecast SSL stream information2022-04-20T09:19:24ZAlain SeysIcecast SSL stream informationNot realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is serv...Not realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is served.
is there a way to also give the track information trough ssl ?
on our website we use a php script to get the trackinformation from a https stream but in vlc we cant get it to work.
please advise mehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2364https stream play 1 second and stop2019-05-13T11:56:47ZMichelhttps stream play 1 second and stopWe have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bul...We have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bult a new RPM for Icecast 2.4.4 on the last version of CentOS Linux release 7.6.1810 (Core) include the openssl update. (OpenSSL 1.0.2k-fips 26 Jan 2017)
I run it on the debug mode (4). Tonight i have the same problem on https on mount /live a mp3 192k stream. It play 2 seconds and stop. (when i try to use include .m3u so https.../live.m3u he go to http in the software player)
Here is the debug error log. I hope you find them useful (see /live) :
```
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52301)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (16)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52302)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_read (18373627904)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_sent (82768157916)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50480)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (1)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (12)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listener_connections (11687)
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source max on /live is 400 (cur 0)
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source Added client to /live
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (11)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (0)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50481)
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
```
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2356Icecast does not handle HTTP Upgrade as to RFC2018-12-14T03:48:15ZPhilipp SchafftIcecast does not handle HTTP Upgrade as to RFCCurrently Icecast 2.5.x does not handle HTTP upgrades correctly. It does not send the final reply to the request doing the upgrade.Currently Icecast 2.5.x does not handle HTTP upgrades correctly. It does not send the final reply to the request doing the upgrade.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2355DoS vector using incorrect TLS teardown2018-12-07T13:48:18ZPhilipp SchafftDoS vector using incorrect TLS teardownWhen in a TLS SOURCE connection the socket is closed without TLS teardown Icecast will read from the socket in a tight endless loop. This locks up the corresponding thread.
Affected at least: Icecast 2.4.4, Icecast 2.5 beta 2.
May be re...When in a TLS SOURCE connection the socket is closed without TLS teardown Icecast will read from the socket in a tight endless loop. This locks up the corresponding thread.
Affected at least: Icecast 2.4.4, Icecast 2.5 beta 2.
May be related to OpenSSL version. Tested with version 1.0.1t.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2354Improve way of what URI is sent to YP2022-03-21T23:14:53ZPhilipp SchafftImprove way of what URI is sent to YPAt this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames)...At this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames).
An attribute to the `<directory>` tag should be added that takes the ID of a `<listen-socket>` on which behalf the YP submission should be made. That `<listen-socket>` may be `type="virtual"`.
See: #2171Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2323m3u/xspf/vclt files do not support SSL2019-07-04T20:20:25ZGitlab Botm3u/xspf/vclt files do not support SSLRegardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if ...Regardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if (host == NULL)
{
config = config_get_config();
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s:%d%s\r\n",
config->hostname, config->port,
sourceuri
);
config_release_config();
}
else
{
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s%s\r\n",
host,
sourceuri
);
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2318icecast fails to build against openssl-1.1 that lacks deprecated features2019-04-24T17:23:49ZGitlab Boticecast fails to build against openssl-1.1 that lacks deprecated featuresicecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
`...icecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
```
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I./common/ -Wall -ffast-math -fsigned-char -I/usr/include/libxml2 -I/usr/include -pthread -march=native -O2 -pipe -c -o connection.o connection.c
connection.c: In function ‘get_ssl_certificate’:
connection.c:195:5: warning: implicit declaration of function ‘SSL_load_error_strings’ [-Wimplicit-function-declaration]
SSL_load_error_strings(); /* readable error messages */
^
connection.c:196:5: warning: implicit declaration of function ‘SSL_library_init’ [-Wimplicit-function-declaration]
SSL_library_init(); /* initialize library */
^
connection.c:198:12: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
method = SSLv23_server_method();
^
```
And later in the linking part:
```
libtool: link: i686-pc-linux-gnu-gcc -pthread -march=native -O2 -pipe -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -o icecast cfgfile.o main.o logging.o sighandler.o connection.o global.o util.o slave.o source.o stats.o refbuf.o client.o xslt.o fserve.o admin.o md5.o format.o format_ogg.o format_mp3.o format_midi.o format_flac.o format_ebml.o format_kate.o format_skeleton.o format_opus.o event.o event_log.o event_exec.o acl.o auth.o auth_htpasswd.o auth_anonymous.o auth_static.o format_vorbis.o format_theora.o format_speex.o auth_url.o event_url.o yp.o -L/usr/lib -Wl,--as-needed common/net/.libs/libicenet.a common/thread/.libs/libicethread.a common/httpp/.libs/libicehttpp.a common/log/.libs/libicelog.a common/avl/.libs/libiceavl.a common/timing/.libs/libicetiming.a -lcurl -lnghttp2 -lidn2 -lssl -lcrypto -lspeex -ltheora -lvorbis -logg -lxslt -lxml2 -lz -ldl -lm -pthread
connection.o: In function `connection_accept_loop':
connection.c:(.text+0x736): undefined reference to `SSL_load_error_strings'
connection.c:(.text+0x73b): undefined reference to `SSL_library_init'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:512: icecast] Error 1
```
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2310re-license to "GPL-2. with OpenSSL exception"2018-06-16T20:52:48ZJamiere-license to "GPL-2. with OpenSSL exception"The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.deb...The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815#15) that could be resolved if icecast2 could be re-licensed to include an exception for openssl (among other options).
Is that option viable? Other options?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2283Streaming over SSL disconnects2020-02-26T00:04:46ZBrendonStreaming over SSL disconnectsI reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications ar...I reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications are all served over SSL.
In order to avoid mixed content warnings, I built Icecast 2.4.3 with SSL support so I could get status info and serve the stream over SSL as well.
(None of the Debian or Ubuntu packages have been built with SSL yet for some reason.)
I'm using Debian 8 x64. libssl is 1.0.1t (which is the latest 1.0.1 LTS version). liquidsoap 1.1.1 is the source and connects to Icecast via port 80 on localhost (both liquidsoap and icecast are on the same VM).
I have six mounts configured all the same. liquidsoap is re-encoding the mp3s at a constant bitrate of 128k. I've uploaded a stripped down Icecast config.
Here is what happens: normally, streaming over SSL works perfectly fine. But sometimes, either right at stream start or at some seemingly random amount of time later, one of the mounts becomes "corrupted." The web player (using a simple <audio> tag) quickly buffers and disconnects. VLC reconnects and gets disconnected over and over.
I've tested this on my local network over wifi using the web player, VLC, and iTunes, and with ServeStream on Android over cellular. All same result.
If I connect to the stream via port 80, I do not get disconnected. I get disconnected from the stream ONLY when streaming over SSL and ONLY when the mount becomes corrupted.
Observations:
- This happens on every mount seemingly at random, but it seems that only ONE mount becomes corrupted at a time.
- Doesn't seem to be triggered by any one song, a track change, or anything else station related that I can find.
- Happens if I use ogg or mp3.
- Shutting down the liquidsoap instance for the corrupted mount, waiting a minute or so (a quick restart doesn't seem to fix it) and then restarting liquidsoap seems to resolve the issue (at least temporarily).
- Nothing in the logs that I can see, even with debug logging on:
[2016-08-21 20:30:08] DBUG stats/modify_node_event update "/electronic" listeners (1)
[2016-08-21 20:30:08] DBUG format/format_check_http_buffer processing pending client headers
[2016-08-21 20:30:08] DBUG client/client_send_bytes Client connection died
[2016-08-21 20:30:08] DBUG source/source_main Client removed
[2016-08-21 20:30:08] INFO source/source_main listener count on /electronic.mp3 now 0
These cycle over and over again as the client disconnects and reconnects. I can find nothing else in any of the logs on the system.
- This happens on both staging and production which is on two separate servers.
I was asked to run Icecast using valgrind. We saw lots of SSL errors, so one possible issue could be a buggy system libssl (which I do not think is the case at this point). I even got the latest OpenSSL 1.0.2h built and then built Icecast against that to rule out 1.0.1t causing a bunch of errors.
I will upload the Valgrind output for both 1.0.1t and 1.0.2h.
I simply started Icecast and then shut it down via ctrl-c. This was NOT running while experiencing a corrupted mount.
That's about as much information as I think I have at this point. I have decided to abandon using SSL for the streams as it simply does not seem to be production ready at this point. This will cause mixed content errors in our applications, but streaming over http seems much more stable.
I'd be happy to help provide more information if requested.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2245Move TLS options out of <paths>2018-06-15T20:50:30ZPhilipp SchafftMove TLS options out of <paths>The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/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/2070openSSL configuration overhaul in Icecast2023-01-03T10:26:01ZThomas B. RückeropenSSL configuration overhaul in IcecastI'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's sy...I'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's systems, but still we should do our part to prevent bad things from happening.
There will be dependent tickets filed for certain aspects.Icecast 2.5.0Philipp SchafftPhilipp Schafft