The RTK2go Caster is free to use for all parties. But sometime this provides an opportunity for abuse, often caused by an operator mistake, but at times intentional. The below rules are intended to allow RTK2go to be used by a large number of people rather than abused by a few.
The SNIP® node on this RTK2go® site employs the SNIP IP tracking logic to detect and block addresses that continually abuse the machine in an attempt to connects or to attack it. The thresholds are set at a somewhat high level for NTRIP Clients, and the period of the ban is fairly short, as this site often has novice users connecting to it. But thresholds are set at a low level for NTRIP Server connections, as most of the abuse seen is from improperly configured server software trying to send data into the SNIP NTRIP Caster.
A count is kept of the number of “bad” or failed connections seen for every IP address (and every IP & mountPt combination). These values are reset on any successful connection or after a period of non use. If the value grows too large (hundreds of failed connections) the IP is banned for a period of time (or hour or two is typical, but longer times are also used). These are all threshold values which the SNIP operator can set to meet his needs. An aggressive NTRIP Client can get itself banned by attempting to connect once per second for a hour or two. A more normal NTRIP Client might see this after days of trying to connect without success.
In either event, the client will get either an html 40x reply message or an html page back until the banned period has passed at which time its connection will again be processed. In the RTK2go.com site configuration, we send the Caster Table as an html page when non NTRIP Clients connect in the hopes that the connection user will read it and understand what is occurring. This follows the NTRIP Rev1 protocol for bad connections. If a browser connects from a banned IP, an minimalist html page is returned.
The most common cause of this event is benign; it is simply an NTRIP Client trying to connect to a stream that does not exist. If this happens to your device, it indicates you have some fundamental issues with your connection you need to work out. It may be that the Base Station software which sends the data you requested simply need to be restarted.
Helpful Hints: If the NTRIP Client is another SNIP device, and the SNIP2SNIP protocol is enabled on the Caster (in the prefs dialog), the mis-connected Client will receive some additional messages to assist the them to determine what corrective action to take.
The second most common cause is a Base Station device that correctly connects but then never sends any data. After ~12 seconds of no activity, SNIP disconnects these data streams. They then endlessly reconnect and retry (still sending no actual data) until banned.
Devices that are getting repeatedly banned many times for days at a time without any actual useful connections occurring may be added to a longer term ban list. Typicality the offending IP is banned for 7 days before an even longer period is used. Most often this sort of event is from a forgotten base station that is simply not working and needs a reset. We may use the email you provided during the Base Station registration process to contact you in such an event. Please contact us if you suddenly found such an issue in order to have your IP ban reset. In extreme cases, the network firewall is used to block your IP from ever reaching the Caster host machine.
A good way to get your IP banned for longer periods of time (days, to several weeks, to permanently) is to…
…try and reconnect providing bad log-on credentials every second for hours on end. A well behaved NTRIP Client (or Server) backs off the re-connection time interval after a period of several failures. If you do not have an adaptive retry rates (read: RTKLIB derived code), then please set both the timeout and retry rates to be at least 10 seconds (10000 mSec).
…send Base Station corrections at rates higher than 1Hz (without obtaining prior clearance). There is very little use for such data and the improvement in rover positional precision is very slight, if any. Because a 10x increase in rates uses 10x more of the Caster resources, this is not allowed. Please use your own copy of SNIP for this. Sending in way too much data can also get your IP banned, more than 500Mb per day will get the IP banned. Such a level probably indicates your Base Station is not configured right. [There are no limits on how much or how many users (NTRIP Clients) can consume your data]
…send excessive amount of NMEA-183 data or other data which is of no value to the Rover community at high data rates. See also: Base Station corrections at rates higher than 1Hz (without obtaining prior clearance) above. Also note: Rover devices (NTRIP Clients) which send in large amounts of NMEA-183 data (particularly non-GGA data) can also be banned.
… name your Base Station mountPt something considered offensive by others. Or to use the mountPt name field (or any other text field in the Caster Entry) for commercial product or promotional uses. This applies even if the product/service being promoted has something to do with GNSS or RTK. MountPt names like “we_have_the_worlds greatest_GNNS_device” will not be tolerated. [Aside, mountPt names over ~20 chars are strongly discouraged but names up to 100 chars are allowed by the standard] Please download and use your own copy of SNIP or use your own advertising resources for this.
… we see a number of TCP/IP sockets being opened and then no data is ever sent. This abuse seems to relate to the use of RTK2go for product testing (see below) and validation of 3rd party developmental software. This use is not allowed. Please use your own copy of SNIP for this (download here). Abuse of this type could result in the IP being blocked for weeks at a time. Technical details: In order to support ‘slow’ NTRIP devices, SNIP allows ~10 seconds for the initial connection data to flow before disconnecting (longer times can be set when required).
…use RTK2go for product testing and validation on your new NTRIP Client of NTRIP Caster software. This use is not allowed. Please use your own copy of SNIP for this (download here). Abuse of this type will result in the IP being blocked for weeks at a time. With your own private copy you will also see useful notes on the SNIP side explaining what was wrong with a bad connection. If you require professional assistance in developing or validating such software, please contact our support team.
…use RTK2go as a place to connect multiple times and download many data streams at once. This use is not allowed. Abuse of this type will result in the IP being permanently blocked. If you connect to a few streams, that is fine. If you connect to your own streams, that is fine. If you connect to 50+ different streams (which occurred and to caused this rule to be created) expect to be blocked. If you want to do this for research needs, ask first. If you connect to multiple streams in a given region and then attempt to resell them from your own Caster, this use is not allowed. All RTK2go streams are expected be, and remain, free.
…use RTK2go as an attempt to redistribute a data stream obtained from other parties beyond your individual licensed right to use such a stream. See point #1 of the legal consent agreement to use RTK2go. In general you do not have the right to subscribe to a data stream from a private service provider (or goverment provider) and then distribute it to others. Check with your legal advisor to be sure if you think you are exempt from this. Some goverment run CORs networks that do allow this, some do not. We will aggressively block any such abuse.
Several of the above uses can be better supported on our leased machines.
Some organization simply do not want to run an NTRIP Caster themselves.
For those deployments we offer a managed rental service for about ~$1/day.
Please see this article for additional details.
A Blocked IP state can last from minutes to weeks depending how the SNIP node has been set. On this site a period of ~180 minutes is typically used. SNIP also provides for permanent bans of any IP in the Pro model, and we have had to use that in some rare cases.
Because the ban affects the IP itself (not the port used or the software used), you may need to use a browser on ANOTHER machine to see if your own node has been banned. If banned, you will see a message similar to the below while the ban lasts. To protect the Caster and user privacy, no further information is provided.
The NTRIP Caster has banned your IP:
The IP address XXX.XX.XX.XXX has been Banned from connecting to the Caster.
This IP has failed to connect over 300 times in a row without success. Once the ban period has lapsed you will be permitted to try and log on again.
During the ban period all IP requests (including obtaining a Caster Table) are denied. Please check your log-on details and the mountPt string you are sending. This event most often occurs due to incorrect user settings with sustained rapid retries. Please take a look at your NTRIP Client settings before contacting the operator.
If the IP you are using is not being banned, and you send a status request from any browser
[the url: www.rtk2go.com:2101/SNIP::STATUS ] you will see a list of the IPs that are currently banned at that time (scroll the page down a bit). The precise values are hidden to protect the end user community, but there is enough detail presented to be able to determine if your IP is on this list without learning about others.
Whenever an IPs have been permanently banned on a SNIP node, it does not show up on the above listings. While each SNIP operator decides when to take these actions, it is typically only done in extreme cases of abuse. SNIP allows banning any problem IPs for weeks at a time before the subject IP (or IP range) is permanently banned.
We have seen this occur a few times where a group of users (often a university laboratory) have managed to get their IP range banned from continued bad connections. This occurs most often when there is a local DHCP server that is providing a new IP address with every device connection. The attack vectors (from the SNIP Caster point of view) are tracked, localized, and banned. The reasons used to determine when to ban the offending device are the same as those listed above. But now the entire group (others devices in the same sub-net who may have done nothing wrong) are prohibited from connecting.
If you believe this has occurred to you, and you see your own IP in the list at http://rtk2go.com:2101/SNIP::BANS then please drop us an email to revolve it. We can remove the ban, but are also likely to point out that you should get your own local copy of SNIP, connect that to the streams in RTK2go of interest, and then let your peers / co-workers beat that machine to death with these bad connections. See also the note above about not using RTK2go for product testing and validation.
The SNIP node on the RTK2go site is a community resource for all, but needs to be shared. This is mostly a data input concern (not one of how many end users). There are typically at least 500 hundred other data streams along with yours at any given time coming from both new users and from hundreds of different regular Base Station users all over the world.
More than 2+ PUSH-In connection from the same IP, or sending in multiple data streams a with message rates greater than 1Hz are good ways to get noticed. Noticed in this case may mean a 24 hour ban on the IP used or longer.
There are many valid reasons to do this sort of thing, but please consider just getting your own copy of SNIP to try them on. If you do not want to manage your own copy, we can set up a regional VM machine for you to operate as well. We can also setup and operate your SNIP NTRIP Caster for you (for a fee), but it is much more cost effective for you to operate your own copy. Please contact us if there are questions.
SNIP operators are advised to set these threshold levels much higher for NTRIP Client connections and much lower for NTRIP Sever connections on their own machines. The default settings are good set of value to start with.
For SNIP-2-SNIP connections the RTK2go Caster will also send back additional details in a report regarding why the connection failed. This is part of the proprietary interactive protocol implemented by SNIP on top of the NTRIP layer. These reports are displayed on the receiving SNIP console so that the sender can take corrective measures. (SNIP = Simple NTRIP with Interactive Protocol)
While this feature is enabled on this SNIP node, please be aware that the owners / operators of other Caster nodes may elect to disable this on their own systems.