{"id":7874,"date":"2021-09-08T17:12:47","date_gmt":"2021-09-08T17:12:47","guid":{"rendered":"https:\/\/www.use-snip.com\/kb\/?post_type=ht_kb&p=7874"},"modified":"2021-10-04T21:15:24","modified_gmt":"2021-10-04T21:15:24","slug":"ntrip-client-warnings","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/ntrip-client-warnings\/","title":{"rendered":"NTRIP Client Warnings"},"content":{"rendered":"

This article covers the NTRIP Client<\/strong><\/em> sections of the automatic error reporting in greater detail.\u00a0 Instructions regarding how to set the trigger thresholds for the needs for your Caster are provided below.\u00a0\u00a0 The SNIP<\/strong><\/span> NTRIP Caster<\/a> provides a range of automatic error reporting mechanisms to alert both the Caster Owner\/Operator and the NTRIP Clients<\/a> when various detrimental operating conditions occur.\u00a0 A higher level overview of these functional sections is provided in this article<\/a>.<\/p>\n

Overview<\/h2>\n

The logic involved in this section deals primarily with the NTRIP User Accounts<\/a> that connect to your Caster, rather than SNIP<\/strong><\/span> itself or the Base Stations connections (covered in other sections). The initial client connection, using the normal NTRIP protocol<\/a>, may have various errors that prevent a successful connection.\u00a0\u00a0 Some valid client connections become ‘bad’ after being in operation for a while (such as a NEAR stream user who is no longer near any Base Stations, or one that does not report a valid location).<\/p>\n

The normal console reports of these events are modified (to prevent leaking private Caster operating details) and sent to the owner of the User Account (and\/or the SNIP<\/strong><\/span> operator) when the number of failures has exceeded a predefined threshold.\u00a0 A minimum time interval can also be set to prevent re-sending an eMail notice of the failure too frequently.\u00a0 In typical operation the trigger threshold is set to occur (and hence warn the user to correct things) well before the threshold for blocking the IP would be reached.<\/p>\n

So in practice, a recurring connection attempt from a misconfigured device would result in SNIP<\/strong><\/span> sending an initial eMail warning regarding the problem to the account owner after several dozen failed attempts.\u00a0\u00a0 This might be repeated with another eMail after a period of several hours if the condition were to persist.\u00a0 Eventually (after hours or days depending on your configuration choices) the source IP would become banned for the period of time you have set (see the IP blocking<\/a> dialog) and this would result in a somewhat different eMail being sent to inform the owner and informing them when connections can resume.<\/p>\n

This section of the dialog consists of three related logic areas highlighted below.<\/p>\n

\"\"<\/a><\/p>\n

Each functional area can be enabled \/ disabled<\/em> by checking \/ un<\/strong>checking<\/em> the associated check box.\u00a0 Each SetUp<\/strong> button brings up a control dialog where the threshold behavior of that function can be set.\u00a0 For this group of functions the triggering moment is related to when the NTRIP Client connection occurs. Every time an NTRIP Client connects the logs are checked for prior connections and any limits which have been exceeded before sending a warning eMail out.\u00a0 The Run button causes a summary report to be created. The Run Now<\/strong> button (at the bottom of the dialog) can be used to process all the active functions and send a report.<\/p>\n

Each functional area is discussed in turn.
\n<\/a><\/p>\n

General Connection Issues<\/h3>\n

This area deals with the most common NTRIP Client connections problems.\u00a0 Issues such as using the wrong password, capitalization problems, NTRIP Revision (Rev1 vs Rev2<\/a>), missing or incorrect mountPts, and violating various User Account restrictions<\/a> are all handled here.<\/p>\n

The setup dialog allows you to set the number of bad connections which must occur before eMail is sent (in the spin box).\u00a0 You can also set how often another email wold be sent to any connection which continues to make this error (in the combo drop down).\u00a0 You can also CC the operator (or not) on these emails.<\/p>\n

\"\"<\/a><\/p>\n

Aside<\/strong><\/span>: Note that sending private account details to the owner of record (who should already have this information) by way of the SSL\/TLS secure eMail socket on SNIP<\/strong><\/span> is in fact more secure than the security offered by NTRIP process itself.
\n<\/a><\/p>\n

Client IP Blocked Events<\/h3>\n

This area deals with processing out an eMail when the offending IP has just been blocked.\u00a0 The actual thresholds for blocking are set in the IP blocking<\/a> dialog.<\/p>\n

The setup dialog does not allow you to set the number of bad connections which must occur before eMail is sent.\u00a0 This value is set in the IP blocking<\/a> dialog.\u00a0 The only option provided is that you can CC the operator (or not) on these emails.<\/p>\n

\"\"<\/a>
\n<\/a><\/p>\n

NEAR Connection Issues<\/h3>\n

This area deals with additional needs and requirements that NEAR connections have that other stream types<\/a> do not.\u00a0 Unlike a single Baseline connection, each NEAR stream<\/a> requires the rover (the NTRIP Client) to provide an estimate of its gross location which is then used (by SNIP<\/strong><\/span>) to select which Base Station they will receive a corrections stream from. These locations are in the form of NMEA-183 $GGA<\/a> sentences.\u00a0 Each time such a sentence arrives for a user, the Base Station assignment is reevaluated to always provide the most effective solution for that specific user.\u00a0 A number of connection issues can arise from this that are dealt with here including:<\/p>\n