Information and Support

I'm not sure if you've already done this since this post was not updated but the latest version is now; SCRIPT_VERSION="2023-1-26_1050_Phoenix_TZ And you can download it here; https://downloads.echonets.com/scripts/starter.sh Just kill the otm process (as explained above) if it's running, then start over using the new version of the starter. The starter itself will now tell you when there is a new version.

@mshafrin I am assuming that your firewall is also your default gateway, if not then what follows could be incorrect. If I take a look at the hops recorded by all 3 SW agents (not only the one you mentioned) and the only HW agent, you will see that only the HW agent is having the first hop pointing to 192.168.1.1, the other ones go directly to an external IP without passing thru the firewall/gateway. So on one side either the Windows agents or the firewall is masking the direct hops or they are connected in a different way from the HW agent; I also saw that the 130435 was once connected in a different way since it had the same 192.168.1.1 that now doesnt show up again. In the end, what does it mean? If the agent cannot determine where the LAN ends and the provider begins there is no way to give you a correct report about where the outage was and IF it was a network outage or a problem related to cabling (provider's end of cabling). If the firewall is NOT your default gateway then it would be nice to understand a bit more about the LAN topology to help to troubleshoot it but so far I haven't seen a wrong behavior from the agents you have installed.

Thank you!!! All reported times (pings, hops, etc) seem to be spot-on here. You guys are the absolute best!!

Hi, Did you resolve this?

So our Windows dev did some digging and this is what we were told. I've found the reason for the crash this person experienced when installing. If the service fails to start because the Listen() call throws an exception then the exception handler calls Close() and Close() fails to check if the handle pointer is a null reference before using it. What I don't know is why we are not able to start a named pipe on that persons machine. I'll add the missing check to the library code but that won't cure the actual problem they had, so I'll investigate further on what might prevent use opening a named pipe on Windows 10 Pro. I've never seen that fail before. So I don't think we have a general issue here, more likely a restriction configured on that machine or possibly the name we use for the pipe is already being used.

@shahinfard Hi, Please double check that all the settings are now associated to the HW agent.

@outagesio-greenwich-k12-ct-us Hi E.K., Let me try to summarize what I see and lets check together if there is a clear explanation. Lets start with the inventory: 128389, SW agent (Win 10 Pro), OTM version 1.69.2106 128316, SW agent (Win 10 Enterprise), OTM version 1.69.2106 128309, SW agent (Win 10 Pro), OTM version 1.69.2106 128313, HW agent (GLinet MT300N-V2), OTM version 1.67.2104 Upload testing + Latency evaluation is available only from version 1.68.2105 and on the HW version we are still testing so this explains why you are not seeing the uploads on the HW agent: as soon as the testing period is over we will release the latest version and your agent will upgrade automatically. As far as I can see: agent 128309 was able to send proper download/upload/latency from Sep 20th when the version 2106 was installed agent 128316 was able to send proper download/upload/latency from Sep 11th when speed-test was enabled agent 128389 seems to be the tricky one since it started from yday right after 3 am The only thing we noticed is that some old Windows 10 builds were blocking some features of the OTM (the software that does the monitoring) and maybe (it is just an assumption) that pc/server was updated to the latest build. Can you please double check that so I can have a better understanding of this weird behavior?

@sbk Yes its all working now. Thank you for your responce :)