Same problem while using gvm-setup, notus-files start syncing but get interrupted, all other syncs fail. Tried from different IPs, no parallel download.
Running as root. Switching to user ‘_gvm’ and group ‘_gvm’.
Trying to acquire lock on /var/lib/openvas/feed-update.lock
Acquired lock on /var/lib/openvas/feed-update.lock
⠙ Downloading Notus files from
rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/
notus/ to /var/lib/notus
rsync: connection unexpectedly closed (127933912 bytes received so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(231)
rsync: connection unexpectedly closed (27143 bytes received so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(231)
⠋ Downloading NASL files from
rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/
nasl/ to /var/lib/openvas/plugins
rsync: [Receiver] safe_read failed to read 1 bytes: Connection reset by peer
(104)
rsync error: error in rsync protocol data stream (code 12) at io.c(282)
[Receiver=3.2.7]
Releasing lock on /var/lib/openvas/feed-update.lock
Trying to acquire lock on /var/lib/gvm/feed-update.lock
Acquired lock on /var/lib/gvm/feed-update.lock
⠋ Downloading SCAP data from
rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/scap-dat
a/ to /var/lib/gvm/scap-data
rsync: [Receiver] safe_read failed to read 1 bytes: Connection reset by peer
(104)
rsync error: error in rsync protocol data stream (code 12) at io.c(282)
[Receiver=3.2.7]
⠋ Downloading CERT-Bund data from
rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/cert-dat
a/ to /var/lib/gvm/cert-data
rsync: [Receiver] safe_read failed to read 1 bytes: Connection reset by peer
(104)
rsync error: error in rsync protocol data stream (code 12) at io.c(282)
[Receiver=3.2.7]
⠋ Downloading gvmd data from
rsync://feed.community.greenbone.net/community/data-feed/22.04/ to
/var/lib/gvm/data-objects/gvmd/22.04
rsync: [Receiver] safe_read failed to read 1 bytes: Connection reset by peer
(104)
rsync error: error in rsync protocol data stream (code 12) at io.c(282)
[Receiver=3.2.7]
@joe.ms Hello and welcome to this community forums.
This looks different what the OP has initially reported, for the OP the whole connection failed Connection refused (111) while in your case you actually are able to connect but get a Connection reset by peer during the sync.
I would suggest to create a new topic about this different problem or maybe the moderation team (@moderators) can move this posting into such a new one?
As a follow-up, it seems there is a hosting and distribution infrastructure problem and the team responsible for this topic seems to be currently trying to identify the cause of the problem.
worked for NVT, SCAP, CERT and GVMD_Data, now it only works for NVT showing status Current, for SCAP, CERT and GVMD_Data the status stays ‘2 days old’.
Running as root. Switching to user ‘_gvm’ and group ‘_gvm’.
Trying to acquire lock on /var/lib/openvas/feed-update.lock
Acquired lock on /var/lib/openvas/feed-update.lock
⠼ Downloading Notus files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/notus/ to /var/lib/notus
rsync: read error: Connection reset by peer (104)
rsync error: error in socket IO (code 10) at io.c(806)
rsync: connection unexpectedly closed (19715 bytes received so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(231)
⠋ Downloading NASL files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/nasl/ to /var/lib/openvas/plugins
rsync: [Receiver] safe_read failed to read 1 bytes: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(282) [Receiver=3.2.7]
Releasing lock on /var/lib/openvas/feed-update.lock
I have an issue with the feeds. someone please help. it is urgent.
@KALI101 Please try to check all existing posts in a topic before posting:
To clarify for further readers arriving here: There is no need to post any additional “I have the same problem” postings in this thread, the problem is known and the responsible team is trying to identify the root cause and to solve it afterwards.
Glad to hear… I have a cron job set up to run once every 2 days for a sync and it logs the progress to a file. Since 21 march the problems began (for your information) :
I don’t want to be the person who posts “me too!” however I think its worth posting that Notus and NASL always complete without a problem for me, but SCAP, CERT-Bund and gvmd data just seem to fail.
$ sudo g greenbone-feed-sync --type ALL
[sudo] password for xxxxxxxx:
Running as root. Switching to user '_gvm' and group '_gvm'.
Trying to acquire lock on /var/lib/openvas/feed-update.lock
Acquired lock on /var/lib/openvas/feed-update.lock
⠸ Downloading Notus files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/notus/ to /var/lib/notus
⠋ Downloading NASL files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/nasl/ to /var/lib/openvas/plugins
Releasing lock on /var/lib/openvas/feed-update.lock
Trying to acquire lock on /var/lib/gvm/feed-update.lock
Acquired lock on /var/lib/gvm/feed-update.lock
⠸ Downloading SCAP data from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/scap-data/ to /var/lib/gvm/scap-data
rsync: read error: Connection reset by peer (104)
rsync error: error in socket IO (code 10) at io.c(806)
rsync: connection unexpectedly closed (845 bytes received so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(231)
⠋ Downloading CERT-Bund data from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/cert-data/ to /var/lib/gvm/cert-data
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]
⠋ Downloading gvmd data from rsync://feed.community.greenbone.net/community/data-feed/22.04/ to /var/lib/gvm/data-objects/gvmd/22.04
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection refused (111)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Network is unreachable (101)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]
Releasing lock on /var/lib/gvm/feed-update.lock
In this case I have no firewall. This is a machine that sits outside of the firewall so as to test the FW rules and to scan from the point of view of an external hacker.
Wouldn’t the Notus and NASL downloads fail too though ? It’s the same “feed.community.greenbone.net” address and I’m assuming port 873 for rsync as well ?
I can guarantee you that this machine has no outbound restrictions except some iptables rules which allow everything to go out. Again this was working flawlessly before the 21 March with no changes to this machine or its network.
If the feed network is not reachable you have only legacy internet connection. So your machine is NOT connected to the network. You can check it by net catting to the rsync port and should receive a banner.
└─$ nc feed.community.greenbone.net 873
@RSYNCD: 31.0 sha512 sha256 sha1 md5 md4
Greenbone community feed server - http://feed.community.greenbone.net/
This service is hosted by Greenbone Networks - http://www.greenbone.net/
All transactions are logged.
If you have any questions, please use the Greenbone community portal.
See https://community.greenbone.net for details.
By using this service you agree to our terms and conditions.
Only one sync per time, otherwise the source ip will be temporarily blocked.
@ERROR: protocol startup error
└─$ nc 45.135.106.143 873
@RSYNCD: 31.0 sha512 sha256 sha1 md5 md4
Greenbone community feed server - http://feed.community.greenbone.net/
This service is hosted by Greenbone Networks - http://www.greenbone.net/
All transactions are logged.
If you have any questions, please use the Greenbone community portal.
See https://community.greenbone.net for details.
By using this service you agree to our terms and conditions.
Only one sync per time, otherwise the source ip will be temporarily blocked.
So with both IP and hostname I can download the banner. My machine is in no way blocked from your IP’s or on rsync’s port number. That’s clear to me from the fact that the Notus and NASL syncs work. Maybe our IP address is blocked at your end for certain rsyncs ?
I do one sync every 2 days - thats all. I don’t launch multiple commands at the same time - just the one so there should just be one session each time. I’ll wait until tomorrow and retest a manual sync and let you know how it’s going.
Hi all. this is not a firewall or server issue. My databases have also not been updated for several days. everything is configured by cron once a day. and a week ago everything was working fine
I now manually ran greenbone-feed-sync several times and was able to update NVT and SCAP.
but CERT and GVMD_DATA are not updated
⠋ Downloading CERT-Bund data from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/cert-data/ to /var/lib/gvm/cert-data
I can confirm, that there seems to be an infrastructure issue as installations that have had no problem running a feed sync for well over a year, are now having problems. The problem only exists if the site tries to complete a full sync from zero. If it is only running an update on an existing complete feed sync and database, then the feed sync seems to run fine. If I set a timer to restart the sync from on the sync from zero install with a 30 second delay, then it will eventually complete a full synchronization. ( it restarted more than 25 times.)
Thanks for the confirmation. It’s exactly the same for me. These syncs were working flawlessly around the 19th March and from the 21st the problems started (I have all this logged) - no network or infrastructure changes on my side so the issue has to be on Greenbone’s side.
Update …
I’m now seeing issues updating from a pre-existing set of feeds as well.
tcpdump shows tons of rsync traffic, and I confirmed there is data being received, so definitely not a firewall issue. The problem seems to be in connection time.
The feed-sync script runs multiple rsyncs in the normal course of execution with --type=all . Normally, the first rsync finishes, the TCP connection closes properly and then the next one will start. At the moment, the first connection is failing after a time, and does not properly close the TCP connection. The script then immediately continues to the next rysnc command which immediately fails as the system, seeing the unclosed previous connection, now sees two simultaneous connections from the same IP and refuses to connect.