Feeds Down?

Good evening,
Are the feeds down? I’m getting a connection refused from multiple IPs including ones that I have never used to pulled from greenbone before.


1 Like

Hmmm … seems to be back up this morning.



No, they weren’t :wink:

1 Like

It seems that it’s down this weekend:

rsync rsync://
rsync: [Receiver] failed to connect to ( Connection timed out (110)
rsync error: error in socket IO (code 10) at clientserver.c(137) [Receiver=3.2.3]

1 Like

Same here

openvas    | Updating NVTs and other data
openvas    | This could take a while if you are not using persistent storage for your NVTs
openvas    |  or this is the first time pulling to your persistent storage.
openvas    |  the time will be mostly dependent on your available bandwidth.
openvas    |  We sleep for 5 seconds between sync command to make sure everything closes
openvas    |  and it doesnt' look like we are connecting more than once.
openvas    |  Pulling NVTs from greenbone
openvas    | <28>Nov  8 10:48:58 greenbone-nvt-sync: The log facility is not working as expected. All messages will be written to the standard error stream.
openvas    | <29>Nov  8 10:48:58 greenbone-nvt-sync: No Greenbone Security Feed access key found, falling back to Greenbone Community Feed
openvas    | <29>Nov  8 10:49:03 greenbone-nvt-sync: Configured NVT rsync feed: rsync://feed.community.greenbone.net:/nvt-feed
openvas    | rsync: failed to connect to feed.community.greenbone.net ( Connection timed out (110)
openvas    | rsync: failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe67:cbb5): Cannot assign requested address (99)
openvas    | rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3]
openvas    | <27>Nov  8 10:49:34 greenbone-nvt-sync: rsync failed.
1 Like

I have found that the IPv6 address seems quite reliable - so have used a tunnel from https://ipv6.he.net/ (my ISP does not support IPv6) to download, and everything has worked since.

Same here as well, unfortunately IPv6 is not an option for us.

You only hit the DoS protection, with IPv6 your chance for a slot are much better. At the moment we hard limit on 150 simultaneous rsync via IPv4 and IPv6. If you hit the limit your IP will be blacklisted for 300 sec.

Looks like I hit that hard limit quite often these days then. Thanks for clarification and the mentioning of the 300sec black-/block-/denylisting.

Have you evaluated if providing the feeds via git might yield improvements over rsync? It would have the additional benefit of easily being able to see and track what has actually changed. Not sure about any security or business implications but you could stuff and/or mirror the whole thing (community feeds) on e.g. GitHub and not have to worry about DoS and/or bandwidth anymore.

We work on a new distribution systems, meanwhile i try to make a more DoS resilient server right now. Without connection tracking and the typical distribution overhead to be able to hard control the IO Scheduler.