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 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 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.
A good way to get your IP banned for longer periods of time (days to 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 periods of 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.
…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.
… 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 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.
…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). 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.
A Ban state can last from minutes to days depending how the SNIP node has been set. On this site a period of ~150 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 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 subnet 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 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 at least two hundred other data streams along with yours at any given time coming from both new users and from several hundred 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.
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 lower on their own machines.
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 nodes may elect to disable this on their own systems.