This article covers the various errors and reporting message that can occur when SNIP is operating in a closed mode such that every new user (every NTRIP Client) must present a valid account and a password in order to log in.

If SNIP is operating in a open mode, the messages described here will not apply.  Under open mode connections all a user (an NTRIP Client) needs to do is request a mountPt that matches to those in the current Caster table. A similar article dealing with the general debugging of client connections (operating in the open mode) can be found here.

It should also be noted that MountPt strings are always case sensitive.

Background Article

Adding new users is covered in general terms in this article.   This article may be of use in understanding how to operate the various console filters which SNIP provides.  Effective filtering is of great benefit when trying to debug a problem connection in the presence of many other server events in the log.

Closing the SNIP Caster

The critical check box Allow Anonymous access for Users which is used to enable or disable the open/closed mode of the SNIP Caster is described in this article.

Watching User Connections as they Occur

The console log can be used to view each NTRIP Client dialog as it occurs.  The critical check box to enable this is to set Display New User Connection Details which found on the Caster and Clients tab.  Be sure to also set the Log threshold to “minor” and enable client message types in order to see these details.  When checked, after each connection is processed, a report of its outcome is presented in the console log. Additional analysis details are provided when the Caster is closed and the connection attempt failed.

A Typical NTRIP Client connection

Looks like the below when all goes well. In these examples we presume that we have created an account set up with the credentials of:   user:password   (all lower case).  When the user:password pair sequence is sent, they are encoded in a Base64 format.  The NTRIP Client will connect to a mountPt which is called:  MOUNTPT

[C56]: Client [#C56] appears to an NTRIP Client connecting with:
[C56]: An NTRIP Client sent: ======================
[C56]: 
GET /MOUNTPT HTTP/1.0
User-Agent: NTRIP RTKLIB/2.4.2
Authorization: Basic VXNlcjE6bm9uZQ==
[C56]: ======================
[MOUNTPT]: Mount Pt [ MOUNTPT ] is a match - allow connection IF credentials match a user entry.
[MOUNTPT]: Credentials for user accepted.
[MOUNTPT]: Client #C56 [69.75.31.227:61916] Connected to MOUNTPT at 05:45:33 PM (local)

When a problem occurs, the analysis details explain what was found and what it likely means (corrective action).  Resolving the problem may mean a change in what the NTRIP Client device sends, or it may mean that you (as the SNIP operator) must adjust the table entry for this user.

A missing user:password

[C57]: Client [#C57] appears to an NTRIP Client connecting with:
[C57]: An NTRIP Client sent: ======================
[C57]: 
GET /MOUNTPT HTTP/1.0
User-Agent: NTRIP RTKLIB/2.4.2
Accept: */*
Connection: close
[C57]: ======================
[MOUNTPT]: Mount Pt [ MOUNTPT ] is a match - allow connection IF credentials match a user entry.
[MOUNTPT]: No credentials were extracted from request (Caster is closed), Disconnected.
[MOUNTPT]: Client #C57 [69.75.31.227:62002] Disconnect from , 89 Bytes in, 967 Bytes out, Connected: 006 mSec

This article has served to summarize various connection problems that can occur when NTRIP Client log onto SNIP and how to recognize and correct them.

[SCSC02]:  Client #C01 [69.75.31.228:60021] Connected to SCSC02 at 11:10:06 AM (local)
[C02]:  Client #C02 [69.75.31.228:60022] Disconnect (NO mountPt was provided), 102 Bytes in, 959 Bytes out, Connected: 054 mSec

[SCSC02]:  Client #C01 [69.75.31.228:60021] Connected to SCSC02 at 11:10:06 AM (local)

[C02]:  Client #C02 [69.75.31.228:60022] Disconnect (NO mountPt was provided), 102 Bytes in, 959 Bytes out, Connected: 054 mSec