Hi, Thank you for reporting back! It seems useful to have the SSH client log this -- as long as it's not logging too much otherwise. Maybe this can be done with a log level change? The HTTP client could not do much as there *was* an HTTP server at the expected location... We're thinking about a probe tag that would show the user that the probe is connected but not reporting. On the server side we would not know why that is though. Regards, Robert On 2019-12-24 15:51, Radek Zajíc wrote:
Hi everyone,
it’s me again. I just want you to notify that I have identified the root cause of this issue. There was a colliding service listening on port tcp/8080 locally – the UniFi controller (yep, I have installed this on a not-so-important node without isolation, will fix this after Christmas). So it happens that the ssh client fails silently (does not exit, no error was in the RIPE atlas probe logs either) when it’s unable to bind to a local socket to perform SSH forwarding. That’s a weird bug, but it’s really there.
So this is just for you to know, that it’s working for me. I will spend more time with the probe and get back with further feedback.
Thanks for having me and again merry Christmas to all of you.
Cheers,
Radek Zajic
*Od: *Radek Zajic <radek@zajic.v.pytli.cz> *Datum: *úterý 24. prosince 2019 9:41 *Komu: *"atlas-sw-probes@ripe.net" <atlas-sw-probes@ripe.net> *Předmět: *Merry Christmas and a HTTP 302
Hi everyone,
Merry Christmas (or Festive season, if you prefer) and a happy New Year to everyone!
I have just registered my first software RIPE probe. I can see it in my RIPE Atlas probe list. When checking systemd logs, I can see that the probe is registered properly with its control server (which is ctr-fsn01.atlas.ripe.net).
When I ran the first measurement from it, the measurement didn’t show up on the web. I see the following error in the systemd journal:
pro 24 09:36:38 controller ATLAS[8785]: total size in dir: 5668
pro 24 09:36:38 controller ATLAS[8785]: httppost: before getaddrinfo
pro 24 09:36:38 controller ATLAS[8785]: httppost: before connect
pro 24 09:36:38 controller ATLAS[8785]: httppost: sending request
pro 24 09:36:38 controller ATLAS[8785]: posting file '/var/atlas-probe/data/out/ooq/2'
pro 24 09:36:38 controller ATLAS[8785]: posting file '/var/atlas-probe/data/out/ooq/1'
pro 24 09:36:38 controller ATLAS[8785]: httppost: getting result
pro 24 09:36:38 controller ATLAS[8785]: httppost: POST command failed: '302 '
pro 24 09:36:38 controller ATLAS[8785]: httppost: leaving with error
pro 24 09:36:38 controller ATLAS[8785]: ooqd: httppost failed with 1
This conforms to what I see in tcpdump:
POST /?PROBE_ID=1000060&SESSION_ID=34f398cd76888d91da4adb236e00ded25abf69bcf959509b748ad7e84b33c2c8&SRC=oneoff HTTP/1.1
Host: 127.0.0.1
Connection: close
User-Agent: httppost for atlas.ripe.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 5759
P_TO_C_REPORT
RESULT { ... }
HTTP/1.1 302
Location: /manage
Content-Length: 0
Date: Tue, 24 Dec 2019 08:14:38 GMT
Connection: close
The question is: why does the probe (talking via the initiated SSH tunnel at 8080:127.0.0.1:8080) receive such a message from the controller? Is this common or a bug?
O/S: Ubuntu 18.04, amd64
SW probe version: atlasswprobe==5000-1
Thanks for any insight and/or hint.
Cheers,
Radek Zajic