This is all documented here:
Closing this topic here.
1 Like
well - closing the topic is not really “friendly” but i need to accept this …
If there’s still others with this problem. I tried only one feed after waiting 24 h with not open session - same result
└─$ sudo runuser -u _gvm – greenbone-feed-sync --type GVMD_DATA 1 ⨯
[sudo] password for xxxxxxx:
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(276) [Receiver=3.2.3]
I guess it was not meant to be unfriendly, just pointing to the solution in the other topic:
Did Back-to-Back Syncs Failing help you?
1 Like
No - unfortunatly it does still not work.
So i put my kali linux vm directly into the network of my router.
there’s no way to get closer to the “internet” as doing it this way.
The router is assigning an ipv4 and an ipv6 adress.
I removed greenbone and openvas, rebooted, reinstalled and run gvm-setup.
Well of course some parts of the database are prepared but here’s what’s happening:
–> SNIP <–
Creating openvas-scanner’s certificate files
[>] Creating database
createuser: error: creation of new role failed: ERROR: role “_gvm” already exists
createdb: error: database creation failed: ERROR: database “gvmd” already exists
ERROR: role “dba” already exists
NOTICE: role “_gvm” is already a member of role “dba”
GRANT ROLE
ERROR: extension “uuid-ossp” already exists
ERROR: extension “pgcrypto” already exists
[>] Migrating database
[>] Checking for admin user
[>] Updating OpenVAS feeds
[*] Updating: NVT
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(276) [Receiver=3.2.3]
[>] Uploading plugins in Redis
[] Updating: GVMD 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(276) [Receiver=3.2.3]
[] Updating: 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(276) [Receiver=3.2.3]
[*] Updating: Cert Data
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.
receiving incremental file list
timestamp
13 100% 12.70kB/s 0:00:00 (xfr#1, to-chk=0/1)
sent 43 bytes received 115 bytes 63.20 bytes/sec
total size is 13 speedup is 0.08
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.
receiving incremental file list
rsync: [generator] failed to set permissions on “/var/lib/gvm/cert-data/CB-K13.xml”: Operation not permitted (1)
./
rsync: [generator] failed to set permissions on “/var/lib/gvm/cert-data/dfn-cert-2015.xml”: Operation not permitted (1)
rsync: [generator] failed to set permissions on “/var/lib/gvm/cert-data/dfn-cert-2016.xml”: Operation not permitted (1)
rsync: [generator] failed to set permissions on “/var/lib/gvm/cert-data/dfn-cert-2018.xml”: Operation not permitted (1)
CB-K18.xml
4,778,354 100% 94.94MB/s 0:00:00 (xfr#1, to-chk=22/29)
CB-K19.xml
4,143,951 100% 12.55MB/s 0:00:00 (xfr#2, to-chk=21/29)
CB-K20.xml
4,669,573 100% 3.11MB/s 0:00:01 (xfr#3, to-chk=20/29)
CB-K21.xml
2,279,536 100% 822.96kB/s 0:00:02 (xfr#4, to-chk=19/29)
dfn-cert-2017.xml
3,127,720 100% 3.50MB/s 0:00:00 (xfr#5, to-chk=8/29)
dfn-cert-2019.xml
3,549,005 100% 3.82MB/s 0:00:00 (xfr#6, to-chk=6/29)
dfn-cert-2020.xml
3,659,208 100% 3.55MB/s 0:00:00 (xfr#7, to-chk=5/29)
dfn-cert-2021.xml
1,996,101 100% 956.49kB/s 0:00:02 (xfr#8, to-chk=4/29)
sha1sums
1,419 100% 44.70kB/s 0:00:00 (xfr#9, to-chk=3/29)
sha256sums
2,019 100% 59.75kB/s 0:00:00 (xfr#10, to-chk=2/29)
sha256sums.asc
819 100% 23.52kB/s 0:00:00 (xfr#11, to-chk=1/29)
timestamp
13 100% 0.35kB/s 0:00:00 (xfr#12, to-chk=0/29)
sent 88,123 bytes received 2,139,779 bytes 297,053.60 bytes/sec
total size is 77,052,246 speedup is 34.59
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1816) [generator=3.2.3]
[*] Checking Default scanner
08b69003-5fc2-4037-a479-93b440211c73 OpenVAS /var/run/ospd/ospd.sock 0 OpenVAS Default
[+] Done
–> SNIP <–
I don’t know what else i can do to fulfil the needs.
I activated and tested ipv6
I put the machine as near to the internet as possible and still it does not work.
So - guess you are right with nat or timeout - why does it partially sync the data?
I am totaly confused und feeling helpless.
It worked fine for months until i updated to 21.04.
The new messages are looking quite different to the initial ones. Could this be related to the following problem in the Linux Kernel in conjunction with rsync:
Thx cfi,
Hi Lukas,
checked again this morning. Client is directly behind the router, only ipv6 is enabled and waited many hours without any action.
…
pre2008/zyxel_pwd.nasl
3,084 100% 5.26kB/s 0:00:00 (xfr#74993, to-chk=115/76168)
sent 4,562,718 bytes received 18,113,521 bytes 223,411.22 bytes/sec
total size is 356,153,916 speedup is 15.71
At this point the system is hanging.
Checked kernel:
└─$ uname -r
5.10.0-kali9-amd64
└─$ uname -a
Linux kali 5.10.0-kali9-amd64 #1 SMP Debian 5.10.46-1kali1 (2021-06-25) x86_64 GNU/Linux
└─$ cat /proc/version
Linux version 5.10.0-kali9-amd64 (devel@kali.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-1kali1 (2021-06-25)
└─$ sudo dmesg | grep Linux [ 0.000000] Linux version 5.10.0-kali9-amd64 (devel@kali.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-1kali1 (2021-06-25)
So 5.10.0 is the latest kernel for kali, but guess before rc1?
Compiling my own kernel does not make sense as i will loose future kernel updates…
But - why did it work with this kali installation over months? shouldn’t the bug be a problem in olders setups also?
Strange …
Also - if i read the source code right, this is a IPv4 issue. But i am using IPv6 only?
That is really strange but at least i am not alone with this problem …
If you send me your source address i can have a look …
At the moment our community server is distributing 1.5TB community feed per day.
Are you 100% sure that your ISP is not messing up with any NAT technology ?
Did you asked your ISP ?
1 Like
guess it will not be possible to ask ISP - they do not know this.
I will try again tomorrow and send my v6IP via PN if this is O.K. for you.
Regarding NAT - i am using this since years / decades and never had such problems. But - in IT “never” is only true until sommething happens the first time 
Meanwhile you can try with our VM, GSM Trial that is the “only” supported platform to ensure this is not a issue due to uncoordinated integrations.
1 Like
i have installed GSM Trial as VM and started in LAN. Here’s the first result:
With this setup the machine is running on IPv4. It did not get an IPv6 adress automatically.
Next i move the network adapter into my WAN zone, directly behind my router.
Let’s look what is happening there …
guess i will give up now.
I was told that my system is resetting the connection - (i do believe this due the log entry shown) my system (wireshark) is telling me the opposite.
Also - even the trial VM is unable to synch the feed…
Next i tried with a different access (normal is vodafone and zyxel, tryout was telekom and huawei) - still no persistent thread update.
sometimes the nvt’s worked but the system stopped the next step.
So i am not only confused but also at the end of what i could try.
here’s the result of my findings:
The idea that it is a problem with rsync and old bug can not be true as it does not work with the appliance.
The hardware and provider should not be the problem - i tested two different combinations.
My firwall can not be the cause - i tested directly behind the router.
IPv4 / NAT - i tested with IPv6 also without getting a solution.
I do know that it worked fine without problems in the previous version. The problems started after the update to the latest release
So all i can try is to install the previous release.
On the other hand it is still strange, that so many other people do have problems with the feed update …
so here’s my last try before giving up.
I made a fresh install of kali 2021.2 as predefined VM.
After “apt update && apt full-upgrade” i installed sudo apt install openvas gvm following this guideline:
https://www.ntbrad.com/2020/12/08/kali-and-openvas-gvm-setup/
had a small problem with postgresql due to “locales” that was fixed soon. postgresql 13 was default and the only one installed.
Next was gvm-setup with this result:
└─$ sudo gvm-setup 1 ⨯
Creating openvas-scanner’s certificate files
[>] Creating database
CREATE ROLE
GRANT ROLE
CREATE EXTENSION
CREATE EXTENSION
[>] Migrating database
[>] Checking for admin user
[] Creating user admin for gvm
[] Please note the generated admin password
[] User created with password ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’.
[] Define Feed Import Owner
[>] Updating OpenVAS feeds
[*] Updating: NVT
At this point the system hang without any action.
So after some time i made a reboot and tried again. Still the same “hang” at the same position.
use iftop to check if there’s any action on the network but - nothing.
So to all using kali and having the same problems - i did not find any solution for this problem.
Maybe i will find some help at the kali forums …
I just checked we had last day 340.000 feed syncs, so there must be something wrong at the infrastructure or your ISP. I suggest you contact your support and ask about CGN and real IPs ?
1 Like
Thx Lukas,
guess vodafone will not be willing to change something for me.
I will need to check for a different solution that i can offer my customers instead.
Have a good time.
1 Like
I am back …
I found out a hint regarding
sync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync .c(276)
on
https://forums.gentoo.org/viewtopic-t-305269-highlight-rsync.html.
So i just downloaded the source for rsync following this guide:
http://www.beginninglinux.com/home/backup/compile-rsync-from-source-on-ubuntu
!!! Take the latest version !!!
Needed to get some missing dependencies but finally i was able to build a current rsync version.
I did not yet made my own “make.conf” as mentioned in the article so there’s no config above the given source.
After this action i was able to run my “gvm-setup” without problems.
Came back to the known problem with:
ERROR: Greenbone Security Assistant too old or too new: 21.4.1~dev1 FIX: Please install Greenbone Security Assistant >= 21.04.ERROR: Your GVM-21.4.1 installation is not yet complete!
but this could be fixed very fast following this guide:
I will now continue testing.
As far a i can understand the problem it might occur with “no so fast” network connections like the one i have (LTE, <20 MBit/s).
I’d be happy if others could try this out to see, if this might be the solution for the problem…
2 Likes
If its working for you, that’s awesome. The reason we’ve raised the issue is that its not working for us, could we possibly address that? I’m just not sure I’ll get anywhere by raising it with my ISP
Got the following error:
*] Updating NVT (Network Vulnerability Tests feed from Greenbone Security Feed/Community Feed)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Connection timed out (110)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Connection timed out (110)
rsync error: error in socket IO (code 10) at clientserver.c(137) [Receiver=3.2.3]
Added an entry to /etc/hosts:
45.135.106.142 feed.community.greenbone.net
Ran the gvm-feed-update successfully after that.
1 Like
That is the old server, try the new one after your DNS resolution …
The 143 IP Address was failing, the .142 worked. What is the new address?