Closed fjahr closed 3 months ago
Count me in!
It might be useful to have a ./run check
which does some sanity checking and spits out relevant info like the rpki-client version.
I'm at 9.0, which is the latest shipped with Ubuntu: https://launchpad.net/ubuntu/noble/+package/rpki-client
I'll try building 9.1 from source.
If anyone I know feels like signing this key... https://ftp.openbsd.org/pub/OpenBSD/rpki-client/RELEASE_KEY.asc
Mmm, building from source on Ubuntu seems very non-trivial, since you need LibreSSL / libtls? I'll try the nix route (but that's not ready yet).
which is the latest shipped with Ubuntu
Oh, weird, on 24.10 it seems 9.1 is available but not on 24.04: https://launchpad.net/ubuntu/+source/rpki-client But I don't know enough about the Ubuntu packages if that is unusual.
I'll try the nix route (but that's not ready yet).
We'll try to have it ready by Wednesday.
I'm in! Just updated rpki-client to 9.1 on MacOS.
Kartograf version: 0.4.6
Using rpki-client version 9.1 (recommended).
Coordinated launch mode: Waiting until 1724248800 (2024-08-21 11:00:00 -03) to launch mapping process.
Countdown: 1 day(s), 19 hour(s), 13 minute(s), 26 second(s)
Ubuntu 24.10 won't be released until October. I'm running 24.04.
I'm in! Just updated rpki-client to 9.1 on MacOS.
I can do it on macOS too if if nix isn't ready on time.
I just tried it twice between macOS with 9.1 and Ubuntu with 9.0 for the same timestamps. Both times I ended up with different RPKI Data, hash sum
. Could that be due to the version difference? Or perhaps due to wildly different download speed (2 minutes on AMD Ryzen 7950x, 12 minutes on 2019 Intel MPB, the same LAN).
I just tried it twice between macOS with 9.1 and Ubuntu with 9.0 for the same timestamps. Both times I ended up with different
RPKI Data, hash sum
. Could that be due to the version difference? Or perhaps due to wildly different download speed (2 minutes on AMD Ryzen 7950x, 12 minutes on 2019 Intel MPB, the same LAN).
I assume you started both at exactly the same timestamp using the -w flag? Then the download speed would be one explanation or it's one of these "silent conflicts" that I mentioned, so the version difference.
If you produce a map from the just rpki data it would be interesting to see what the diff is. Or you could look at the file tree to see if the difference there is small enough. It's the annoying part of asmap that debugging these things are often pretty time intensive. If you could share your raw rpki data from both macos and ubuntu with the same timestamp then I could try to take a look but I probably won't get it done before we do our run here.
Last but not least, since there is a massive de-dublication of the RPKI data the end result can still be a match. Did you finish the process and receive a different end result as well?
fwiw: fjahr/rpki-client-nix#7
This should be fixed now. nix users please use kartograf 0.4.7, for non-nix users there is no difference to 0.4.6.
This should be fixed now. nix users please use kartograf 0.4.7, for non-nix users there is no difference to 0.4.6.
Thanks!
Using rpki-client version 9.1 (recommended).
I assume you started both at exactly the same timestamp using the -w flag?
Yes
Did you finish the process and receive a different end result as well?
No
but I probably won't get it done before we do our run here.
Let's just wait and see how it goes tomorrow, and then upload stuff where needed.
T-29 minutes til takeoff
$ ./run map -w=1724248800 -irr -rv
--- Start Kartograf ---
Kartograf version: 0.4.6
Using rpki-client version 9.0. Please beware that running with the latest tested version (9.1) is recommend.
Coordinated launch mode: Waiting until 1724248800 (2024-08-21 15:00:00 BST) to launch mapping process.
...
my run errored out with OSError: AF_UNIX path too long
in the merging RPKI and IRR step. Tried rerunning but it didn't finish downloading TALs, so can't rerun the same run. Looking into it.
I finished with the final hash of 4474291b341d9b36a2fb743bfb6c335409d56a2a6d6a184c2c4e13184acaecd2
.
Just finished it with the final hash of 0236b4f8c6e023e3bd201996c49f9f10852be0ca7e5952a4ba26fc1c00b71153
.
0236b4f8c6e023e3bd201996c49f9f10852be0ca7e5952a4ba26fc1c00b71153
Nice, @Sjors and @brunoerg are a match ❤️ 😉
I am probably not going to match with anyone because I am missing a hand full of rpki repositories. I am not sure how that has happened but I have noticed previously the number of fetched repositories is not always consistent. I have opened an issue in kartograf
for this and asked about this at rpki-client
: https://github.com/fjahr/kartograf/issues/19
To give some more details on how I detected this: When looking at my logs you can see Parsing 163900 ROAs
and Result entries written: 401562
, these are suspiciously low number, usually they are >200k and >500k respectively looking at my past runs. So I checked my rpki data folder and saw that I was missing several repository folders compared to my trial run yesterday.
$ comm -3 <(ls -1 ./projects/python/kartograf/data/1724193993/rpki/cache/ | sort) <(ls -1 ./projects/python/kartograf/data/1724248800/rpki/cache/ | sort)
ca.nat.moe/
rpki.arin.net/
rpki.miralium.net/
rpki.sailx.co/
rpki.tools.westconnect.ca/
My final hash: 0236b4f8c6e023e3bd201996c49f9f10852be0ca7e5952a4ba26fc1c00b71153
(which matches @Sjors and @brunoerg).
P.S.: I see I only differed by having one less ROA than both Sjors and brunoerg, but got the same mapping :tada:
I've got the same final hash: 0236b4f8c6e023e3bd201996c49f9f10852be0ca7e5952a4ba26fc1c00b71153
I've got:
< snip >
--- Finishing Kartograf ---
The SHA-256 hash of the result file is: 0236b4f8c6e023e3bd201996c49f9f10852be0ca7e5952a4ba26fc1c00b71153
Total runtime: 10:27:29.130238
--- Finishing Kartograf ---
The SHA-256 hash of the result file is: 0236b4f8c6e023e3bd201996c49f9f10852be0ca7e5952a4ba26fc1c00b71153
Total runtime: 6:38:29.027651
Hi all, thank you for participating is such high numbers. This is awesome! 🥳
Even though there might be still some more results coming in (please still post them if you haven't yet) it looks like 0236b4f8c6e023e3bd201996c49f9f10852be0ca7e5952a4ba26fc1c00b71153
is clearly a winner. I don't think we have ever had that many matches in one run, a good indication that keeping everyone on the same rpki-client
version may be the right way to go for the future.
Can someone who got the matching hash please post their final_result.txt
here? Thank you!
Can someone who got the matching hash please post their
final_result.txt
here? Thank you!
It's too big to attach directly to a comment here (32 MB and limit is 25 MB), but here is a temporary link: [removed].
EDIT: See comment below (https://github.com/fjahr/asmap-data/issues/15#issuecomment-2304588468)
Thanks @dunxen! It works if you zip it, putting it here so you don't have to maintain that link.
Closing this with great success 🥇
@jurraca has opened the PR to add the encoded version to the repo here: https://github.com/fjahr/asmap-data/pull/16 Would be great to get 1-2 more ACKs for verification there!
Thanks again and see you next time 🙂
Run with rpki-client-portable 8.8:
--- Finishing Kartograf ---
The SHA-256 hash of the result file is: 0236b4f8c6e023e3bd201996c49f9f10852be0ca7e5952a4ba26fc1c00b71153
Total runtime: 19:28:46.398949
Next collaborative launch is planned for
1724248800
. Please make sure to use Kartograf v0.4.6 and this time please also try to use the latestrpki-client
version. The run will work with an older version, too, but I would like to test if our success rate can be improved if everyone is one the latest version. This could hint at "silent conflicts" produced by different versions ofrpki-client
. See here for more info on this: https://github.com/fjahr/kartograf/issues/16.EDIT:
nix
users please use kartograf 0.4.7. This ensures you will be on the latestrpki-client
version.