RTK2go IP Bans

Does anyone have any idea why my base station IP keeps getting banned from RTK2go because I cannot see any issue with my settings and RTK2go can only tell me that their firewall is doing “strange things” with my traffic.

The mountPt [Ryedale] was Rejected due to a BAD MountPt, User or Password [ : PASSWORD]] at: 2022/03/29 07:37:43 AM
The mountPt [Ryedale] has a Prior Rev 1 Reservation and it must use the private password: [ PASSWORD ]

The username and password are correct, settings as per below.

Ports 2101 and 80 are both forwarded correctly to the LAN IP of the RTKBase R-Pi, 80 is obviously only for the web interface:

There are many reasons why rtk2go might ban you.
Mainly activities that affect the performance of rtk2go, followed by data abuse.
IPs are automatically banned but can also be banned by SNIP administrators (and a new ban will be introduced to automatically ban similar behavior in the future).

Your IP is banned and it will continue to be banned if you don’t solve your problem.

If you really have realized your mistake and need to restore connection immediately, send an email to the SNIP admin, they will review and remove the ban for you:

Most of this problem is because your version of NTRIP Base software has not been well designed according to rtk2go’s secure connection standard.

All you need to do in the future is simply:

  • Send RTCM at 1hz. (Do not send RAW,NMEA,…)
  • Wait at least 60 seconds to 5 minutes if you have to reconnect to the server.
  • Do not attempt to connect to the server without actually sending anything useful.

Our users of ESPrtk are never (very rarely) banned by rtk2go because ESPrtk will not attempt to reconnect (or wait) if problems with the F9P/PX1122R’s hardware (message filtering, speed) are detected. stream), internet stability, and past reconnections.
In the worst case, ESPrtk can even detect if rtk2go is banning it and will increase the reconnect timeout after 30 minutes - 1 hour.
Because if you get banned, your IP will be in danger of being banned forever.

Just make sure you don’t abuse rtk2go too much, and stop reconnecting before it gets blacklisted by rtk2go.

I have spoken with the team at RTK2go and they told me that their firewall was acting strangely with regard to my traffic, but could not elaborate on this.

It could be a problem with an RTK2b setting, but I have meticulously followed the ardusimple guide for this. It could be a setting in RTKBase, but again I have changed very little.

I’m guessing that some protocol is at fault, might have to get a packet sniffer fired up and see what is happening on the wire, but even then I may struggle as the AS documentation really is pretty poor.

1 Like

I believe the same F9P configuration will not affect rtk2go as most people still use it normally

This is a typical example for a base station of our user F9P +ESP32 (ESPrtk). (Project by Stefan Urban, he is testing WIFI and is planning to use Ethernet).

  • All RTCM messages at 1hz.
  • Not turn on too many unnecessary messages (1094,1008,1033,1074,…).
    The rtk2go’s email response seems to be making it clear that the connection between the Caster rtk2go server and your NTRIP Base application is the cause.
    RTK2GO provides quite a bit of useful information when a Base station uploads data to it.
    If you don’t mind, please provide the link to your mountpoint when it becomes available again.
    I hope I can do something to help you find the cause and solve the problem.
1 Like

Well first of all, thank you for your input.

I’m just using the standard off the shelf ardusimple setup instructions.l:

As I say, I did speak with RTK2go and they concluded this was a problem with their firewall rejecting my traffic and they couldn’t see why. It works just fine as a NTRIP server for my rover, that doesn’t appear to be an issue. I just cannot get it registered with RTK2go so I can’t share it publicly which is a bit of a shame because I wanted to share it with a bunch of farmers around me.

Maybe I have inadvertently enabled a weird messaging option or standard, I’ll have a look.

Thanks again.


This is why I’m not completely comfortable relying on rtk2go. There are too many variables that can lead to banning. I’m using them currently using their ntrip server app to push rtcm from serial port to their servers, and I’ve never had any banning issues. But I hope to somehow run my own ntrip server at some point. Although truth be told I don’t love ntrip at all. It’s an awkward way of doing things (and confusing nomenclature). I think using http is kind of silly for this sort of thing. But I guess it does provide a mechanism for multiple “servers” to push to a central caster, and deal with multiple mount points (why not call them channels?).

1 Like

I’m still learning the principles behind all this, but I do kind of get the banning. I would imagine that they have limited bandwidth and resources and don’t want to process relentless streams of gibberish. So far the bans have been fair, their firewall is seeing consistent authentication failures which could be the sign of a brute force attack. So they block traffic for a few hours. Seems fair enough.

I have never had any issues using their local mountpoint as a server to my rover, but I wanted to give something back so I was trying to register my base for public use.

Being a network engineer by trade, I like the idea of NTRIP; precision correction data over IP. No long distance radios and line of sight necessary, you could set up a Wifi mesh covering tens, if not hundreds of miles on your land, or just use the internet / cellular to connect your base to your river.

I also think HTTP is a good way of delivering this because it’s pretty universal. Every device has a browser these days, so the ability to present data in a browser does make sense.

That’s what I like most about RTKBase, it gives the pi a graphical front end for your base station.

However, my old networks team would have hung me for saying this because, to them, GUIs were for people who didn’t understand computers. These people were savage.


Either of you get bored and want to get deeper into Ntrip, this is the decode of my local ntrip. Message 1004 and 1006 are attached. Now what to do with this?

Ntrip Stream.txt (6.5 KB)


Thank you so much KentStuff.
But RAW RTCM file will be better.

@bluerabbit and @torriem .

You both have your right opinions.
I completely agree with both of you.

NTRIP is not really good but still not too bad to remove .
The future of NTRIP will certainly have to change a lot if it is not to be beaten by MQTT, because NTRIP hardware performance (processor chip) proves stressful for deployment in large numbers.
However, NTRIP is still very popular so we support both (NTRIP and MQTT).

Hopefully @bluerabbit will solve his problem after switching to a public account on rtk2go.
RTK2GO is a free service and it is fair that they are trying to keep things free to use as efficiently as possible. And ip ban is such a thing.

@torriem I really understand how you feel.
Do you want to try with ESPrtk? I think this is the right time for you to try using a CORS server of your own.
Thank you for your support and help in the past time on AGOPENPS forum. I would suggest to ESPrtk Team to give you a special offer asking you to send the activation key when sending email to contact@esprtk.com .

Here is an example for a public CORS server running on ESP32 .

NTRIP : http://esprtk.myddns.me:2102

  • Mountpoint : Base_0
  • Username NTRIP : name_0
  • NTRIP password: pass_0

Profile : http://esprtk.myddns.me:82/admin

  • Username Profile: admin
  • Profile Password: abc123ABC

CORS Dashboard : http://esprtk.myddns.me:82/admin

  • CORS Dashboard username: admin
  • CORS Dashboard password: abc123ABC

And of course, with it, you will have the highest permissions of the CORS NTRIP server administrator and can set up IP bans, monitor immediate disconnections or IP bans with an active Client. , track location via GGA messages and user thread speed , limit bandwidth and resources with accounts … the same way NTRIP’s admins are doing !

And therein lies the problem, I have a public account with RTK2go :slight_smile:

I’m actually tempted to try with your esp solution. It’s something that I have been meaning to study when I get the time, but I’ve been focussed on NTRIP.

@KentStuff , @bluerabbit and @torriem . The ESPrtk team will consider to offer of three you guys a special offer when you email us your request key activate.

About CORS server, something like this when you compare between building NTRIP Base and NTRIP CORS Server mode on ESPrtk.

Now I see exactly what you are saying.

I’ve been away for a couple of days and have come back to yet another email from RTK2GO saying that my IP has been banned yet again. The offence? That I left an NTRIP client running which was connected to a caster which has stopped responding.

So basically the owner of the caster I was using has turned off their base station and for this reason I have had my IP banned from RTK2GO!

I try to be patient and understanding, I try to see both sides in a debate, but this is completely absurd, it’s like YouTube banning you from their services because you left a video running for a couple of hours when they were having unrelated problems with their own service. They had the problems and banned you for not immediately responding to their problem.

Stuff that, I’m never going anywhere near RTK2GO again and will advise everyone I know to completely avoid them.

Correct me if I am wrong here, but aren’t we base station owners doing RTK2GO a favour by publishing our casters and making them available on the RTK2GO service for free? The way they act is like they are doing us a favour, but I’m really not sure about this. It all seems very one way to me…

1 Like

Sorry to hear that, @bluerabbit. That’s definitely absurd. It’s worth emailing rtk2go to ask that the ban be reversed and also to ask them to stop banning for that reason. Also perhaps they could be asked what a automated client should do when a mount point disappears.

Were you using the AOG ntrip client? I ask so that maybe the NTRIP client code can be modified to back off the connection attemps, rather than hammering RTK2Go’s server.

I had a temporary IP ban once using u-Center’s ntrip client, but I can’t remember the reason.

One minor quibble, though. We’re not doing rtk2go a favor by publishing our base stations. They don’t make money on any of that end of things. The more base stations that are published the more it costs them, just as the more clients that connect the more it costs them also. If RTK2Go was able to monetize our base stations then I’d say you had a point. Maybe NTRIP v3 will support ads for a revenue stream! :slight_smile:

I’ve been using Tailscale for several weeks with my phone, connecting directly to my base station and have had no troubles whatsoever. The only issue with Tailscale is that the certificates it generates under the hood only last 180 days, so every six months you have to re-enroll your devices (including the Pi) to generate new certificates and keys. This is not too hard but does require a command in the terminal on the Pi.

Same cause. I had inadvertently left a laptop in the garage running ucentre’s NTRIP client connected to a local caster. I cannot easily see how this causes a problem though, if the caster is turned off, then any NTRIP requests will simply get dropped by their firewall as there is nothing responding to the service. This will add approximately zero load to their network as it doesn’t have to process anything, the traffic just gets rejected.

Why ban the client? I genuinely don’t get it. This just seems backwards.

With regard to who is doing who a favour here, without casters, RTK2GO has nothing to offer and the more casters it has, the better its service. The resources required for this hosting service are minimal, the network load is also minimal.

Yes, it’s free, and therefore it could be argued that it is churlish to complain, but compare their service and support with AOG; I probably use up more bandwidth and resources with my constant spamming of this forum with requests than any NTRIP service would generate and haven’t been banned… yet :wink:

The bottom line here is that I’m just going to keep things simple and keep my base station private from now on. It feels like I am fighting a constant uphill battle with RTK2GO in order to add my resources to their network at my own expense. They seem to be making this unnecessary convoluted.

I will check out tailscale, thanks!

1 Like

Interesting coincidence… Something has flaked out on my computer acting as a base station (really just a radio receiver that picks up my base station radio and repeats it over the internet), and I get a message from rtk2go saying my IP is banned. And I was away from home and no way of fixing it. Lovely. Anyway I know what happened and how to prevent it from happening again, but that’s reinforces my desire to be completely independent.

Basically the crime was that my rtcm data stream stopped, so the ntripserver program was sending no data to rtk2go so they booted it, and of course when it tried to reconnect that triggered their firewall. The thing that irks me is that I’m using their official ntripserver to push data to the caster. You’d think the server would be smart enough to determine there’s no data coming in over the serial port (or whatever the source) and to not try connecting to the rtk2go server. That would save me and them a ton of trouble.

1 Like

That was exactly my problem, I was away for a bit and couldn’t resolve the issue before they banned me.

This is a massive flaw, regardless of how well you configure your end of things, you can go to bed with everything working and then wake up to find you have been banned. It looks like you have about 20 mins to respond and resolve any issues.

Yes, agreed, it would be fairly simple to monitor whether data was arriving from a certain address and, if not, then ignore it for a period (or until the correct data is detected again) rather than just responding to any issue with an IP ban. Just seems lazy to me.

As you said before though, it’s a free service. I just don’t want to use it any more :slight_smile:

1 Like


And maybe I have to admit to my own mistakes here. Still think it’s a bit rough to be banned for leaving an NTRIP client running when there are issues on the caster side, but have had time to look at this and have learned a bit that may prove useful to new members.

The actual process for setting up an RTK base station with an Ardusimple simpleRTK2b board is really straight forward and I have been over complicating matters. Simply…

Download the Base Station config file from their site, upload it to your simpleRTK2b board and don’t mess with it.

Download RTKBase, burn it to an SD card and stick that in a Pi.

Do the relevant firewall rules and it should then work with rtk2go (once registered)

One thing I have learned is that this default config runs the board in “Survey in” mode for 60 seconds and this process is run every time the board is restarted unless the user changes from Survey In to Fixed in U-Centre.

There are some extra steps in this and I’ll write an updated guide when I get the chance, but it pretty much all works out of the box.

My biggest mistake was that, in my quest for the best accuracy and precision possible, I had set my RTK2b board to Survey In to run for a minimum of 24 hours before going to FIXED.

So it’s entirely possible that I annoyed the heck out of RTK2go every time I messed with my base and restarted this process.


Now I have similar situation when my base went out, AgIO crashed or getting banned for too many reconnect attempts.

After couple tablet, AgIO, AOG restarts I opened source table and my base station was missing after selecting other base station problem want away.

Can AOG do a check on startup is your selected mountpt online / in source table ?

Yes, this is a real problem.

I want to use NTRIP corrections on my base, but if I do and they turn off the caster, then I get banned after an hour or so.

Not easily that I can think of. Really you would need some kind of auth packet that, if rejected, tears down the session.

@KentStuff: any ideas on this?