Tested again this morning from a server in a Frankfurt Datacenter. The rsync ran for about 5 minutes before dropping.
tcpdump shows the transfer going along smoothly, then the server starts sending resets.
-Scott
Hmm i changed the firewall a bit, can you try again … mit-sync rest is often a trigger of a firewall signature .-(
So i turned on rsync all protections off.
Happy Easter
Tested again this morning with the same result.
-Scott
I just tested it with a empty feed without any issues. So check your TCP-Timeout and if you have any IPS that might rest your connection.
@Lukas ,
Thanks, I’m not sure what you mean by TCP-Timeout though. (there are lots of keep-alive settings in /proc/sys/net, but nothing specifically to timeout and regardless, nothing is being changed from the kernel standards ) If there is a timeout set by rsync, that is being handled by the greenbone-feed-sync script. The servers I’m running from are Linodes, so they have direct connections to the internet (no external firewalls or NAT.) I’ve tested from multiple nodes in multiple data centers in different regions of the world, all with the same result. I’ve watched and analyzed the tcp streams, and the time between the first RST from the rsync server and the previous ACK is in milliseconds, so it doesn’t look like a timeout. I’m not infallible though, so I could be missing something on my end, but I’m at a complete loss as to what that could be.
-Scott
I see exactly the same, no improvment.
Okay everybody, can you give it a try now? If it’s still not working right go ahead and follow up in the thread, thanks! 
2 Likes
@DeeAnn
Two seperate tests from two seperate servers, one last night and one this morning.
I’m happy to report, that both synced fully from zero!
Seems the issue is resolved.
Thank you!!
2 Likes
Good news, first successful sync the first time today for me. Seems to be back to normal. Thanks for fixing this !
2 Likes
That’s great news and thanks for letting us know!
2 Likes
I’m still seeing this issue. My version is showing 202403191649, and I’m seeing the connection reset error:
$ /usr/local/bin/greenbone-feed-sync -c ./feed-sync.toml --type nvt
Trying to acquire lock on ./vt/feed-update.lock
Acquired lock on ./vt/feed-update.lock
⠦ Downloading Notus files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/notus/ to ./notus
⠼ Downloading NASL files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/nasl/ to ./vt
rsync: read error: Connection reset by peer (104)
rsync error: error in socket IO (code 10) at io.c(806)
rsync: connection unexpectedly closed (189337 bytes received so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(231)
Releasing lock on ./vt/feed-update.lock
Tried multiple times. Everything else syncs fine, it’s just the nasl files which are failing.