Automatically monitor your Internet service and provider with optional alerts to problems
Monitor your Internet services or devices to ensure they are always online. Tracks Internet connectivity and speeds with useful proof. For Windows, Linux, ARM (Raspberry, Tinker Board, etc).
Learn more by visiting
  • 0 Votes
    1 Posts
    No one has replied
  • 1 Votes
    49 Posts

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

  • 1 Votes
    3 Posts

    Sorry for the long delay, this seems to have been missed.
    The dev asks the following;

    Are you certain there is not already a copy of the service installed and running on that machine? Normally the only reason for a named pipe to fail to listen is if there is already a pipe with that name.

    Can you make sure to completely uninstall the echo networks service if you see it then try again.
    You'll have to use the dashboard to create a new agent if it no longer exists and just follow the directions as before.

  • 1 Votes
    13 Posts

    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.
  • 1 Votes
    4 Posts


    Please double check that all the settings are now associated to the HW agent.

  • 0 Votes
    4 Posts


    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?

  • 0 Votes
    4 Posts


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