Information and Support

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

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.

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 :)