Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayNetwork monitoring is a critical aspect of maintaining the health and functionality of any IT infrastructure. You need to be sure you can get quality tech support when you need it.
Let's review a recent conversation between a DPS Telecom engineer, Richard, and a client from outside the US. As we analyze their conversation, we'll highlight some common remote monitoring issues and effective solutions.
Client: Good day. We're [a full-service telecommunications provider from outside the US]. We're having trouble connecting to our T/Mon's web interface. We're seeing an error message.
Richard: We have a hotfix for this issue. Would your email be a good email address to send the hotfix to?
Client: Great, thank you. You can email me.
Richard: Ok. I'll send you an email with the hotfix and instructions on how to install.
Client: Thank you very much. The browser I am currently using is working without issue. They are having issues through Chrome and Firefox.
Richard: The issue is caused because Firefox and Chrome have both dropped support for TLS 1.0 and TLS 1.1, two old encryption styles, in their most recent versions. T/Mon Fedora systems, like the one you likely have, do not support the newer TLS 1.2 and 1.3 which have become the standard. We do have new CentOS and Redhat systems that support TLS 1.2, but upgrading from Fedora may require a more involved hardware upgrade as well, depending on when you got your T/Mon. Older versions of Chrome and Firefox should still be able to browse to the T/Mon without problem, while up-to-date versions will see the error you saw.
Client: Ok, great. Thank you for the information regarding this. I have received the email and will follow the instructions to install the hot patch and have the users try to log in again.
Richard: Sounds good.
Client: To upload the patch for the T/Mon, do I have to upload the .tar to the URL or do I need to extract the files first from the .tar.gz?
Richard: Upload the .tar.gz.
Client: Ok, thank you. The upload was successful. I will notify the personnel to try to access the T/Mon again. Thank you for your support. I will reply via email once they have had success.
Richard: No problem. Have a nice day! Let me know if there's anything else I can help with.
...
Client: Good morning. I am having two issues with equipment on our DPS network and would like to have some assistance.
Richard: How can we help?
Client:
- The T/Mon server is giving a notice on the login screen saying no resources available.
- One of the NetGuardian nodes reported a series of false alarms on February 10th and 11th. The alarms were shown on the T/Mon. I cannot go back that far on the NetGuardian to see if the alarms came from the node. I did check another network at the same location for that time and did not see any alarms.
Richard: The No Resources available message is due to using all of the REMOTE ACCESS jobs by users logging in. You can have up to 34 active logins at a time by setting all jobs 30-63 as REMOTE ACCESS with type HTTP. This limit is removed in the latest software (v1.3A22.1107). What is the T/Mon serial number?
Client: Ah ok. This is the information for the primary node which I am currently using. Thank you very much. My manager said that he will look into the matter.
Richard: You or your manager can also call in to our 1-559-454-1600 number as well if that's easier. We are in Pacific Standard Time. Our office hours are 7 am to 6 pm PST. Okay, sounds good!
Client: Thanks very much for the information. I will forward the contact information to him once it is required.
Richard: Okay, great! Once that is done, I can send out the updated software.
Client: Great, not a problem.
In a recent conversation, our client reported seeing an error message during the login process on their T/Mon master station.
"Good day. A user contacted me regarding an error message they are getting when trying to log into the T/Mon."
Having a solid background with in-depth experience, Richard had seen this issue before. Ready to send over the hotfix solution for this issue, he asked for the client's desired contact information:
"We have a hotfix for this issue. What would be a good email address to send the hotfix to?"
We were able to solve this one very quickly. This interaction demonstrates Richard's preparedness for the situation, showing his ability to solve unique end-user issues.
At DPS Telecom, we dedicate a significant part of our support efforts to helping clients extend the lifespan of their products. As technology continues to evolve, your needs and challenges also change. We don't just "fix" problems. We empower you to adapt and optimize your existing DPS equipment as new technologies and industry trends emerge.
The client specified that they only had this login issue when using Chrome or Firefox. Richard noted that this issue is related to older TLS versions and whether or not they are supported by the browser:
"The issue is caused because Firefox and Chrome have both dropped support for TLS 1.0 and TLS 1.1, two old encryption styles, in their most recent versions. T/Mon Fedora systems, like the one you likely have, do not support the newer TLS 1.2 and 1.3 which have become the standard. We do have new CentOS and Redhat systems that support TLS 1.2, but upgrading from Fedora may require a more involved hardware upgrade as well, depending on when you got your T/Mon."
Richard explains that the outdated TLS versions are no longer supported by modern browsers. This can create the need for an upgrade to newer systems that support the latest security protocols. In this case, installing a software "hotfix" was a reasonable workaround for any organization working within a secure network where HTTPS was not a necessary additional layer of security.
Our client also noted an issue with their T/Mon server displaying a "no resources available" message on the login screen. Richard responded by explaining the cause of this message:
"The 'No Resources Available' message is due to using all of the REMOTE ACCESS jobs by users logging in. You can have up to 34 active logins at a time by setting all jobs 30-63 as REMOTE ACCESS with type HTTP. This limit is removed in the latest software (v1.3A22.1107)."
This explanation clarifies that the system is currently maxed out on remote access sessions. By adjusting the job settings or updating the software, the issue can be resolved. Doing so allows more users to log in simultaneously.
T/Mon systems, like many other network monitoring tools, have a limited number of concurrent login sessions available. When all sessions are in use, additional login attempts will be denied. This results in the "no resources available" error.
This issue is often more severe in large organizations with multiple users needing simultaneous access to the monitoring system. Richard recommended the client configure the system to allow more concurrent sessions and upgrade to the latest software version. This configuration removes the limitation altogether.
This solution addresses the root cause by expanding the session capacity and leveraging the benefits of the latest software.
Again, this situation is evidence of T/Mon continuing to evolve to suit your needs. As DPS has grown our client base to include household-name mega-companies, we've added support for more concurrent users.
Another issue reported was a series of false alarms from one of the NetGuardian nodes. False alarms can lead to unnecessary panic and wasted effort. This impacts the efficiency of network operations. Our client stated:
"One of the NetGuardian nodes reported a series of false alarms. The alarms were shown on the T/Mon. I cannot go back that far on the NetGuardian to see if the alarms came from the node. I did check another network at the same location for that time and did not see any alarms."
Troubleshooting steps for a problem like this would include analyzing the source Port and Address to identifying which NetGuardian RTU actually sent the message. It's important to remember that NetGuardian alarm logs, although they have grown over the years, are medium-term data buffers. It's expected that their limited storage capacity will "wrap" within days, weeks, or months. The timeline varies based on your alarm activity. Fortunately, T/Mon's abundant storage and explicit addressing means that history data stored in the NetGuardian is not necessary to trace mysterious alarm events.
At DPS Telecom, we understand the complexities of network monitoring and work to give you solutions that address these challenges effectively. From ensuring reliable alarm notifications to managing multiple protocols, our products and expertise help you maintain the integrity and reliability of your network.
For more information, or to speak with a DPS Telecom engineer, contact us at 1-800-693-0351 or email sales@dpstele.com. We're here to help you maintain the reliability and security of your network.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
