Turris SW probe - long time to connect
Hello, Since this week based on report [1], [2] from Martin we were able to observe his issue, which he reported and by using Atlas SW Probe 5010 and older, we noticed that in CLI probe is running and that it is doing something, but on the RIPE website, it shows that probe is disconnected. Can you please check probes IDs (1000585, 1000243) and what it took so long to show that it is connected? Both of those probes were shown as connected at the same time - 20:22) on Tuesday? We noticed that in some cases if you were using the latest version 5020 and register a new probe, it is working within a few minutes. However, we pushed to all our Turris OS version updated Atlas SW Probe to version 5020 and some of our users noticed similar maybe the same behavior. A probe was running on the router, but it was disconnected for almost an hour (probe ID 1000036) The router is working in all cases, ping, dig connection is OK. I'm wondering if this issue isn't on server side. In reg_init_reply.txt were following data: WAIT TIMEOUT 115 Do you know how to debug it more? [1] https://forum.turris.cz/t/turris-os-5-0-0-is-released-in-hbt/12733/149 [2] https://github.com/RIPE-NCC/ripe-atlas-software-probe/issues/38 Looking forward to hearing from you, Jan
Hi Jan, On 2020/06/04 17:01 , Jan Pavlinec wrote:
Can you please check probes IDs (1000585, 1000243) and what it took so long to show that it is connected? Both of those probes were shown as connected at the same time - 20:22) on Tuesday? We noticed that in some cases if you were using the latest version 5020 and register a new probe, it is working within a few minutes.
In reg_init_reply.txt were following data: WAIT TIMEOUT 115
Do you know how to debug it more?
In general, this means that the probe was refused due to a temporary problem. There are two ways this can happen. One is that the probe is doing something wrong, for example connecting way too often. The other is that there is an issue on our end. There is no reason to worry about network connectivity in the case. I checked probe 1000243 and in this case there was something weird going on on our end. I'll try to figure out what is happening. Philip
Similar issue here at the moment with probe 1000331; 5020 Centos 8 repo build; On Fri, 5 Jun 2020 at 01:21, Philip Homburg <philip.homburg@ripe.net> wrote:
Hi Jan,
On 2020/06/04 17:01 , Jan Pavlinec wrote:
Can you please check probes IDs (1000585, 1000243) and what it took so long to show that it is connected? Both of those probes were shown as connected at the same time - 20:22) on Tuesday? We noticed that in some cases if you were using the latest version 5020 and register a new probe, it is working within a few minutes.
In reg_init_reply.txt were following data: WAIT TIMEOUT 115
Do you know how to debug it more?
In general, this means that the probe was refused due to a temporary problem. There are two ways this can happen. One is that the probe is doing something wrong, for example connecting way too often. The other is that there is an issue on our end.
There is no reason to worry about network connectivity in the case.
I checked probe 1000243 and in this case there was something weird going on on our end. I'll try to figure out what is happening.
Philip
On 2020/06/06 7:46 , Mick O'Rourke wrote:
Similar issue here at the moment with probe 1000331; 5020 Centos 8 repo build;
The problem was the following: we have limits on controllers for how many probes they can handle. We failed to notice that we now have more software probe than configured by the limits. The limits were set very conservatively, so we just raised them and the problem should be gone now. Thanks to everyone who reported this. Philip
participants (3)
-
Jan Pavlinec -
Mick O'Rourke -
Philip Homburg