[atlas-sw-probes] Merry Christmas and a HTTP 302
- Next message (by thread): [atlas-sw-probes] SW Probe 1000069 issue
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Robert Kisteleki
robert at ripe.net
Thu Jan 2 10:13:53 CET 2020
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 at zajic.v.pytli.cz> > *Datum: *úterý 24. prosince 2019 9:41 > *Komu: *"atlas-sw-probes at ripe.net" <atlas-sw-probes at 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 >
- Next message (by thread): [atlas-sw-probes] SW Probe 1000069 issue
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]