Download of data from ftp.ripe.net fails silently

[herrbischoff]

Environment

$ uname -a
FreeBSD [REDACTED] 12.1-RELEASE-p5 FreeBSD 12.1-RELEASE-p5 GENERIC  amd64

Issue

Recently, since about a week, download of IP data from ftp.ripe.net fails halfway through without any error output, just with an exit code of 1.

Excerpt:

$ sudo ipdb-update.sh ftp.ripe.net
/usr/local/etc/ipdb/IPRanges/afrinic.md5                74  B  393 kBps    00s
/usr/local/etc/ipdb/IPRanges/afrinic.dat               571 kB 4125 kBps    00s
/usr/local/etc/ipdb/IPRanges/apnic.md5                  73  B  437 kBps    00s
/usr/local/etc/ipdb/IPRanges/apnic.dat                6358 kB 4098 kBps    01s

$ echo $?
1

Using another RIR FTP like ftp.apnic.net or ftp.lacnic.net is extremely slow but completes as expected and exits cleanly with 0.

[cyclaero]

I verified the issue, and the problem is, that the stored MD5 hash of the apnic data does not match the hash of the dowloaded data.

fetch ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-extended-latest.md5
fetch ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-extended-latest
cat delegated-apnic-extended-latest.md5
--> MD5 (delegated-apnic-extended-latest) = 5c761e7ab4dd98737acc71ecb1e89bbd
md5 delegated-apnic-extended-latest
--> MD5 (delegated-apnic-extended-latest) = abc891ea8ea594e6dec5eaaffa93b28f

The update simply exits when it sees hash mismatches, since it cannot do much about this by itself. The options are:

1. utilize another mirror, until Ripe comes up with a correct hash for the Apenic data.
2. edit a copy of theipdb-update.shin order to let it ignore the mismathch, e.g. you could put a # in front of line 96:

   ipdb/ipdb-update.sh

   Line 96 in 8571703

   exit 1

[cyclaero]

FYI, for some reason Ripe does not update the MD5 hash file of the Apnic data. The MD5 hash file on the Apnic upstream repo does match the actual MD5 hashes of both data files, namely the one on the Ripe mirror and the one on the Apnic upstram repo.

EDIT: On the Ripe mirror the MD5 hash file of the Lacnic data is outdated as well.

[herrbischoff]

Thanks for looking into this. My brain somehow did not process the fact that ipdb-update.sh is a shell script, so I could have debugged this myself. Therefore, double thanks.

Just out of curiosity: why use the MD5 hash at all? My understanding is, that to truly verify a file has not been tampered with during transfer, you'd need to get the hash file through some other means, preferably secure. Or is this simply meant as a basic checksum to ensure that the full file has been transferred?

In any case, I have just reported this issue to RIPE NCC and hope they will look into it.

[cyclaero]

The MD5 hash checking is really meant as checksum for file integrity. I use the update script in a weekly cron job, and some firewall rules rely on the proper functionality of the ipdb lookup. So, in the case of MD5 mismatches, I prefer that the database files are simply not touched and ipdb continues working.

In the present case, the data files are correct and some of the MD5 hash files are outdated for some reasons. It could well be vice versa. There could be various scenarios which could corrupt a data file, either on the mirror or upstream. In my crontab I got:

# weekly update of the IP geo-location databases
11      3      *       *       7       root    /usr/local/bin/ipdb-update.sh ftp.lacnic.net > /dev/null 2>&1  && /root/config/ipfw.reload || echo "Weekly update of the IP databases failed." 1>&2

Therefore, I receive an e-mail when something went wrong. The firewall would just work with the old IP db's for another day, and I would be able to troubleshoot the issue calmly without having any transtortions in the back.

I didn't see the issue, because I am in Brazil and I use the Lacnic mirror, which can be accessed from here as fast as the Ripe mirror from somewhere in Europe.

[herrbischoff]

Response from RIPE NCC:

Thanks for reporting this.
We will address the issue shortly.

Please note that it's also possible to retrieve a "combined" file which is linked from this page:
https://www.nro.net/new-global-extended-statistics-report/
(unfortunately without MD5).

[cyclaero]

It looks like RIPE NCC has fixed the issues with incorrect MD5 files on their mirrors.

[herrbischoff]

Unfortunately it did not work for me, so I reported this back. Finally, they confirmed the issues to be resolved today and I can confirm it working on my end.

In the meantime I made the script output a simple error message with the mismatching hashes. Would you consider adding something like that?

[cyclaero]

In the meantime I made the script output a simple error message with the mismatching hashes. Would you consider adding something like that?

Yes, please attach the changed script here, and I will have a look at it. This week I will be quite busy, and I cannot promise to work on it immediately, though.