similar to: Setting explicitly the source of slaves connections

Hello, I found a bug in Icecast-2.3.2. SVN trunk is affected either. The problem lies in src/net/sock.c: sock_connected() function. This function is used to check status of socket after nonblocking connect(2) and it has two implementations: select(2) and poll(2). The select branch does the right job---it gets socket status by getsockopt(2) after selecting for write. But the poll branch does not.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Build environment: Solaris 7, JKP 106541-18 gcc 2.95.3 Current (as of a couple hours ago) CVS ice2 After a long bit of downtime, I'm throwing myself back into icecast with a fervor. I'm attempting to build ice2 on my Solaris box, and everything goes fine (well, went fine once I got libxml...) until the

Reimplementation of my earlier patch - more proper aliasing - at the suggestion of Mike -Paul -------------- next part -------------- diff -ur icecast/CVS/Entries IceCast/CVS/Entries --- icecast/CVS/Entries 2003-04-18 11:00:19.000000000 -0400 +++ IceCast/CVS/Entries 2003-04-17 22:14:16.000000000 -0400 @@ -1,4 +1,3 @@ -/.cvsignore/1.3/Wed Jan 15 05:36:15 2003// /AUTHORS/1.2/Fri Aug 9 15:55:01

I wrote a patch which makes client connections retain info about which socket they connected to - this way, you can change the server's behavior based on which <listen-socket> is being connected to. In addition, I added a field to the <listen-socket> section of the config file called <default-mount> which specifies a default file in the case that one isn't specified (it

I've installed 2.8.1 on a Raspberry PI 5 using Pi OS bookworm 64 bit (Debian 12) with success. When I take that same configuration to a PI 3B running bookworm 32 bit, compile from source, use the same files from /etc/nut, I get a 'nut-monitor ups at localhost Connection refused. usbhid-ups and dummy-ups are running at the time. What should I be looking for? Dan -------------- next

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 re all, this patch has not been integrated in Debian yet, hence the Icecast2 package still segfaults after filling up all the memory with its leak. as this is a critical bug, while it seems that the current Debian mantainer for the icecast2 package has abandoned its duty, i'm kindly asking the attention of debian developers included

The init functions are not longer required in OpenSSL 1.1 so I dropped them. TLSv1_client_method() should not be used because it enables only the TLSv1.0 protocol. Better is to use SSLv23_client_method() which enable all the protocols including TLSv1.2. With this functions SSLv2 and SSLv3 is theoretically possible but as of today those protocols are usually build-time disabled. To avoid all this

Hi, I have been running nut successfully for a long time with my Debian 11 server. I upgraded my server to Debian 12 today, which upgraded nut also from 2.7.4-13 to 2.8.0-7. I noticed that after upgrade there was a upssched process running and taking 100% cpu time. I checked if there were any changes to configuration file formats with nut upgrade and only differences I noticed were a terminology

Hi, I ran the strace command while upssched was 100% CPU hungry. This is what I got: 1686633611.702798 read(7, "", 1) = 0 <0.000004> 1686633611.702816 read(7, "", 1) = 0 <0.000004> 1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL) = 1 (in [7], left {tv_sec=0, tv_nsec=999998800}) <0.000006> 1686633611.702862 read(7,

Hi, I ran the strace command while upssched was 100% CPU hungry. This is what I got: 1686633611.702798 read(7, "", 1) = 0 <0.000004> 1686633611.702816 read(7, "", 1) = 0 <0.000004> 1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL) = 1 (in [7], left {tv_sec=0, tv_nsec=999998800}) <0.000006> 1686633611.702862 read(7,

Hi, re libshout: MacOSX doesn't have poll(), which prevents sock.c from compiling. I've patched sock.c to use select(), which is supported on MacOSX, and should be elsewhere too. I've marked my changes with "SKoT" comments in the file below. Main changes are in sock_write_bytes(). - SKoT ------8<----- /* sock.c * - General Socket Functions * * Copyright (c) 1999

On up-to-date f36, with latest kernel 6.1.7-100.fc36.x86_64. After receiving a few of these messages Broadcast message from nut at e7.eyal.emu.id.au (somewhere) UPS ups at ups is unavailable I noticed and ran sudo systemctl restart nut-driver at ups.service which triggered Broadcast message from nut at e7.eyal.emu.id.au (somewhere) Communications with UPS ups at ups established I now added

diff -u --recursive icecast/src/admin.c icecast-new/src/admin.c --- icecast/src/admin.c 2003-07-18 16:29:23.000000000 -0400 +++ icecast-new/src/admin.c 2003-08-06 19:18:32.000000000 -0400 @@ -213,7 +213,7 @@ html_write(client, "HTTP/1.0 200 OK\r\n" "Content-Type: text/html\r\n" "\r\n"); - DEBUG1("Sending XSLT

Le dim 29/02/2004 à 17:27, oddsock a écrit : > for most stations that have this kind of listener capacity, they are > getting bandwidth from AOL/Nullsoft. Nullsoft had (may still have) a > policy of offering free bandwith to stations they hand-picked. They > were tapping into the rather huge amount of bandwidth that AOL had, and > thus could offer the kind of listener capacity

While working on integrating nonblocking IO into libshout, I noticed that sock_connected cannot be called without blocking. If I read it right, a timeout of zero will cause the call to block until the socket is connected. So, my questions: 1. Am I reading this right? 2. How should I poll a pending connection? I'd prefer to have a zero timeout act as a poll, but I don't know if any other

I've not been able to connect to my ups using NUT 2.7.4 or NUT 2.8.0. 2.7.4 was installed as a package, 2.8.O was compiled from source. I've messed with permissons, everything is root:root and has the approprate read/execute permissons. I've tried two differnt UPS(es) APC & CyperPower. I'm running PI OS (Raspbian) on a Raspberry Pi3 model B. The port 3493 is open (UFW). I can

Le jeudi 13 mai 2010 05:46:12, jaromil a ?crit : > re all, Hi, > this patch has not been integrated in Debian yet, hence the Icecast2 > package still segfaults after filling up all the memory with its leak. > > as this is a critical bug, while it seems that the current Debian > mantainer for the icecast2 package has abandoned its duty, i'm kindly > asking

Hi, after the talks about this a while ago here on the mailing list; I've managed to put together a useful proof of concept of my ideas. I've wrapped Java and Flash "engines" in Javascript, allowing a Vorbis player to be embedded on a web page if _either_ Java or Flash is installed on the client, with the Javascript API remaining identical, independent of the actual engine

Le 18/04/2024 ? 21:55, TDAS a ?crit?: > Hiya > > Is this bug known about, in stats.json ? > > Currently showing for me: > > "listeners": 140462600, > > I'd love to think I had that many listeners, but I think the server > would have long given up... ;) > > Anything I can help with, logs etc? Hey, What version of icecast are you using? I

Geoff Shang wrote: > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I./.. -pthread -g -O2 -c sock.c > -Wp,-MD,.deps/libicenet_la-sock.TPlo -fPIC -DPIC -o > .libs/libicenet_la-sock.o > sock.c: In function `sock_get_server_socket': > sock.c:702: `IPV6_V6ONLY' undeclared (first use in this function) > sock.c:702: (Each undeclared identifier is reported only once > sock.c:702: