Is there a way to get notified when the probe loses IPv6-connection?
The way it is done at the moment isn’t satisfying me.
Just messages, no email notification.
Your probe … was automatically tagged as “system: IPv6 Doesn’t Work”
Your probe … was automatically tagged as “system: IPv6 ULA”
I think it is a failure, if my router switches from dualstack to single stack ipv4 after a reconnect.
But the atlas probe should not accept that.
Or should I disable IPv4 in general for my probes? Would be sent notifications about lost ipv6-connectivity then?
You are not getting the disconnect email because the reconnect happens within the time set for the notification. The shortest available time for the disconnect email to be sent is 10 minutes currently.
We could send a notification on every disconnect and connect but this could potentially lead to a lot of emails being sent if your probe’s connection is unstable. We might make this available though if there is enough demand for it.
Alternatively, we could send emails on tag changes but this would have even more of a delay, generally around 4 hours.
And yes, if you disable IPv4 for your probe completely, if the probe disconnects from IPv6, then after 10-30 minutes the disconnect email will be sent.
That would be a nice alternative for me. At the moment I miss notifications about the ipv6 connection failures or I see it very late.
Of course it would be better if the router tries it again, but unfortunately the router software has the same opinion about “being connected” .
A single mail is sent by RIPE after 10 minutes when it detects a probe as disconnected. We should have the option to have an email sent each week; notably if there was a configuraiton failure after a firmware update, or other problems in your infra; taking action 3 months after the failure, when the probe is marked “abandoned” in your database even if it was online continuously, and was rebooted multiple times.
For now RIPE hardware probe contain no diagnostic tool we can use locally to get more info, all we have is just 2 leds on the Ethernet port, and one (internal) RED led near the USB port, and we can just ping it with IPv4 and IPv6 without any issue detected.
The firmware should embed a small telnet or https server reachable from the LAN, displaying a summary status, or with some commands to display some internal logs (just like in most smartTV firmwares, or in internet routers). You’re not required to install a full generic HTTP server. Such internal plugin can be extremely small but would be helpful (and you should be able to use it privately via some secure connection to get status and some logs (and it should work most of the time as soon as we confirm that the probe is visibly connected to our IPS router, and ICMP-pingable from the LAN and the net.
I do not request a full access to its administration shell (I know this could be risky if probes are targeted by malwares, but as probes are already used by remote accesses to perform tests and report results, it should already embed everything necessary to secure these legit accesses and avoid infections by remote malwares trying to harvest them).
The hardware probes don’t provide local services (HTTP or otherwise) by design, which helps reducing the attack surface against them, thereby keeping them safer. I’d recommend running a software probe if you’d like to watch what’s going on in there precisely - the code for those is exactly the same and in this case you have access to all the details and logs on your own machine.
I canot run a “software probe” due to the dedicated hardware requirement and cannot pay for just that; in addition using a classic PC on the long term for tat takes space, and too much energy; small probes that you provide are much more efficient. However I don’t understand your rationale about not running ANY kind of local service on your probe, given that it already features everything for the networking protocol stacks and has all the necessary API implemented and functional in the OS, at least on the Ethernet port (I don’t know if you use any kind networking on the USB port or if it is just just for powering).
You don’t need to support advanced queries, and complex HTTP(S) libraries for this service, which is very basic. The exposition surface (the networking stacks) is necessary already exposed on the IP socket APIs (at least TCP and UDP), so implementing a telnet-like monitor accepting any basic “1-character” command would just be enough without needing to control how the probe works, but just to show some basic status and statistics.
Eventually if you fear an attack from the Internet, targetting this service, may be this could be implemetned on the USB port. However I doubt it: all probes need to receive data and parse them, at least to perform their tests and counting incoming bytes and datagrams, and timeing them, but as well to perform DNS resolution, connect to controlers, and getting controls from them, including for downloading their sofwate updates, or for its local DHCP requests. So you could just accept this small monitoring function only from a local Ethernet segment (may be only with IPv6): a single socket, parsing 1-character command and sending basic textual response. In addition this service may be configurable (tuned on/off) from the online RIP NCC account, so that you still have control on it in case it really could harmed. My opinion is that all the rest of the probe functionalities will be much easier to attack than such a very basic service. If that monitoring service is attacked, this very likely that all the rest on functionalities are attacked (using many TCP and UDP ports, and complex compression, encryption and all possible bugs on the Linux OS, its hardware drivers, timers, CPU/cache bugs, IP fragmentation and packet sizes, PKI certificates for SSL to various tested domains…).
Please note you don’t need to have a dedicated hardware to create a software probe, the package can co-exist on an existing Linux machine that you use for other reasons.
Thank you for your suggestion on a local service. As with everything, complexity creeps in very quickly - think of the need for authentication and ACLs, the increased attack surface, what this exposes and to whom etc.
the need for authentication and ACLs is not demonstrated at all. And in fact I do not request anything that would expose a usable facility that would change how the probe would run. You just need a few lines of C or Python to listen a specific independant port, and process very basic incoming commands limits to one character (not complex to parse and easy to do safely, just to expose the basic status of the probe). This will in fact expose much less things than what is already visible in the online RIPE database and personal accounts, with timed statistics for precise targeted tests. We don’t need to expose any personal data and this facility can be even restricted by allwing connections only from the local network segment. There’s much more things exposed by the internet router on which we connect it! That service does not need to format the results into HTML, a plain-text only ouput would be sufficient, it would not use much memory (much less than what is used by targeted tests performed by the probe itself). All that it needs to expose is some local perfomance metrics and boolean variables, that are already used internally by all existing targetted tests that depend on them.