On the same host, same user, same shell environment can you curl -OL https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz? Typically if that works, Suricata-Update should work as well.
Usually when I see the download failing at 99% there is some proxy, or WAF that thinks the rules are malware and dropping the last packets which can result in what you are seeing.
Thanks @ish . Command curl works without problems … Theres is no WAF or firewall or another type of device disrupting https comms between suricata sensor and Internet … In fact, I can update RHEL without problems but suricata-update fails …
Is it possible to debug? Or maybe do I need to install addiitonal python package under RHEL? Actually the following packages are installed:
Unfortunately there isn’t much options for debugging (short of downloading the code and adding some print’s). This is a simple loop that reads 8k from the network at a time, and there error suggest its just not getting the end of the file. One thought is that this might happen if its failing to write the temporary file for any reason, but unlikely given the error message.
You could try the curl -o /tmp/rules.tar.gz -L https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz to rule out issues.
I have just tested on RHEL 10 to make sure this isn’t some repeatable issue on RHEL10.
I have done some tests. I have installed a new host with Debian 13 this time, directly connected to Internet (no fws, no proxys, etc) and problem is the same: suricata-update returns “The read operation timed out” … with et and stamus open rules.
Using curl to donwload both sets of rules work ok … maybe, is it a bug with suricata-update?
Something to check is the behavior of the progress bar? Does it very slowly get to 99%? Or does it get to 99% quickly, then stall for about 30 seconds before the timeout?
If it gets to 99% very fast, then stalls, it suggests it’s something outside of Suricata-Update’s control, its waiting for the file to complete, but it never does.
You could try tweaking the timeout, find the file suricata/update/net.py, go to line 146:
remote = opener.open(url, timeout=30)
and change that to something higher (120). However, its already well suited for very slow connections, as its a timeout per read call, not for the whole download.
The behaviour is exactly this: suricata-update gets to 99% quickly and then stall for 30 seconds and displays the timeout.
But I have done another test. I have another host with Suricata 7.0.11 under a FreeBSD 14 hosts deployed in the same network as Debian 13 and RHEL10 and the result is that suricata-update works without any problems on FreeBSD.
At this point, all that remains is for me to point to Python.
RHEL10: use python3.12 and suricata-update does not work.
Debian13: use python3.13 and suricata-update does not work.
FreeBSD14: use python3.11 and suricata-update works.
I’ve added AlmaLinux 10 build to our CI which does a Suricata-Update with the et/open rules, and it does appear to pass:
This matches my local testing that all passes:
AlmaLinux 10, Python 3.12.9: OK
RHEL 10, Python 3.12.9: OK
Fedora 42, Python 3.13.5: OK
While we don’t host the et/open ruleset, we do host the index and I see many users fetching the index with Python 3.13, however not many from Debian 13 or RHEL10 yet, but typically we hear about critical problems pretty quick.
Are you able to test with something more common? Ubuntu 24.04 or AlmaLinux 9 are probably the most frequently used.