Most times, you'll know if even your own local gateway goes down but a lot of that has to do with how a network is set up.

Some folks have multiple internal devices like a wireless router connected to their own router which is then connected to their providers.

There is no way for the agent to know these things so to us, it's expected to work on a 'traditional' network which is usually the providers router/modem only.

That said, for companies that do have multiple internal gateways, we have a feature we can manually enable that tells the reports side where the local network ends and where the provider starts otherwise, those folks get reports of the LAN being down when it's actually the provider or vise versa.

Hard to have a tool that does it all automatically but we keep working on it :).

@kmichailg

Yes, this confirms the change we decided to apply: we want to avoid cookies usage in the login phase at least.

That error is the effect of that change.

Please inform of any other situation where the login for some reason is affecting the normal behavior of the app

@7thlensinc
I confirm from a technical standpoint that the temporary code was to allow you to associate that specific hardware to your account.

The activation code is gone and all things are working fine from our perspective

@markl

Hi there,

This post seems to have been missed.

The choice is really up to you. There isn't anything to hack on the agents but as usual, when you put something directly on the Internet, it becomes a target for hackers.

Yes, absolutely, you could install another little router outside the MSP's device then connect your agent to that so long as the upstream is providing DHCP.

Let me know if you have any more questions, I'm sorry this was missed and happy to help in any way we can.

@johnmeyer My suggestion would be to keep monitoring to see if you can find a pattern since it's different from when this question started.

Once you spot something, post a new question with those details and maybe we can offer a little insight.

If you don't see an outage report, it's because it's not an IP problem, it's something else. That could be anything from signals levels to bad cable.

This can help to explain.
About Internet outages, alerts and agent statuses

Ok, well, based on everything you've told me, the problems are no matter if you are using wireless or wired and directly connected to the providers router.

Your next task would be to check the signal levels on your providers router. Most, if not all cable routers will have a status page showing signal levels. You just need to look up the info for your own device and how you log into that. Most times, it's a default admin/admin login since there's nothing to config, just view.

As your LAN IP for the device you have the agent running on is 192.168.0.x, then your router access should be either http://192.168.0.1/ or https://192.168.0.1/

Can you see a status page if you go to this IP from something inside your house? If so, if you need to log in, you'll have to dig on the net for default login credentials.

Your input suggests that either the router/modem is suffering signal loss or its at the street level coming into your house.

If you ask neighbors if they also experience such problems, then it will likely mean that the providers local device serving others in your neighborhood is having a problem.

Providers will usually never admit to problems outside your home unless others are complaining or it's very obviously affecting your own service.

We have many experiences where we've told the provider exactly where the problem was but they would barely acknowledge our information or flat out deny it. Later, services mysteriously get better.

Here's a great example of such a story.

Our local Internet provider would not admit it

If you can confirm signal levels, then contact your provider and ask them to look at the signal levels on your router/modem. If they tell you it's fine and the problems continue, you could ask others in your area to also use OutagesIO and then we could help you confirm issues are affecting others and you could post on their social pages.

OutagesIO is just a tool, it cannot solve the problems of course but it gives you the information you need to get your provider to get things fixed. Like all tools, you use all peices of information together to come to a conclusion.

Hope all this helps.

@SBK Unfortunately, my extended subscription has expired, so I can no longer check it. Will renew again and let you know.

@SBK Thanks Ed. Funny we mentioned the lower prevalence of runtime bugs in code written in the functional programming paradigm, then a runtime bug happens, what are the odds?

Aside from this little hiccup, the service has been great though. Appreciate the quick fix.

@OutagesIO_Support Hi, yes I was testing it. Will probably create a post for my testing.

@claytonbcollins said in Can't delete Agent:

129098 and switch the Extended service to 129112,

Done
Please confirm all is ok and let me know if you could change the address

@OutagesIO_Support
Never mind. I searched for that command you suggested, "ps cax | grep otm_binary", in the forums and saw it mentioned to run the script, "sudo ./starter.sh". And now I'm back up and running!

Thanks!
Clay

@claytonbcollins

Hi,

Yes, we are already testing a new version that is going to include also the upload speed test.

I cannot give a precise time-frame yet but definitely we want to get there too :-)

@markl
Done

@SBK
Yes, it says "Export date: Jun 9, 2022, 4:26:43 PM" but it was 7:26pm.

@Laguy442

Yes correct

Those "missing" ping are just a possible problem in the connection

If your router disconnects for those 2 min and 22sec then you have already the answer but lets wait a bit to see how much data is stored and what you can see from the dashboard

@SBK No matter if it's the primary WAN is up or not, 192.168.0.1 always remains up even during the failover or failback process. I verified this in my first post.

That's why I said the agent reports something incorrect, because it reports that 192.168.0.1 is down when actually 192.168.1.1 is down.

@markl

Hi Mark,

I recall during the tests we made that if the agent was connected to one network the speed tests were coming in correctly while connected on the other one they didnt.

Is this the situation?

So how is it going? Did you figure it out?