Vreemd (Python) connectie probleem (geodata.nationaalgeoregister.nl)

Hoi,

Ik heb een heel raar probleem, wat enerzijds Python gerelateerd lijkt en anderzijds (netwerk)Provider gerelateerd…

Om de lagen van een WMS/WFS op te halen, haal ik de capabilities op van een service met een paar Python regels als:

import urllib.request, urllib.error
url = 'https://geodata.nationaalgeoregister.nl/nok2014/wms?request=GetCapabilities&service=wms'
print(f'test url: {url}')
response = urllib.request.urlopen(url)
string = response.read()
print(f'string: {string}')

Als ik die url in een browser zet, of met curl opvraag heb ik meteen response(!!)

Als ik bovenstaande code uitvoer duurt het (bij mijn provider Freedom.nl) eindeloos of timed out (zowel onder windows als linux).

Als ik bovenstaande code uitvoer wanneer ik een ANDERE connectie heb (bv G4 t-mobile, of als ik via een VPN ga) dan werkt het WEL.

Ik heb al met mijn provider gebeld, maar die heeft ook geen idee…
Kan iemand anders dit reproduceren?
Of er een verklaring voor geven?
(machines, routers alles herstart natuurlijk)

Voor netwerk nerds mijn traceroutes (ikzelf kan dit niet interpreteren):

Via freedom.nl

traceroute geodata.nationaalgeoregister.nl

traceroute to geodata.nationaalgeoregister.nl (145.77.103.123), 30 hops max, 60 byte packets
1 fritz.box (192.168.178.1) 0.857 ms 1.032 ms 1.238 ms
2 lo0.cmbr.nikhef-1.connected.by.freedom.nl (185.93.175.225) 11.230 ms 11.385 ms 11.333 ms
3 xe-1-0-0.frdm.nikhef-1.connected.by.freedom.nl (185.93.175.233) 12.190 ms 13.396 ms 13.347 ms
4 cr0.nikhef.nl.fusix.freedom.nl (37.139.138.48) 13.619 ms 17.212 ms 17.160 ms
5 br0.drtam1.nl.fusixnetworks.net (37.139.139.247) 15.217 ms 15.675 ms 16.096 ms
6 adm-b1-link.telia.net (62.115.151.184) 16.953 ms 16.368 ms 16.711 ms
7 adm-bb3-link.telia.net (62.115.136.194) 17.891 ms 10.363 ms adm-bb4-link.telia.net (62.115.137.64) 10.082 ms
8 adm-b10-link.telia.net (62.115.120.229) 10.332 ms * *
9 * * *
10 ae-2-3207.edge6.Amsterdam1.Level3.net (4.69.162.218) 12.963 ms 12.904 ms ae-1-3107.edge6.Amsterdam1.Level3.net (4.69.162.214) 13.199 ms
11 CAPGEMINI-O.edge6.Amsterdam1.Level3.net (212.72.47.66) 13.932 ms 14.802 ms 15.063 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Via T-Mobile

traceroute geodata.nationaalgeoregister.nl

traceroute to geodata.nationaalgeoregister.nl (145.77.103.123), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 84.241.225.42 (84.241.225.42) 36.697 ms 36.657 ms 36.614 ms
6 80.157.130.241 (80.157.130.241) 36.572 ms 23.991 ms 23.878 ms
7 pd9ef35ea.dip0.t-ipconnect.de (217.239.53.234) 23.829 ms 29.224 ms 23.587 ms
8 4.68.72.29 (4.68.72.29) 23.471 ms 23.424 ms 23.661 ms
9 ae-1-3107.edge6.Amsterdam1.Level3.net (4.69.162.214) 27.669 ms 27.544 ms 27.490 ms
10 CAPGEMINI-O.edge6.Amsterdam1.Level3.net (212.72.47.66) 25.894 ms 33.562 ms 113.378 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Kan het zijn dat het mogelijk iets te maken heeft met ddos aanvallen op verschillende ISPs?

Freedom werd ook genoemd als een van de providers waarop aanvallen hebben plaatsgevonden.
Je kunt als workaround proberen om op je lokale machine/router een alternative DNS server in te stellen.

Bijvoorbeeld die van OpenDNS:

  • 208.67.222.222
  • 208.67.220.220

of van Google:

  • 8.8.8.8
  • 8.8.4.4

om te kijken of het dan wel werkt?

2 likes

Hoi Richard, ik kan het probleem (via xs4all) niet reproduceren. Ik krijg meteen respons - het zou dus wel eens aan je ISP kunnen liggen inderdaad…

Voor de liefhebbers, ik heb het deels opgelost. Wanneer je aan de regel

response = urllib.request.urlopen(url)

een timeout (in seconden) waarde toevoegd:

response = urllib.request.urlopen(url, timeout=2)

Dan komt in de (provider-specifieke?) gevallen dat er eerder helemaal niks kwam nu tenminste na die 1 of 2 seconden WEL gewoon de data binnen…

Wat in het geval van PDOK dan wel weer (voor mij) lastig is, want, om de configuratie-file voor een release van de QGIS pdokservices-plugin te maken, haal ik de capabilities op van alle beschikbare services (paar honderd) en elke seconde die ik de timout vergroot duurt het weer langer eer het geheel binnen is. Maar sommige services lijken (intern) wel gecached, maar anderen lijken live (langzaam) te worden gegenereerd, dus ik heb echt moeten pielen met in stukken ophalen met verschillende time outs. Bijkomend issue is dat de url’s recent wat veranderd zijn, waardoor het script zoiezo niet goed liep …

Technisch begrijp ik niet hoe dit werkt, net of urllib z’n ontvangen buffer pas uitspuugd nadat de connectie is afgesloten. En sommige http connecties lijken open te blijven na ontvangst van een document terwijl andere openblijven en pas na de timeout afkappen (ofzo…). urllib/http guru’s kom maar door :wink:

Maar goed, uiteindelijk is het gelukt: timeout optie gebruiken dus :slight_smile:

Voor http maak ik graag gebruik van retry-wrappers om calls. retry/api.py at master · invl/retry · GitHub gebruikt een decorator waarin je zowel een delay als een backoff parameter kan meegeven. Aangezien QGIS (nog) geen Python package installatie ondersteunt zou je de code moeten kopieren en plakken in je project maar de code is klein genoeg om enigszins hanteerbaar te zijn, denk ik.

Hoop dat je hier wat aan hebt.

Voor niet-QGIS-plugin-bouwers: gebruik pip install retry en dan krijg je het netjes als een package. Zie retry · PyPI voor documentatie.

“retry” (en timeout) gebruiken we ook in GeoHealthCheck [1] om “false negatives” te vermijden. Timeout en retry zijn onderdeel Python requests [2] package. Een veel betere optie dan urllib, en min of meer de standaard in Python voor HTTP clients. Maar weet niet of je in PyQGIS die luxe hebt om requests te gebruiken.

Ahem, ja voor alle HTTP(S) downloads van Kadaster, bijv basisregs downloads gebruik ik ook in Bash (curl, wget) een retry-loop omdat connecties nogal eens worden (werden?) afgebroken.

[1] GeoHealthCheck/util.py at master · geopython/GeoHealthCheck · GitHub
[2] Requests: HTTP for Humans™ — Requests 2.30.0 documentation

1 like

Het kan ook zijn dat de server je afknijpt mdat je geen, of een (in de ogen van de server) verkeerde request headers meestuurt. Ik weet dat onder andere Open Streetmap en met.no op die manier hun verkeer wat in goede banen proberen te leiden. Omdat je browser automatisch headers (user-agent, accept-waardes, dat soort dingen) meestuurt, maar curl niet (althans niet automatisch voor zover ik weet) zou je dat eens kunnen proberen. Gewoon de headers en user-agent van je browser meesturen, kijken wat er gebeurt.

1 like

Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.