Hi Ernst, Sorry to hear you are having issues with installing the probe software. Can you maybe provide a step by step instruction how you got to the yum atlasswprobe error? I would like to check that everything is ok on our end. Secondly, regarding the bandwidth problems, can you explain what kind of issues you experience in non-bridged modes? What have you tried, and what was the result? Traceroute is known to work through NAT connections, which is typically what hypervisors use to share the connection (if bridging is not used). On your OpenWRT probe installation attempt, it seems there are 2 versions in the field; A version maintained by RIPE NCC used solely for the hardware probes. A community package written by the OpenWRT community, which uses the software probe implementation You mentioned having startup problems with the telnet daemon on the OpenWRT community package, I cannot say why this is, but the most likely culprit is the software not being able to find the location of the binary. Do you get any errors during startup? On a Windows implementation, there has not been a decision to do so as yet, I’m not sure whether the raw packets that are sent by the various measurements would work with Windows, but to be honest, this has not been investigated. Can you explain your use case for a Windows based implementation? Regards, Michel
On 2 Jul 2022, at 19:23, Ernst J. Oud <ernstoud@gmail.com> wrote:
Don’t know whether this is the place to share experiences but …
I installed a SW probe in Docker for Windows (the Alpine version). Turns out traceroute doesn’t work in that setup. So I installed VMware player on that PC (the latest version can coexist with Hyper-V which Docker requires) and CentOS and the binary of the probe. Of which the instructions on the Ripe Atlas site doesn’t work in the last step (yum complains no package atlasswprobe found in the repo). Manual download and install did work however. Hurrah.
Turns out traceroute in that setup only works with VMware in bridged network mode. Fine. But… all my bandwidth tests on that same box suddenly showed strange impacts… so either a working probe and accept incorrect bandwidth tests (using Ookla SpeedTest) or find another solution. Apparently the bridge in VMware and Windows on the same physical Ethernet port influence each other.
Tried the probe on OpenWRT on a small router. Works fine but I don’t want to dedicate this router to just probe work. Also the ATLAS service from init.d refuses to run the telnetd daemon at startup. Weird.
So installed VMware on a separate Windows 10 headless box (Minix Z83) that I had spare with CentOS and the binary. Runs fine. Finally.
Will kill the other two probes once I am convinced it now finally works.
Thanks Ripe for this excellent tool! A Windows version would help however :-)
Regards,
Ernst -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas