How to get your IP banned

Top   SNIP Knowledge Base

Ban Thresholds

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, and the period of the ban is fairly short, as this site often has novice users connecting to it.

A count is kept of the number of “bad” or failed connections seen for every IP address.  This value is 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).  These are all threshold values which the operator can set.  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 a 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 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.  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.

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 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.   Please contact us if you suddenly found such an issue in order to have your IP ban reset.

The following cases can result in in longer ban periods

Very Aggressive Re-Connections

A good way to get your IP banned for longer periods of time (days to permanently) is 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.

Very Aggressive Base Station Data

A good way to get your IP banned for longer periods of time (days to permanently) is 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]

Abusive mountPt Names

A good way to get your IP banned for longer periods of time (days to permanently) is to 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 your own advertising sources for this.

Using for Product Testing

A good way to get your IP banned for longer periods of time (days to permanently) is to 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.


If Banned

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), 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, 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 30 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 a browser
[the url: ] you will see a list of the IPs that are currently banned at that time.  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.

Usage Thresholds

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 a 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 4+ 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.


For SNIP Owner / Operators

SNIP operators are advised to set these levels much lower on their own machines.

Using the IP Ban control settings are discussed further here, and here,  on the knowledge base site.

For those connecting to RTK2go with a SNIP device.

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.

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.