Trouble finding feed for 2a10:4741:30::/44

[sid6mathur]

The owner of 2a10:4741:30::/44 has published their feed URL with the geofeed attribute in inet6num records but it isn't discovered in the output CSV with neither of -i ripe or -i arin. What could be the reason? Any guidance is appreciated.

https://apps.db.ripe.net/db-web-ui/query?searchtext=2a10:4741:30::%2F44

Other observations:

• Deleting the cache directory to trigger a re-download didn't change the above behavior
• Interestingly, geofeed-finder-linux-x64 -t 2a10:4741:30::/44 yields the correct results on stdout

[sgteq]

Not reproducible here. How many lines do you have in the output csv file?

sgteq@desk ~/geofeed $ fgrep 2a10:4741: ripe-2023-02-02.csv
2a10:4741:0030:0000:0000:0000:0000:0000/44,,,,
2a10:4741:0032:0000:0000:0000:0000:0000/48,CA,CA-ON,Toronto,
2a10:4741:0036:0000:0000:0000:0000:0000/48,CA,CA-QC,Montreal,
2a10:4741:0037:0000:0000:0000:0000:0000/48,CA,CA-QC,Montreal,
2a10:4741:0033:0000:0000:0000:0000:0000/48,CA,CA-ON,Toronto,
2a10:4741:0035:0000:0000:0000:0000:0000/48,CA,CA-QC,Montreal,
sgteq@desk ~/geofeed $ wc -l ripe-2023-02-02.csv
31128 ripe-2023-02-02.csv

[sid6mathur]

I am using the pre-built Linux AMD64 binary in the releases folder , v1.7.0 ~$ ~/bin/geofeed-finder-linux-x64 -v 1.7.0

Command I use: ~/bin/geofeed-finder-linux-x64 --keep-non-iso --keep-invalid-subdivisions --download-timeout 0 -i ripe -o ripe.csv

Line count: ~$ wc -l ripe.csv 32604 ripe.csv

No results: ~$ cat ripe.csv |grep -i 2a10:4741

[sid6mathur]

31741 lines in my ripe.csv but no mention of any 2a10:4741. Altering the CLI options has no effect on this specific outcome. Will try recompiling myself, rather than use the precompiled binary release v1.7.0

[massimocandela]

Hi @s8mathur,

I just tried with both no parameters (31800 entries) and with the parameters you reported in your previous post (32583 entries), only ripe.

In both cases I can get the prefixes correctly.

2a10:4741:0030:0000:0000:0000:0000:0000/44,,,,
2a10:4741:0032:0000:0000:0000:0000:0000/48,CA,CA-ON,Toronto,
2a10:4741:0036:0000:0000:0000:0000:0000/48,CA,CA-QC,Montreal,
2a10:4741:0037:0000:0000:0000:0000:0000/48,CA,CA-QC,Montreal,
2a10:4741:0033:0000:0000:0000:0000:0000/48,CA,CA-ON,Toronto,
2a10:4741:0035:0000:0000:0000:0000:0000/48,CA,CA-QC,Montreal,

Precompiled or not doesn't matter. However, just to be sure I also tried with the precompiled downloaded from git (version 1.7.0). Same result of above, everything is fine.

I would suggest you to check that you are able to download the geofeed file: check inside logs/ and grep for as208914. Also, your lower count of geofeed suggests me that your cache is not up to date. Try rm -rf .cache in the root directory where geofeed-finder is.

Update: I read wrongly your results, 32604 skipping the iso check is a fresh cache. I would focus on the logs/ then. However, it could still be that the geofeed file itself is cached.

[sid6mathur]

Thanks for your help, folks. Deleting rm -rf ~/.cache (instead of the rm -rf ~/.cache/ripe and rm -rf ~/.cache/arin that I did previously) seems to have fixed the problem, hence closing this issue. Somewhat troubling that the cache files go into a silent failure mode, but I will keep an eye out for future inconsistencies of the type. Perhaps ~/.cache/<toolname> should be used as cache root directory to avoid inadvertent collision with many other tools which save files there?

[massimocandela]

I think you removed the whois dump, but the geofeed file itself was still cached. I would cd in the location of the binary and run it, in this way the .cache directory is inside the same directory of the binary (however, I think it was just cached and it needed to expire).