This article covers the NTRIP Client sections of the automatic error reporting in greater detail. Instructions regarding how to set the trigger thresholds for the needs for your Caster are provided below. The SNIP NTRIP Caster provides a range of automatic error reporting mechanisms to alert both the Caster Owner/Operator and the NTRIP Clients when various detrimental operating conditions occur. A higher level overview of these functional sections is provided in this article.
Overview
The logic involved in this section deals primarily with the NTRIP User Accounts that connect to your Caster, rather than SNIP itself or the Base Stations connections (covered in other sections). The initial client connection, using the normal NTRIP protocol, may have various errors that prevent a successful connection. 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).
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 operator) when the number of failures has exceeded a predefined threshold. A minimum time interval can also be set to prevent re-sending an eMail notice of the failure too frequently. 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.
So in practice, a recurring connection attempt from a misconfigured device would result in SNIP sending an initial eMail warning regarding the problem to the account owner after several dozen failed attempts. This might be repeated with another eMail after a period of several hours if the condition were to persist. 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 dialog) and this would result in a somewhat different eMail being sent to inform the owner and informing them when connections can resume.
This section of the dialog consists of three related logic areas highlighted below.
Each functional area can be enabled / disabled by checking / unchecking the associated check box. Each SetUp button brings up a control dialog where the threshold behavior of that function can be set. 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. The Run button causes a summary report to be created. The Run Now button (at the bottom of the dialog) can be used to process all the active functions and send a report.
Each functional area is discussed in turn.
General Connection Issues
This area deals with the most common NTRIP Client connections problems. Issues such as using the wrong password, capitalization problems, NTRIP Revision (Rev1 vs Rev2), missing or incorrect mountPts, and violating various User Account restrictions are all handled here.
The setup dialog allows you to set the number of bad connections which must occur before eMail is sent (in the spin box). 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). You can also CC the operator (or not) on these emails.
Aside: 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 is in fact more secure than the security offered by NTRIP process itself.
Client IP Blocked Events
This area deals with processing out an eMail when the offending IP has just been blocked. The actual thresholds for blocking are set in the IP blocking dialog.
The setup dialog does not allow you to set the number of bad connections which must occur before eMail is sent. This value is set in the IP blocking dialog. The only option provided is that you can CC the operator (or not) on these emails.
NEAR Connection Issues
This area deals with additional needs and requirements that NEAR connections have that other stream types do not. Unlike a single Baseline connection, each NEAR stream requires the rover (the NTRIP Client) to provide an estimate of its gross location which is then used (by SNIP) to select which Base Station they will receive a corrections stream from. These locations are in the form of NMEA-183 $GGA sentences. 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. A number of connection issues can arise from this that are dealt with here including:
- Never sending any GGA sentences at all.
- Sending a location that is outside of the service area of the requested NEAR stream.
- Sending a location that is full of null content (location zero zero).
- Sending a location that has just moved to outside of the valid service area.
- Sending other unwanted NEMA-183 content.
The setup dialog allows you to set the number of bad connections which must occur before eMail is sent. You can also set how often another email wold be sent to any connection which continues to make this error. You can also CC the operator (or not) on these emails.
Typical Examples of use
Here we provide two common NTRIP Client connection problems as examples of use.
- An NTRIP Client Connection with a bad user password
- An NTRIP Client Connection requesting a nonexistent MountPt
NTRIP Client Connection; with a bad user password
Consider a Caster where an otherwise valid NTRIP Client user account has mangled the assigned password it should use.
In this example we have created a User Account called “aTestUser” and assigned it a password of “ThePassword” (note the capitalization). This User Account is owned by a Customer Account with the email <dummy@use-snip.com> associated with it. The method of using a valid email for the user account could also be employed here. [Aside; the below value “YVRlc3RVc2VyOnRoZXBhc3N3b3Jk” below is the Base64 encoding of “aTestUser:thepassword”]
When the connection occurs, the SNIP console log provides the normal summary details of the connection event to the operator. The in-line hyperlinks (disabled here) allow exploring both the the IP used and the Base Station requested in greater detail in the document viewer when desired.
[C046]: New Client [#C046] appears to an NTRIP Client connecting, Wed 09:25:40 AM (local), from 192.168.2.105:13242 with: [C046]: An NTRIP Client sent: ====================== (115 chars) GET /RTCM3EPH HTTP/1.0 User-Agent: NTRIP RTKLIB/demo5_b33b2 Authorization: Basic YVRlc3RVc2VyOnRoZXBhc3N3b3Jk =END= [RTCM3EPH]: Mount Pt [ RTCM3EPH ] is a match - allow connection IF credentials match a user entry. [RTCM3EPH]: Credentials for user [aTestUser] did not match any suitable entry, [RTCM3EPH]: User Login Attempt Failed, details follow. Analysis of User: aTestUser and PW: thepassword connection failure is: Existing user entry, but incorrect password used Provided [thepassword], Expected [ThePassword] (good user, bad password) Check for a capitalization error or a sub-string mismatch. [eRpts]: An eMail regarding the failed User connection attempts was sent to: Dummy <dummy@use-snip.com> [CC to Caster admin] [RTCM3EPH]: Client 'aTestUser' #C046 [192.168.2.105:13242] Disconnect (tried to mount RTCM3EPH, using bad credentials), 115 Bytes in, 1.26 KB out, Connected: 026 mSec
The above console log entry shows the moment the eMail was triggered, after several prior failed connection attempts. The number of prior events needed is set by the trigger threshold described above. The body of the eMail which is then sent to the owner of the account (and may be CCed to the SNIP operator) is shown below. Note that key information needed to correct the problem is presented (for the account owner or for the tech support use), but additional details about the Caster itself is not provided (such as the connection numbering).
Dear Dummy <dummay@use-snip.com> At this time the User Account aTestUser is trying to connect to Base Station RTCM3EPH but is having problems on the SNIP NTRIP Caster located at 192.168.2.105:2101 (<CasterName> Node). You have been sent this automated email in the hopes the below details will allow you to correct the problem. Below is the log entry from the last connection. This has now occurred 30 times in the recent past, which triggered this email to you. You may need to consult your last reservation eMail to confirm that the credentials are correct. Connection Transcript Log: User Login Attempt Failed, details follow. Analysis of User: aTestUser and PW: thepassword connection failure is: Existing user entry, but incorrect password used Provided [thepassword], Expected [ThePassword] (good user, bad password) Check for a capitalization error or a sub-string mismatch. Please correct this as soon as possible to avoid having your IP address blocked by the Caster. Regards, The Support team <CasterName> Node
NTRIP Client Connection; requesting a nonexistent MountPt
Consider a Caster where an otherwise valid user account has request a Base Station (a mountPt) which is not present at the time of the request. It may be that the Base Station is momentary offline, or it may be that the requested Base Station has never been associated with the Caster. The precise console details displayed by SNIP will denote if a requested Base Station was present in the past, indicating that is simply offline at the moment (the phrase “no longer” present versus the phrase “never” present). For this example we use the same user account as above but have disabled the Base Station stream RTCM3EPH. Therefore requests for this stream result in a connection error.
[C033]: New Client [#C033] appears to an NTRIP Client connecting, Wed 11:05:56 AM (local), from 192.168.2.105:14254 with: [C033]: An NTRIP Client sent: ====================== (115 chars) GET /RTCM3EPH HTTP/1.0 User-Agent: NTRIP RTKLIB/demo5_b33b2 Authorization: Basic YVRlc3RVc2VyOlRoZVBhc3N3b3Jk =END= [C033]: No matching mount point, requested: [RTCM3EPH], sending Caster Table and disconnecting. [eRpts]: An eMail regarding the failed User connection attempts was sent to: Dummy <dummy@use-snip.com> [CC to Caster admin] [C033]: Client 'aTestUser' #C033 [192.168.2.105:14254] Disconnect (tried to mount RTCM3EPH, is No Longer in table), 115 Bytes in, 1.11 KB out, Connected: 043 mSec
The above console log entry shows the moment the eMail was triggered, after several prior failed connection attempts. As before, the number of prior events needed is set by the trigger threshold described above. The body of the eMail which is then sent to the owner of the account (and may be CCed to the SNIP operator) is shown below.
Dear Dummy <dummy@use-snip.com> At this time the User Account aTestUser is trying to connect to Base Station RTCM3EPH but is having problems on the SNIP NTRIP Caster located at 192.168.2.105:2101 (<CasterName> Node). You have been sent this automated email in the hopes the below details will allow you to correct the problem. Below is the log entry from the last connection. This has now occurred 50 times in the recent past, which triggered this email to you. You may need to consult your last reservation eMail to confirm that the credentials are correct. Connection Transcript Log: No matching mount point, requested: [RTCM3EPH], sending Caster Table and disconnecting. Please correct this as soon as possible to avoid having your IP address blocked by the Caster. Regards, The Support team <CasterName> Node
Note: If the requested mountPt has been present on the Caster in the past, the reply in both the console and the eMail is modified slightly to show the last time it was present. If the number of bad connections has risen to the point when an IP ban may soon occur (if it has reached 50% of the current threshold), this information is also shown in the console log (but not the eMail).
[C1035]: No matching mount point, requested: [RTCM3EPH], sending Caster Table and disconnecting. However, the stream RTCM3EPH was connected in the past to this Caster. The last connection was: Wed, September 08, at 03:20:03 pm Pacific Daylight Time [C1035]: Client 'aTestUser' #C1035 [192.168.2.105:2215] Disconnect (tried to mount RTCM3EPH, is No Longer in table), 115 Bytes in, 1.12 KB out, CAUTION: The Bad Connections in a Row counter has risen to 725 for this IP, trips past 800 / 500.