198.148.78.0 has a location according to v1.5.2 "-t" but it's not in the resulting .csv

[sgteq]

This is a minor impact issue that could be caused by more than one space between Geofeed keyword and url. Only a single case was found across about 300 records. As far as I see the RFC does not specify that only one space must be placed so I think two or more spaces should be allowed. In any case "-t" option and a general run of the geofeed-finder do not agree.

sgteq@desk:~/geofeed$ ./geofeed-finder-linux-x64-1.5.2 -i arin -o arin.csv -k| tee arin.log
...
Done! See arin.csv
sgteq@desk:~/geofeed$ grep 198.148.78.0 arin.csv
sgteq@desk:~/geofeed$ grep talos.csv arin.log
sgteq@desk:~/geofeed$ ./geofeed-finder-linux-x64-1.5.2 -t 198.148.78.0
inetnum: 198.148.78.0/23 https://talosops-public.s3.amazonaws.com/talos.csv [cache]
198.148.78.0/23,US,US-VA,Ashburn,
198.148.78.6/32,US,US-MD,Fulton,
198.148.78.134/32,US,US-MD,Fulton,
198.148.78.240/29,US,US-TX,Dallas,

Retrieved whois data:

198.148.78.0.txt:Comment:        Geofeed  https://talosops-public.s3.amazonaws.com/talos.csv

The web UI of ARIN uses standard html to display the record so it displays only one space even though the html source code has two. That's another argument for accepting more than one space.

[massimocandela]

This is done, at the moment the parser is more permissive. However, it is more strict in reporting warnings. While running a test with -t it will report all anomalies like double spaces. I hope this helps.