Rsync error when sync to feeds

[mmar22]

Hey all, i am using Version 21.4.3 on Debian 11. This VM is in our Xenserver hypervisor.

I have been having rsync issue when syncing to the latest feeds. I did some workaround and manage to sync the GVMD_DATA but could not on others.

When I convert the VM to test on Virtualbox the sync process is successful. Is this due to the EOL of v21.4.3? Kindly help on this, Thanks in advance.

[bricks]

Hi,

if you are able to sync the gvmd data you should be able to sync the other feed types too. There is no difference between them besides the URLs. Most likely this is a network setup issue on your side. Please use the search of this forum for finding threads about debugging the issue. There are already a lot of hints in existing threads.

[mmar22]

Hi, first of all thank you for replying.

At fist i also suspected it to be a network issue, but upon checking the firewall we did not block port 873 for the rsync to feed.community.greenbone.net. A telnet test also suceed.

Attached is the result of the tcptraceroute and telnet. Thanks in advance.

[cfi]

Besides the already mentioned networking issue this could be caused also by other environmental issues like e.g.:

24-year-old bug in the Linux Kernel might impact you rsync

Hi all, we notices that some of you had issues with syncing the community-feed via rsync some parallel investigations shows an very interesting article about this that might describe the bug as well. This ONLY impact the GCF (Greenbone appliances and GSF are not impacted by that bug). https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-linux-kernel/ As result we at Greenbone updated all Kernels at our community feed servers, but you need to update your Linux-Kernel to a f…

[mmar22]

Hi,

Thanks for all the reply. Now i am able to sync the feeds to latest version.

[Technolust]

Running Kali Purple and I am experiencing this same issue but the kernel update doesn’t resolve.

uname -a
Linux technolust-purple 6.3.0-kali1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1kali1 (2023-06-29) x86_64 GNU/Linux

Showing the Send and Receive

 ss -mito dst :873
State                 Recv-Q              Send-Q                            Local Address:Port                                Peer Address:Port               Process
SYN-SENT              0                   1                                   10.69.0.221:37524                             45.135.106.143:rsync               timer:(on,11sec,4)
         skmem:(r0,rb131072,t0,tb16384,f3200,w896,o0,bl0,d0) cubic rto:16000 backoff:4 mss:524 pmtu:1500 rcvmss:88 advmss:1460 cwnd:1 ssthresh:7 segs_out:5 lastsnd:26088660 lastrcv:26088660 lastack:26088660 app_limited unacked:1 retrans:1/4 lost:1 rcv_ssthresh:64240

TCP Dump Shows:

 sudo tcpdump | grep -i 45.135.106.143
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:13:01.558312 IP pi.hole.domain > 10.69.0.221.58973: 60107 1/0/0 A 45.135.106.143 (62)
09:13:01.567722 IP 10.69.0.221.60184 > 45.135.106.143.rsync: Flags [S], seq 767118998, win 64240, options [mss 1460,sackOK,TS val 2918796561 ecr 0,nop,wscale 7], length 0
09:13:02.594294 IP 10.69.0.221.60184 > 45.135.106.143.rsync: Flags [S], seq 767118998, win 64240, options [mss 1460,sackOK,TS val 2918797588 ecr 0,nop,wscale 7], length 0
09:13:04.610315 IP 10.69.0.221.60184 > 45.135.106.143.rsync: Flags [S], seq 767118998, win 64240, options [mss 1460,sackOK,TS val 2918799604 ecr 0,nop,wscale 7], length 0
09:13:08.706307 IP 10.69.0.221.60184 > 45.135.106.143.rsync: Flags [S], seq 767118998, win 64240, options [mss 1460,sackOK,TS val 2918803700 ecr 0,nop,wscale 7], length 0
09:13:16.898333 IP 10.69.0.221.60184 > 45.135.106.143.rsync: Flags [S], seq 767118998, win 64240, options [mss 1460,sackOK,TS val 2918811892 ecr 0,nop,wscale 7], length 0
09:13:33.026302 IP 10.69.0.221.60184 > 45.135.106.143.rsync: Flags [S], seq 767118998, win 64240, options [mss 1460,sackOK,TS val 2918828020 ecr 0,nop,wscale 7], length 0
09:14:07.074316 IP 10.69.0.221.60184 > 45.135.106.143.rsync: Flags [S], seq 767118998, win 64240, options [mss 1460,sackOK,TS val 2918862068 ecr 0,nop,wscale 7], length 0

Running the update sudo greenbone-feed-sync

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: [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): Network is unreachable (101)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]

⠧ Downloading NASL files from rsync://feed.community.greenbone.net/community/vulnerability-feed/22.04/vt-data/nasl/ to /var/lib/openvas/plugins
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): 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/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: [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): Network is unreachable (101)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]

⠧ 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 timed out (110)
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 timed out (110)
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

Not sure what to check/do next…

Thoughts?

[rippledj]

See this link to a post about what I consider the best way to trouble shoot a connection:

Cannot ping "feed.community.greenbone.net" or 45.135.106.143

I know that you have resolved this issue already, but I thought I would add what I think to be the most effective way to troubleshoot the rsync connection to Greenbone’s feed sync servers in case someone else has this issue. The nping command is part of the nmap tool. It can be used to directly traceroute a TCP connection to a specific port while traceroute and tcptraceroute cannot be configured to test a specific port. This will help identify port-based firewall rules as well as host / IP-bas…

The entire thread discusses other options for troubleshooting your connection.

[Technolust]

Everything I read in the rabbit hole…

gvm-check-setup 22.5.0
  Test completeness and readiness of GVM-22.5.0
Step 1: Checking OpenVAS (Scanner)...
        OK: OpenVAS Scanner is present in version 22.7.3.
        OK: Notus Scanner is present in version 22.5.0.
        OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.
Checking permissions of /var/lib/openvas/gnupg/*
        OK: _gvm owns all files in /var/lib/openvas/gnupg
        OK: redis-server is present.
        OK: scanner (db_address setting) is configured properly using the redis-server socket: /var/run/redis-openvas/redis-server.sock
        OK: the mqtt_server_uri is defined in /etc/openvas/openvas.conf
        ERROR: Directories containing the NVT collection not found.
        FIX: Run the NVT synchronization script greenbone-feed-sync.
        sudo greenbone-feed-sync --type nvt

 ERROR: Your GVM-22.5.0 installation is not yet complete!

Please follow the instructions marked with FIX above and run this
script again.

sudo traceroute -T -O info 45.135.106.143

traceroute to 45.135.106.143 (45.135.106.143), 30 hops max, 60 byte packets
 1  10.69.0.1 (10.69.0.1)  0.306 ms  0.295 ms  0.293 ms
 2  * * *
 3  * * *
4  38.104.30.226 (38.104.30.226)  2.055 ms  1.983 ms  1.981 ms
 5  be6533.rcr21.b003320-1.dca01.atlas.cogentco.com (38.104.30.225)  18.721 ms  17.484 ms  17.379 ms
 6  be2213.ccr41.dca01.atlas.cogentco.com (154.54.6.241)  18.501 ms be2231.ccr42.dca01.atlas.cogentco.com (154.54.83.69)  18.411 ms be2213.ccr41.dca01.atlas.cogentco.com (154.54.6.241)  16.601 ms
 7  * * be3111.ccr42.par01.atlas.cogentco.com (154.54.89.226)  100.088 ms
 8  be2800.ccr42.fra03.atlas.cogentco.com (154.54.58.237)  108.167 ms * *
 9  be2846.rcr22.fra06.atlas.cogentco.com (154.54.37.30)  109.246 ms * *
10  be2844.agr21.fra06.atlas.cogentco.com (130.117.0.30)  107.888 ms * *
11  149.11.20.50 (149.11.20.50)  109.511 ms * *
12  po1-2899.ccr2.whp26.fra.iag.eu (195.34.175.5)  105.684 ms * *
13  * * *
14  * * *
15  * * *

I can’t access the feed via rsync and the documents say I need to sync with the feed.

[rippledj]

This is really a different issue than the OP’s so I suggest creating a new thread on the forum.
Also, the command you executed doesn’t properly test your rsync connection since it does not specifically test the rsync port (873), so it doesn’t specifically test for firewall restrictions that block the rsync port.

@Technolust

sudo traceroute -T -O info 45.135.106.143

That’s why I pointed you to the other post which shows a test that does specifically test the rsync port.

[Technolust]

My apologies, I will open up a new thread. Also did the rsync specific and the results are inconclusive.

─$ sudo traceroute -T -O info 45.135.106.143 -p 873
traceroute to 45.135.106.143 (45.135.106.143), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *

I disabled all services on the firewall and I still could not get through.

Thanks for the help.

[rippledj]

@Technolust

Also did the rsync specific and the results are inconclusive.

Hmm… seems the result of the traceroute with the specified port is not inconclusive. It clearly shows you cannot reach the destination, in fact, your packets seem they cannot reach even the next host, and certainly indicates they cannot go beyond your local network. I guess this means you have some firewall blocking on your local host.

Here is the output of a successful traceroute using the command you used. It shows the packets can reach the gateway (192.168.1.1) and also transit the global internet:

sudo traceroute -T -O info 45.135.106.143 -p 873
traceroute to 45.135.106.143 (45.135.106.143), 30 hops max, 60 byte packets
 1  mynetwork (192.168.1.1)  0.410 ms  0.380 ms  0.422 ms
 2  lnsm4-toronto63--lo0.net.bell.ca (64.230.11.234)  1.864 ms  1.852 ms *
 3  tcore3-toronto63--2/10/0/3--be43.net.bell.ca (64.230.101.144)  22.848 ms  22.836 ms  22.823 ms
 4  cr01-toroon63zda-bundle-ether7.net.bell.ca (142.124.127.157)  14.380 ms  15.674 ms *
 5  * * *
 6  bx9-chicagodt_ae0-0.net.bell.ca (64.230.79.73)  16.891 ms  14.640 ms  14.586 ms
 7  * * *
 8  ae1.3110.edge4.Frankfurt1.level3.net (4.69.163.106)  111.980 ms  111.930 ms  110.646 ms
 9  INTERNET-AG.edge4.Frankfurt1.Level3.net (62.67.19.26)  108.171 ms  109.359 ms  109.324 ms
10  po1-2890.ccr1.whp26.fra.iag.eu (195.34.175.194)  108.387 ms  108.302 ms  109.072 ms
11  * * *
12  45.135.106.143 (45.135.106.143) <syn,ack>  109.183 ms  108.560 ms  105.984 ms