"Another request from your IP is still running", but there is no other request

[HostedDinner]

Sometimes I get this error at overpass-turbo:

runtime error: […] Another request from your IP is still running.

but I'm not running any other request at the moment.
And on the osm website, I've got:

Fehler beim Kontaktieren von http://overpass-api.de/api/interpreter: Too Many Requests

for the query tool. The Ajax request returns http error code 429 with following response in the body:

runtime error: open64: 0 Success /osm3s_v0.7.51_osm_base Dispatcher_Client::request_read_and_idx::rate_limited. Another request from your IP is still running.

Is it an IPv6 issue? I know some programs will split IPv6 after the first : and treat everything with the same prefix as one IP. I'm not sharing my internet connection or something like this.

I don't think, that I have issued too many request like in #223 in a given time period (1 or 2 in a minute)

[Pauleosm]

I have the same with my Kabel BW account, same Error

[TheFive]

As some internet providers have started to use IPV4 addresses for several customers the same time, this was a matter of time to happen.
@mmd-osm I assume you support IPV6 with no problem.

@Pauleosm Can you have a look in your "Fritz Box" or Router, which kind of IP Connection you are using.
If there is a DS-Lite info in the IPV4, than my assumption of shared IP Adress can be true.

I do not know, wether it is possible to switch the router to IPV6 temporary.

But I am "leaving" my level of competence with this help.
If you are using IPV6 and IPV4 with priority for IPV6 (which should be normal), Overpass should use IPV6 and everything has to be fine.

[mmd-osm]

// cc: @drolbr

I think there are still some parts in the dispatcher where ipv6 is not yet covered, affecting the overall resource management. Most notably, probe_client_token is only implemented for IPv4, but not IPv6.

I know some programs will split IPv6 after the first : and treat everything with the same prefix as one IP.

That's quite close to the actual issue: to reproduce you can check in C++ shell: http://cpp.sh/9qmfp

Input IP: 2001:123:2212:1:1123:aabc:1123:4321
Result: 2001

=> All IP addresses starting with 2001 will be identified as one single ip address.

This is even worse for addresses used by provides like "Free" in France. They use 2a01:e00::/26 as prefix, which will be converted to client token "2".

[MikiDi]

Hi,
I'm also experiencing this problem since a couple of days (together with many other people I think, as my ip prefix has the same kind of format as @mmd-osm mentioned).
Could someone who's into the project please list what has to be done to get this fixed please?
Parsing the ipv6 address itself isn't the big issue I guess (although no 128-bit standard type exists ...), but I suppose some work will need to be done on the backend as well right?

[mmd-osm]

Roland prepared a patch and I believe it's already deployed on the server. Can those who were affected try again please?

[Pauleosm]

It works!

[drolbr]

A quick patch has been deployed with commit 291bf95 and its predecessor. However, this leaves a couple of more long term relevant IPv6 problems and related problems open:

1. What part of the IPv6 address is a unique user?
   IPv4 addresses on the time scale of a few minutes worked good enough. IPv6 offers on purpose every single DSL line subscriber at least the lower 64bit as freely available address space, i.e. 2^64 potential addresses for a rogue user. While one could get around that problem by ignoring the lower 64 bit, at the risk of clustering legitimate different users on a single address, a couple of carriers have planned to give each customer a /56 address space instead. I.e., we cannot figure out in a simple way what size of address block belongs to a unique user.
2. What to do with proxies?
   I know of at least two cases where a bunch of users share a single IPv4 address. It would be a fair deal to give these users a mechanism to differentiate from each other. The basic idea would be to hand out user keys that override the IP address to those that ask for, and leave the management details to who controls that IP address. These user keys need to be mapped into the potential key space, but IPv6 has no official local address space.

However, as a first aid, the current patch should work.

[kdano]

I also haven't experienced the issue for the last 2-3 days.

[HostedDinner]

I do not use it often, but I don't have seen the issue in the last few days neither.

I have looked at the linked code, and I suggest, first try to recognise IPv6 (by searching at least one :), then search for a .. That's because . are allowed in IPv6 (https://tools.ietf.org/html/rfc3513#section-2.2)

[mmd-osm]

Instead of implementing all the IPv4/IPv6 parsing logic from scratch, another option might have been to use existing functions- like inet_pton or getaddrinfo.

These user keys need to be mapped into the potential key space, but IPv6 has no official local address space.

Isn't that already covered by Private IPv6 addresses?

[MikiDi]

No more problems over here either, thanks a lot :-)

[grischard]

I experienced the issue again this morning from a script, 7 times in a row:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" lang="en"/>
  <title>OSM3S Response</title>
</head>
<body>

<p>The data included in this document is from www.openstreetmap.org. The data is made available under ODbL.</p>
<p><strong style="color:#FF0000">Error</strong>: runtime error: open64: 0 Success /osm3s_v0.7.51_osm_base Dispatcher_Client::request_read_and_idx::rate_limited. Another request from your IP is still running.
 </p>

</body>
</html>

I've added a sleep(5) to my code and haven't seen the error again, but is there a better solution?

[mmd-osm]

I assume you're running several queries in a row? You're hitting a new limit which was introduced in 0.7.52, so that's expected. You can add a delay, or switch to the rambler.ru instance as an example.

Please also take a look at #223 instead. This issue #229 is about a different root cause albeit producing the same error message (which in turn is also a bug).

[grischard]

Thanks, it does make more sense in the context of #223. The rambler.ru instance, unfortunately, seems to be broken for attic queries.