HTTPS URL fails after a second or two

[comiconomenclaturist]

I have downloaded Icecast 2.4.4 from http://downloads.xiph.org/releases/icecast/icecast-2.4.4.tar.gz and configured it with SSL:

./autogen.sh 
./configure --with-curl --with-openssl
make

I have obtained a certificate using certbot / letsencypt and everything seems to work. Then about once a week a problem appears with one of the streams over HTTPS where the stream plays for a moment and then stops. This can be solved by restarting the icecast service with sudo systemctl restart icecast.service

There are no errors reported in /var/log/icecast/error.log, although I have only just increased the log level to 4/DEBUG so hopefully something useful might appears here.

The server has plenty of RAM and CPU spare (debian 10 OS).

Here are some possibly relevant section of the config file:

<limits>
    <clients>1000</clients>
    <sources>16</sources>
    <client-timeout>30</client-timeout>
    <header-timeout>15</header-timeout>
    <source-timeout>10</source-timeout>
    <queue-size>2000000</queue-size>
    <burst-on-connect>1</burst-on-connect>
    <burst-size>500000</burst-size>
</limits>
<listen-socket>
    <port>80</port>
    </listen-socket>       
<listen-socket>
    <port>443</port>
    <ssl>1</ssl>
</listen-socket>
<http-headers>
    <header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<paths>
    <basedir>/usr/local/share/icecast</basedir>
    <logdir>/var/log/icecast2</logdir>
    <webroot>/usr/local/share/icecast/web</webroot>
    <adminroot>/usr/local/share/icecast/admin</adminroot>
    <alias source="/" destination="/status.xsl"/>
    <ssl-certificate>/etc/icecast2/bundle.pem</ssl-certificate>
</paths>
<logging>
    <accesslog>access.log</accesslog>
    <errorlog>error.log</errorlog>
    <playlistlog>playlist.log</playlistlog>
    <loglevel>4</loglevel>
    <logsize>1000000</logsize>
</logging>
<security>
    <chroot>0</chroot>
    <changeowner>
        <user>icecast2</user>
        <group>icecast</group>
    </changeowner>
</security>

[Keyne]

Same here with 2.4.3. Did you happen to solve it?

[comiconomenclaturist]

No we are still having this issue. There are some messages in /var/log/kern.log like which may be related:

[Sat Apr 24 03:34:16 2021] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
[Sat Apr 24 04:37:40 2021] TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.  Check SNMP counters.
[Sat Apr 24 08:03:05 2021] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
[Sun Apr 25 04:25:03 2021] TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.  Check SNMP counters.
[Mon Apr 26 04:50:25 2021] TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.  Check SNMP counters.
[Thu Apr 29 20:39:08 2021] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
[Sat May  8 04:19:37 2021] TCP: request_sock_TCP: Possible SYN flooding on port 1044. Sending cookies.  Check SNMP counters.
[Mon May 10 14:04:15 2021] TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.  Check SNMP counters.
[Wed May 12 02:44:33 2021] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
[Thu Jun  3 12:40:34 2021] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.

Googling this issue shows lots of results for kernel tuning so I've set these values in /etc/sysctl.conf:

net.core.somaxconn=8192  
net.ipv4.tcp_max_syn_backlog=16384

but the issue still persists. Would love a fix for this!

[alainseys]

the only way i got it working by enabeling apache with proxy

[phschafft]

Does this still apply? Is there a ticket on the official ticket system at https://gitlab.xiph.org/xiph/icecast-server/-/issues ?

To me this sounds more like known problems in some specific versions of OpenSSL. Those should be fixed by updating.

If there is no report of this still applying I will close the ticket.

[phschafft]

As there is no reply, it seems it really was the OpenSSL bug. Therefore closing the ticket.