Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-10-11T09:01:32Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2363Use of `<shoutcast-compat>` results in unexpected behaviour2020-10-11T09:01:32ZPhilipp SchafftUse of `<shoutcast-compat>` results in unexpected behaviourWhen setting `<shoutcast-mount>` within `<listen-socket>` two sockets will be created:
* A normal one with the shoutcast mount set
* A second one at (`port` + 1) with shoutcast mount set as ICY source port (`<shoutcast-compat>` set).
Ho...When setting `<shoutcast-mount>` within `<listen-socket>` two sockets will be created:
* A normal one with the shoutcast mount set
* A second one at (`port` + 1) with shoutcast mount set as ICY source port (`<shoutcast-compat>` set).
However you can set `<shoutcast-compat>` manually. In this case also two ports are opened at `port` and `port` + 1 with both being identical in configuration.
The code uses the following condition to check if the extra socket must be created:
```c
if (listener->shoutcast_mount) {
```
However I think it should be:
```c
if (listener->shoutcast_mount && !listener->shoutcast_compat) {
```
This will prevent the listen socket on `port` + 1 to be created.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2112Locks on avl client_trees needed?2020-10-11T11:18:30ZMarvin ScholzLocks on avl client_trees needed?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2380Invalid JSON structure when title is empty2020-10-11T11:37:16ZEdwin HermannInvalid JSON structure when title is emptyBelow is a snippet of the JSON structure returned from /status-json.xsl when the song title is empty:
```
"stream_start":"Mon, 28 Oct 2019 10:49:00 +1300",
"stream_start_iso8601":"2019-10-28T10:49:00+1300",
...Below is a snippet of the JSON structure returned from /status-json.xsl when the song title is empty:
```
"stream_start":"Mon, 28 Oct 2019 10:49:00 +1300",
"stream_start_iso8601":"2019-10-28T10:49:00+1300",
"title": - ,
"dummy":null
}
```
The problem item here is "title". The resulting JSON string does not parse correctly because of the hyphen. To fix the bug, the hyphen should be enclosed in double-quotes.
The server whence this came is not mine so I am not able to determine why it is that the Icecast server is returning an unquoted hyphen. The server concerned has been that way for several days; the URL is http://219.89.83.33:8000/status-json.xslhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/738Errorcode when client wants to connect to "full" mountpoint should be changed2020-10-15T13:51:17ZrobeErrorcode when client wants to connect to "full" mountpoint should be changedHi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same error...Hi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same errorcode that gets returned when the requested mountpoint doesn't exist.
A possible solution to this would be returning 403 with a customized reason phrase like "Mountpoint full" (or similar) in the header (since this is the only thing (if any) that gets forwarded to the user with most clients). The HTTP 1.1 RFC (#2616) allows this:
6.1.1:
[..]
The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
[..]Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2347ACL should support names2020-10-15T14:20:49ZPhilipp SchafftACL should support namesACLs should support name=""s just like Roles do for easier administration.
This will become more important when Icecast will support multiple ACLs per Role.ACLs should support name=""s just like Roles do for easier administration.
This will become more important when Icecast will support multiple ACLs per Role.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2398Handling of GET request on admin/ should be updated2020-10-15T15:24:33ZPhilipp SchafftHandling of GET request on admin/ should be updatedCurrently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
R...Currently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
Reject the request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2373Incorrect status code2020-10-15T16:20:55ZPhilipp SchafftIncorrect status codeIn case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.In case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2359`<listen-socket>` does not support `<http-headers>`2020-10-15T20:42:13ZPhilipp Schafft`<listen-socket>` does not support `<http-headers>`Currently `<listen-socket>` does not support `<http-headers>` as a child. While I see little reason to use this there is no reason why this should not work.Currently `<listen-socket>` does not support `<http-headers>` as a child. While I see little reason to use this there is no reason why this should not work.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344Crash Icecast 2.4.3 on CentOS 7.52020-10-18T15:38:53ZMichelCrash Icecast 2.4.3 on CentOS 7.5Hi,
We running Icecast v2.4.3 on the Last version of CentOS Linux release 7.5.1804 (Core).
And its crash every 3 a 4 days. We see in the systemlog:
kernel: traps: icecast[5425] general protection ip:7ff3b209cc19 sp:7ffc63b5a910 error:0...Hi,
We running Icecast v2.4.3 on the Last version of CentOS Linux release 7.5.1804 (Core).
And its crash every 3 a 4 days. We see in the systemlog:
kernel: traps: icecast[5425] general protection ip:7ff3b209cc19 sp:7ffc63b5a910 error:0 in libssl.so.1.0.2k[7ff3b2070000+67000]
We run OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS 7.5 using the last updates.
We use dual stack ipv4/ipv6 and run on ssl and streaming on flac, opus and mp3.
Best regards,
Michelhttps://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/2399Crash Icecast 2.4.4 on CentOS 7.52020-10-19T17:28:24ZMediaKCrash Icecast 2.4.4 on CentOS 7.5Linked from previous report `https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344`
My radio stream service exits on minimal load.
I'm using Icecast 2.4.4
OpenSSL 1.0.2k-fips 26 Jan 2017
On CentOs 7.8
WHM/CPANEL: v90.0.15
`Oct 18 ...Linked from previous report `https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344`
My radio stream service exits on minimal load.
I'm using Icecast 2.4.4
OpenSSL 1.0.2k-fips 26 Jan 2017
On CentOs 7.8
WHM/CPANEL: v90.0.15
`Oct 18 02:18:33 server1 kernel: traps: icecast[16512] general protection ip:7f2327a88c09 sp:7ffdab32ab80 error:0 in libssl.so.1.0.2k[7f2327a5c000+67000]
`
With added errors
`Oct 18 02:18:33 server1 systemd: icecast.service: main process exited, code=killed, status=11/SEGV
Oct 18 02:18:33 server1 systemd: Unit icecast.service entered failed state.
Oct 18 02:18:33 server1 systemd: icecast.service failed.`
How can this be resolved?https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2306[PATCH] Fix build failure due to incorrect include ordering2020-10-21T08:50:27ZJoshua Root[PATCH] Fix build failure due to incorrect include orderingCommit 627da3d8 made an incorrect change: INCLUDES should have been changed to AM_CPPFLAGS rather than its contents being moved to AM_CFLAGS. Putting preprocessor flags in AM_CFLAGS results in them being passed in the wrong order relativ...Commit 627da3d8 made an incorrect change: INCLUDES should have been changed to AM_CPPFLAGS rather than its contents being moved to AM_CFLAGS. Putting preprocessor flags in AM_CFLAGS results in them being passed in the wrong order relative to CPPFLAGS, which results in build failure when a previous version of libshout is installed and its headers are in the same place as those of its dependencies.
Downstream bug: https://trac.macports.org/ticket/58466
[Makefile.am.patch](/uploads/bf297f2da070f02f791e49f0800e6205/Makefile.am.patch)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/1946oggfwd/ezstream: mime-type is always application/ogg2020-10-21T08:50:27Ztuxoggfwd/ezstream: mime-type is always application/oggIn most cases for multimedia streaming and conferencing, the user will probably want audio/ogg instead of application/ogg mime types (see RFC5334). However, oggfwd 0.2-6 and ezstream 0.5.6~dfsg-1 on Debian always sends things with applic...In most cases for multimedia streaming and conferencing, the user will probably want audio/ogg instead of application/ogg mime types (see RFC5334). However, oggfwd 0.2-6 and ezstream 0.5.6~dfsg-1 on Debian always sends things with application/ogg.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2309libshout's connection state maschine does not honor connection specific block...2020-10-21T08:50:27ZPhilipp Schafftlibshout's connection state maschine does not honor connection specific blocking settingCurrently libshout's connection state machine overrides it's own blocking setting in `shout_connection_connect()`:
```c
shout_connection_set_nonblocking(con, shout_get_nonblocking(shout));
```
Using the setting from the parent objec...Currently libshout's connection state machine overrides it's own blocking setting in `shout_connection_connect()`:
```c
shout_connection_set_nonblocking(con, shout_get_nonblocking(shout));
```
Using the setting from the parent object should only be the default if no specific value was set.
See also: #2308Philipp SchafftPhilipp Schafft2019-06-28https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2310libshout connects to the same port for ICY data and metadata connections2020-10-21T08:50:27ZPhilipp Schafftlibshout connects to the same port for ICY data and metadata connectionslibshout does the port increment for ICY data connections unconditionally and therefore also for metadata connections.
This is part of the multi-topic ticket #2308.libshout does the port increment for ICY data connections unconditionally and therefore also for metadata connections.
This is part of the multi-topic ticket #2308.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2312Use-after-free bug after reopening connection2020-10-21T08:50:27ZAlexander MilosUse-after-free bug after reopening connectionHello,
There have recently been some issues when using libshout in combination with MPD (the Music Player Daemon) which, after some investigation in collaboration with the author of MPD, have apparently been tracked to a bug in libshout...Hello,
There have recently been some issues when using libshout in combination with MPD (the Music Player Daemon) which, after some investigation in collaboration with the author of MPD, have apparently been tracked to a bug in libshout. MPD's author reported the issue but did so on your GitHub mirror, so in case you may have missed it I saw fit to report it here as well.
The gist of that bug report is as follows:
"Since libshout 2.4.2, the library crashes due to a use-after-free and double-free bug if an application reopens the connection using shout_open() after a previous connection with the same shout_t had been closed by shout_close().
See [MusicPlayerDaemon/MPD#622](https://github.com/MusicPlayerDaemon/MPD/issues/622) for details and valgrind logs.
The crash bug was introduced by commit 3110fe32"
The original bug report is here: [xiph/Icecast-libshout#17](https://github.com/xiph/Icecast-libshout/issues/17)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318Misc memory fixes2020-10-21T08:50:28ZClément BœschMisc memory fixesHi,
2 memory fix patches (patch 1 is the most important one):
- [0001-Fix-cleanup-format-residual-after-close.patch](/uploads/445ae23a375206242940a51ee2f69e4b/0001-Fix-cleanup-format-residual-after-close.patch)
- [0002-Fix-check-ogg_sy...Hi,
2 memory fix patches (patch 1 is the most important one):
- [0001-Fix-cleanup-format-residual-after-close.patch](/uploads/445ae23a375206242940a51ee2f69e4b/0001-Fix-cleanup-format-residual-after-close.patch)
- [0002-Fix-check-ogg_sync_buffer-pointer-before-writing-to-.patch](/uploads/8e33e8f69d5bef238e5b7bcb51df3c92/0002-Fix-check-ogg_sync_buffer-pointer-before-writing-to-.patch)https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2317nanosleep patch2020-10-21T08:51:08ZRosen Penevnanosleep patchI can't create a merge request so here's a patch:
```
From 4467530c2396c61e886bf2dc4563be0e9c54394b Mon Sep 17 00:00:00 2001
From: Rosen Penev <rosenp@gmail.com>
Date: Fri, 3 Apr 2020 19:32:39 -0700
Subject: [PATCH] nonblocking: remove ...I can't create a merge request so here's a patch:
```
From 4467530c2396c61e886bf2dc4563be0e9c54394b Mon Sep 17 00:00:00 2001
From: Rosen Penev <rosenp@gmail.com>
Date: Fri, 3 Apr 2020 19:32:39 -0700
Subject: [PATCH] nonblocking: remove usleep usage
usleep is deprecated under POSIX 2008 and is optionally unavailable
with uClibc-ng.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
examples/nonblocking.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/examples/nonblocking.c b/examples/nonblocking.c
index 8e38a94..2f15b80 100644
--- a/examples/nonblocking.c
+++ b/examples/nonblocking.c
@@ -70,8 +70,10 @@ int main()
if (ret == SHOUTERR_BUSY)
printf("Connection pending...\n");
+ const struct timespec req = {0, 10 * 1000 * 1000};
+ struct timespec rem;
while (ret == SHOUTERR_BUSY) {
- usleep(10000);
+ nanosleep(&req, &rem);
ret = shout_get_connected(shout);
}
--
2.26.2
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2319Building errors2020-10-21T08:53:09ZAtomtmBuilding errorsTrying to build the package and I get
```
checking for autoconf...
checking for automake 1.6 or later... automake
checking for aclocal 1.6 or later... aclocal
checking for libtool... libtoolize
Generating configuration files for libsho...Trying to build the package and I get
```
checking for autoconf...
checking for automake 1.6 or later... automake
checking for aclocal 1.6 or later... aclocal
checking for libtool... libtoolize
Generating configuration files for libshout, please wait....
aclocal -I m4
autoheader
libtoolize --automake
automake --add-missing
configure.ac:235: error: required file 'src/common/net/Makefile.in' not found
configure.ac:235: error: required file 'src/common/timing/Makefile.in' not found
configure.ac:235: error: required file 'src/common/thread/Makefile.in' not found
configure.ac:235: error: required file 'src/common/avl/Makefile.in' not found
configure.ac:235: error: required file 'src/common/httpp/Makefile.in' not found
src/Makefile.am:22: error: required directory src/common/avl does not exist
src/Makefile.am:22: error: required directory src/common/net does not exist
src/Makefile.am:22: error: required directory src/common/timing does not exist
src/Makefile.am:22: error: required directory src/common/httpp does not exist
src/Makefile.am:6: error: required directory src/common/thread does not exist
```
when using `./autogen.sh`. Any ideas please ?https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2315Network socket not set to nonblocking mode despite using nonblocking API2020-10-23T07:06:28ZTomasz LemiechNetwork socket not set to nonblocking mode despite using nonblocking APIhttps://gitlab.xiph.org/xiph/icecast-libshout/commit/0ac7ed9e84c3871d4427acc1ce59dca5e4af21ef introduced a bug which causes network sockets not to be set into nonblocking mode when requested with `shout_set_nonblocking(s, 1)`. This can b...https://gitlab.xiph.org/xiph/icecast-libshout/commit/0ac7ed9e84c3871d4427acc1ce59dca5e4af21ef introduced a bug which causes network sockets not to be set into nonblocking mode when requested with `shout_set_nonblocking(s, 1)`. This can be demonstrated simply by tracing an example `nonblocking` app.
Bad (current master HEAD):
```
$ strace -f -e fcntl,fcntl64,socket,connect ./nonblocking
(...)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
```
Good (v2.4.3):
```
(...)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now i n progress)
```
In the first case `fcntl` is never called and the socket stays in the default (blocking) mode.
This is due to the following condition in `shout_connection_connect`:
```C
if (con->nonblocking == SHOUT_BLOCKING_DEFAULT)
shout_connection_set_nonblocking(con, shout_get_nonblocking(shout));
```
But as `con->nonblocking` is never initialized to this value, it's effectively `if(0)`.
Adding a simple:
```C
con->nonblocking = SHOUT_BLOCKING_DEFAULT;
```
to `shout_connection_new` fixes the problem. But this turns the above condition into `if(1)`, so is it really needed? It was not there before. What's the idea behind this?