Laden tweakers.net gaat niet altijd goed

[TomPlant0]

Ik hoop dit bericht in een keer te kunnen tikken. Maar weet niet of het lukt

Op mijn iPhone 6S krijg ik op tweakers vaak de melding "Safari kan de webpagina niet openen, omdat de netwerkverbinding verbroken is". Nu heb ik een Ping test gedaan op mijn iPhone naar tweakers. Echter zie ik niks raars. Zowel met Ping, DNS en NSLOOKUP.

Zie afbeeldingen:
http://imgur.com/rSyqSi7
http://imgur.com/Y0LINHQ
http://imgur.com/oCZ8UNz

Daarnaast ook alle tmp bestanden verwijderd. Werkt ook niet. Zelfs m'n iPhone wissen en schoon beginnen. Werkt niet.

Het begint inmiddels wel vervelend te worden. Iemand nog tips ?

[xbeam]

Hier het zelfde probleem, Ik heb al van alles geprobeerd maar helaas zonder resultaat.

Ook loopt hier al een topic voor maar ook daar heeft niemand een oplossing of suggesties

Tweakers laadt soms niet

[ Voor 33% gewijzigd door xbeam op 03-01-2016 00:33 ]

[Brahiewahiewa]

31.22.80.140 ?

[killercow]

Heb je toevallig 2 routers achter elkaar staan? Eentje die wellicht een te grote MTU gebruikt?

[johnkeates]

Waarschijnlijk ligt het aan je provider en niet aan tweakers.

[TomPlant0]

Het vreemde is. Ik heb eerst altijd m'n Ziggo modem/Router gebruikt. Nu heb ik daar een eigen router aan gehangen. Ziggo heeft de router functie uitgezet op de modem. Sindsdien heb ik er alleen op m'n iPhone 6 last van. Het vreemde is dat ik het op mijn iPhone 5. (Net nog even tien minuten op zitten browsen.) Het probleem helemaal niet heb.

Ik heb een WRT1900AC router van Linksys/Cisco
@brahawiehawie Dat is ook een IP-adres van tweakers. Maar je krijgt dan een fout-melding te zien als je die gebruikt.

[ Voor 13% gewijzigd door TomPlant0 op 03-01-2016 08:57 . Reden: Reactie ]

[Breezers]

Dit probleem is o.a. ook in onderstaand topic aangegeven, maar is kennelijk niet belangrijk, want is Apple Safari/IPhone probleem icm Tweakers en daar hebben te weinig gebruikers last van, dus hier gaat men niets aan doen vanuit Tweakers

Ben ik de enige?

Ik heb mij laten vertellen dat het probleem zit in de manier waarop Tweakers alle sessies van gebruikers probeert te tracken voor reclame doeleinden die afwijkt van andere websites en daardoor dit gedrag vertoond, maar ik heb er zelf geen verstand van.

[TomPlant0]

Hmm. Dat is inderdaad een interessante. Ik zal eens op alle apparaten uitloggen. Kijken of het dan beter gaat.

Update: Het probleem blijft dus gewoon. Het vreemde is alleen. Als ik op m'n 4G verbinding internet heb ik geen problemen. Alles gaat dan goed. Tenzij ik weer op zei-Fi ga werken.

[ Voor 45% gewijzigd door TomPlant0 op 03-01-2016 10:16 . Reden: Update ]

[DJVG]

Buiten het feit dat de nameservers van Tweakers niet goed geconfigureerd zijn om te antwoorden over TCP via IPv6 (geen vereiste opzich want pakketjes zijn kleiner dan 512B):
En is er iemand die IPv6 gebruikt die dit probleem heeft?

code:

# dig +tcp tweakers.net @2a00:1188:8:d001::1

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> +tcp tweakers.net @2a00:1188:8:d001::1
;; global options: +cmd
;; connection timed out; no servers could be reached

# dig +tcp tweakers.net @2001:9a8:0:e::53

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> +tcp tweakers.net @2001:9a8:0:e::53
;; global options: +cmd
;; connection timed out; no servers could be reached

Het "vreemde" is wel dat het werkt over IPv4:

code:

# dig +tcp tweakers.net @31.22.80.137

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> +tcp tweakers.net @31.22.80.137
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55984
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tweakers.net.                  IN      A

;; ANSWER SECTION:
tweakers.net.           300     IN      A       213.239.154.20

;; Query time: 3 msec
;; SERVER: 31.22.80.137#53(31.22.80.137)
;; WHEN: Sun Jan  3 10:04:42 2016
;; MSG SIZE  rcvd: 46

# dig +tcp tweakers.net @213.239.154.17

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> +tcp tweakers.net @213.239.154.17
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25659
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tweakers.net.                  IN      A

;; ANSWER SECTION:
tweakers.net.           300     IN      A       213.239.154.20

;; Query time: 1 msec
;; SERVER: 213.239.154.17#53(213.239.154.17)
;; WHEN: Sun Jan  3 10:04:09 2016
;; MSG SIZE  rcvd: 46

Dit zou natuurlijk een keuze kunnen zijn, maar kan zo 123 niet bedenken welke.

Daarbij valt het op dat de waardes in het SOA record afwijken van de recommended waarde:

code:

# dig SOA tweakers.net  @213.239.154.17

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> SOA tweakers.net @213.239.154.17
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47662
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tweakers.net.                  IN      SOA

;; ANSWER SECTION:
tweakers.net.           300     IN      SOA     ns.tweakdns.eu. bofh.tweakers.net. 2015110202 300 300 864000 300

;; Query time: 11 msec
;; SERVER: 213.239.154.17#53(213.239.154.17)
;; WHEN: Sun Jan  3 10:08:20 2016
;; MSG SIZE  rcvd: 85

SOA TTL van 300 terwijl 3600 wordt geadviseerd, meh, maakt niks uit.
Wat wel interessant is zijn de refresh, retry, expire, minimum waarde, ik weet niet wat de reden is geweest voor een refresh/retry van 300 seconden maar dit heeft geen enkele waarde en zorgt alleen maar voor onnodige bandbreedte/load op DNS slaves. De expire waarde staat dan op "maar" 10 dagen waarbij meer dan 14 dagen geadviseerd wordt. We moeten er voor het gemak maar van uit gaan dat Tweakers DNS fouten binnen 10 dagen kan oplossen in het ergste geval zijn ze na 10 dagen onbereikbaar.
De minimum waarde staat op 300, opzich prima aangezien ze alle records publishen met een TTL van 300, o nee toch niet:

code:

# dig ANY tweakers.net  @213.239.154.17

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> ANY tweakers.net @213.239.154.17
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45250
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tweakers.net.                  IN      ANY

;; ANSWER SECTION:
tweakers.net.           60      IN      A       213.239.154.20
tweakers.net.           60      IN      A       31.22.80.140

;; ADDITIONAL SECTION:
mx2.tweakers.net.       60      IN      A       213.239.154.8
mx1.tweakers.net.       60      IN      A       213.239.154.6
mx2.tweakers.net.       60      IN      A       213.239.154.7
mx1.tweakers.net.       60      IN      A       213.239.154.5

;; Query time: 2 msec
;; SERVER: 213.239.154.17#53(213.239.154.17)
;; WHEN: Sun Jan  3 10:29:14 2016
;; MSG SIZE  rcvd: 146

Nu is dit natuurlijk geen probleem, 60 seconden is niet zo gek voor een dergelijke opstelling.

Maaarr, al deze factoren bij elkaar betekend wel dat bijna elke request opnieuw gevalideerd moet worden door de nameservers van Tweakers of dat een cache ergens op het pad tussen je browser en de nameservers van Tweakers een antwoord invalideert terwijl je het antwoord opvraagt, in theorie zou het dus mogelijk zijn dat je op 1 moment het A record van tweakers.net wilt opvragen terwijl die niet beschikbaar is en er dus voor zorgt dat je browser tweakers.net niet kan vinden.

Willen ze bij Tweakers het liefst elke query zelf afhandelen? Want die nameservers moeten serieus veel queries aan het afhandelen zijn met deze opstelling, onnodig.
Ik weet natuurlijk niet of dit er mee te maken heeft, daarvoor heb ik het probleem nooit echt onderzocht (wel tegengekomen in het verleden) maar wie weet stuurt dit iemand in de juiste richting

Bonus:
Het TXT record met de SPF definitie heeft dan wel weer een TTL van een dag en heeft geen policy (?all, zijn er medewerkers misschien met een @tweakers.net adres die mail afleveren bij MTA van Ziggo oid?) dus misschien draaien ze nog in test mode of durven ze en -all nog niet aan :

code:

# dig TXT tweakers.net @213.239.154.17

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> TXT tweakers.net @213.239.154.17
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11825
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tweakers.net.                  IN      TXT

;; ANSWER SECTION:
tweakers.net.           86400   IN      TXT     "v=spf1 ip4:213.239.154.0/26 ip4:31.22.80.128/27 ip6:2a00:1188:8::/48 ip6:2001:9a8:0:e::/64  ?all"

;; Query time: 2 msec
;; SERVER: 213.239.154.17#53(213.239.154.17)
;; WHEN: Sun Jan  3 10:33:05 2016
;; MSG SIZE  rcvd: 139

[ Voor 11% gewijzigd door DJVG op 03-01-2016 10:38 ]

[ACM]

TomPlant0 schreef op zaterdag 02 januari 2016 @ 23:54:
Het begint inmiddels wel vervelend te worden. Iemand nog tips ?

Dus je hebt het alleen op je Wifi thuis?

TomPlant0 schreef op zondag 03 januari 2016 @ 08:52:
@brahawiehawie Dat is ook een IP-adres van tweakers. Maar je krijgt dan een fout-melding te zien als je die gebruikt.

Hoe 'gebruik' je die? Want beide ip-adressen horen gewoon een werkende Tweakers.net te geven. Als je echter het ip-adres zelf in je browser intikt, dan zal je inderdaad een melding krijgen dat je een onbekende hostname hebt opgevraagd. Maar op zich is dat ook een bevestiging dat je goed bij ons uitkwam

Breezers schreef op zondag 03 januari 2016 @ 09:42:
Dit probleem is o.a. ook in onderstaand topic aangegeven, maar is kennelijk niet belangrijk, want is Apple Safari/IPhone probleem icm Tweakers en daar hebben te weinig gebruikers last van, dus hier gaat men niets aan doen vanuit Tweakers

Ik vind dat een interessante conclusie, aangezien geen medewerkers van Tweakers in dat topic hebben gereageerd. Aangezien iPhone+Safari een tot de grootste browsers op Tweakers behoort, zijn we wel degelijk bereid daar moeite in te steken. Maar wij kunnen niets aan netwerkproblemen doen, tenzij het ons stukje van het Internet is.

Ik heb mij laten vertellen dat het probleem zit in de manier waarop Tweakers alle sessies van gebruikers probeert te tracken voor reclame doeleinden die afwijkt van andere websites en daardoor dit gedrag vertoond, maar ik heb er zelf geen verstand van.

Door wie heb je je dat laten vertellen? Het lijkt eerder je eigen conclusie te zijn?
Er zit heel weinig verschil in wel en niet ingelogd Tweakers bezoeken. En een verbroken netwerkverbinding klinkt al helemaal als iets wat dan per definitie onmogelijk zou moeten zijn (we hebben die verbinding tenslotte nodig om te weten of je ingelogd bent!)

Hoedanook, als een probleem - zoals hier - eigenlijk alleen bij een enkeling voorkomt, dan wordt het helaas wel erg lastig om vanuit ons nog hulp te kunnen bieden. De kans is dan wel erg groot dat het aan de kant van de gebruiker ligt.

DJVG schreef op zondag 03 januari 2016 @ 10:26:
Buiten het feit dat de nameservers van Tweakers niet goed geconfigureerd zijn om te antwoorden over TCP via IPv6 (geen vereiste opzich want pakketjes zijn kleiner dan 512B):
En is er iemand die IPv6 gebruikt die dit probleem heeft?

Niet goed? Ik hoop 'niet' ? We hebben nog niet de tijd genomen om IPv6 helemaal goed op te zetten en tot die tijd blijft het uit staan.

Het "vreemde" is wel dat het werkt over IPv4:

Het zou wat zijn als het niet werkte op IPv4

Maaarr, al deze factoren bij elkaar betekend wel dat bijna elke request opnieuw gevalideerd moet worden door de nameservers van Tweakers of dat een cache ergens op het pad tussen je browser en de nameservers van Tweakers een antwoord invalideert terwijl je het antwoord opvraagt, in theorie zou het dus mogelijk zijn dat je op 1 moment het A record van tweakers.net wilt opvragen terwijl die niet beschikbaar is en er dus voor zorgt dat je browser tweakers.net niet kan vinden.

Ik mag toch hopen dat een record niet onbeschikbaar op het moment dat het geinvalideert wordt? Het lijkt mij dat een fatsoenlijke dns-server dan het nog bekende antwoord terugstuurt en daarna opzoek gaat naar de nieuwe of dat het eerst het nieuwe adres ophaalt en dus langer doet over het beantwoorden van de client.

Overigens vergeet je in deze klacht nog dat het OS en browsers de dns-records ook cachen, (in onze ervaring) meestal wat hardnekkiger dan die TTL voorschrijft.

Willen ze bij Tweakers het liefst elke query zelf afhandelen? Want die nameservers moeten serieus veel queries aan het afhandelen zijn met deze opstelling, onnodig.

Die korte TTL is de enige manier waarop onze GSLB mogelijk is. Als we TTL's van uren of dagen zouden hanteren, dan zou je bij uitval van een van de twee locaties ook pas na uren of dagen naar de nog wel werkende locatie gestuurd kunnen worden... Nu gebeurt dat in enkele minuten

Ik weet natuurlijk niet of dit er mee te maken heeft, daarvoor heb ik het probleem nooit echt onderzocht (wel tegengekomen in het verleden) maar wie weet stuurt dit iemand in de juiste richting

Als dat het door jou beschreven probleem zou veroorzaken, dan zou je toch verwachten dat het juist heel gebruikelijk is dat het voorkomt? Hier is een iemand die het alleen op zijn thuisnetwerk heeft...

[xh3adshotx]

Voorheen had ik er ook last van met een Asus AC68u, zowel op de iPad, iPhone als MacBook. Het vreemde was dat het op Windows (7,8&10) wel goed ging. Na het overstappen op een R7000 werkt Tweakers ook weer normaal op de Apple devices.

[DJVG]

ACM schreef op zondag 03 januari 2016 @ 10:54:
[...]
Niet goed? Ik hoop 'niet' ? We hebben nog niet de tijd genomen om IPv6 helemaal goed op te zetten en tot die tijd blijft het uit staan.

Maar over UDP antwoorden jullie wel netjes over IPv6 (en de IPv6 adressen zijn gepubliceerd in jullie nameservers):

code:

# dig +notcp tweakers.net @2001:9a8:0:e::53

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> +notcp tweakers.net @2001:9a8:0:e::53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15132
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tweakers.net.                  IN      A

;; ANSWER SECTION:
tweakers.net.           60      IN      A       213.239.154.20

;; Query time: 2 msec
;; SERVER: 2001:9a8:0:e::53#53(2001:9a8:0:e::53)
;; WHEN: Sun Jan  3 11:04:07 2016
;; MSG SIZE  rcvd: 58

ACM schreef op zondag 03 januari 2016 @ 10:54:
[...]

Het zou wat zijn als het niet werkte op IPv4

Was dus bedoeld dat waarschijnlijk inbound TCP op poort 53 over IPv6 geblokkeerd wordt.

ACM schreef op zondag 03 januari 2016 @ 10:54:
[...]

Ik mag toch hopen dat een record niet onbeschikbaar op het moment dat het geinvalideert wordt? Het lijkt mij dat een fatsoenlijke dns-server dan het nog bekende antwoord terugstuurt en daarna opzoek gaat naar de nieuwe of dat het eerst het nieuwe adres ophaalt en dus langer doet over het beantwoorden van de client.

Overigens vergeet je in deze klacht nog dat het OS en browsers de dns-records ook cachen, (in onze ervaring) meestal wat hardnekkiger dan die TTL voorschrijft.

Dat klopt inderdaad helemaal, het is alleen zo dat er natuurlijk resolvers bestaan tussen het pad van de resolver op het systeem en jullie nameservers die die waarde niet respecteren omdat ze buiten de geadviseerde waarde vallen, dit kan tussen DNS servers gekke problemen opleveren (vooral de waarde in het SOA record, die wordt vooral tussen cache's gebruikt).

ACM schreef op zondag 03 januari 2016 @ 10:54:
[...]

Die korte TTL is de enige manier waarop onze GSLB mogelijk is. Als we TTL's van uren of dagen zouden hanteren, dan zou je bij uitval van een van de twee locaties ook pas na uren of dagen naar de nog wel werkende locatie gestuurd kunnen worden... Nu gebeurt dat in enkele minuten

Deze techniek is ook niet heel vreemd er wordt veel toegepast (binnen een minuut is Tweakers nu weer op een ander IP beschikbaar). Dit zal weinig tot geen problemen opleveren in de praktijk (al blijf ik benieuwd naar query stats van jullie PowerDNS machine ).

ACM schreef op zondag 03 januari 2016 @ 10:54:
[...]

Als dat het door jou beschreven probleem zou veroorzaken, dan zou je toch verwachten dat het juist heel gebruikelijk is dat het voorkomt? Hier is een iemand die het alleen op zijn thuisnetwerk heeft...

Dat hoeft niet, als dit probleem iets specifiek iets is in de Apple DNS resolver dan kan het beste zijn dat alleen Apple devices er last van hebben (en dan nog kan het een racecondition zijn tussen caches). Ik zou graag het probleem willen kunnen reproduceren om uit te sluiten dat het iets met deze DNS configuratie maken heeft. Voor mij blijft de hamvraag of alle cache's jullie waarde respecteren. Het zou interessant zijn om de DNS servers van mensen die er last van hebben te verzamelen en kijken of er iemand uit te halen valt. Ik zeg niet dat het aan de DNS ligt maar gezien de bovenstaande informatie wil ik het ook niet helemaal uitsluiten just helping.

[xtr3me]

Dit probleem heb ik dus ook, goed om te horen dat ik niet de enige ben.
9 van de 10 keer gebeurd dit inderdaad op tweakers.net (+ safari iOS) en als ik het daarna met chrome (iOS) probeer werkt het wel.

[wagenveld]

Geen netwerk expert hier, maar ik heb wel vergelijkbare problemen opgelost met het aanpassen van de MTU op de router. Alleen bij bepaalde combinaties van provider, modem/router en websites, zal ongetwijfeld iets te maken hebben met gedrag van tussenliggende routes.
http://www.tp-link.us/FAQ-190.html

Kan geen kwaad om uit te testen, alleen weet ik niet of je dit vanaf een Apple kan doen.

[TomPlant0]

Ik ga vanmiddag even de MRU controleren. Zou top zijn als het zo eenvoudig is.

[xbeam]

ACM schreef op zondag 03 januari 2016 @ 10:54:
[...]

Dus je hebt het alleen op je Wifi thuis?

[...]

Als dat het door jou beschreven probleem zou veroorzaken, dan zou je toch verwachten dat het juist heel gebruikelijk is dat het voorkomt? Hier is een iemand die het alleen op zijn thuisnetwerk heeft...

Hij is niet de enige klachten staan verspreid over het forum.Ook hier is tweakers.net vaak niet berijkbaar op een iPhone via WiFi

via gprs/3&4G is het lastig om aan te geven omdat mensen dat minder actief gebruiken (minder op het forum zitten en veel pagina's opvragen.) en als de pagina niet geladen wordt dan word de oorzaak vaker aan de mobile verbinding toegeschreven.

[francoski]

Ik heb hier ook het probleem, op een Android met Chrome. Heb inderdaad twee routers staan. Zal eens gaan kijken naar die MTU size.

Edit: ik heb een OpenWRT installatie op een TP-Link en de MTU staat overal op 1500, wat voor zover ik op internet kan vinden goed zou moeten zijn. Iemand tips waar ik nog meer naar kan kijken?

[ Voor 42% gewijzigd door francoski op 03-01-2016 13:55 ]

[xh3adshotx]

DJVG schreef op zondag 03 januari 2016 @ 11:15:
Dat hoeft niet, als dit probleem iets specifiek iets is in de Apple DNS resolver dan kan het beste zijn dat alleen Apple devices er last van hebben (en dan nog kan het een racecondition zijn tussen caches). Ik zou graag het probleem willen kunnen reproduceren om uit te sluiten dat het iets met deze DNS configuratie maken heeft. Voor mij blijft de hamvraag of alle cache's jullie waarde respecteren. Het zou interessant zijn om de DNS servers van mensen die er last van hebben te verzamelen en kijken of er iemand uit te halen valt. Ik zeg niet dat het aan de DNS ligt maar gezien de bovenstaande informatie wil ik het ook niet helemaal uitsluiten just helping.

Destijds gebruikte ik een Asus AC68u in combinatie met een iPhone, iPad, MacBook Air en een Windows desktop. Pas na de update naar iOS 9 en OS X El Capitan kreeg ik last van pagina's die niet laden op Tweakers.net (ook alleen Tweakers.net). Mijn standaard configuratie was als volgt:

IP: DHCP assigned (192.168.1.x)
DNS: DHCP assigned (192.168.1.1 -> router welke de ISP (Solcon) dns servers gebruikte)
Gateway: DHCP assigned (192.168.1.1)

Daarna heb ik een aantal dingen geprobeerd om het probleem te verhelpen, zo heb ik geprobeerd om de DNS servers van Google te gebruiken (zowel rechtstreeks in het apparaat als in de router) en verschillende webbrowsers. Geen van deze dingen heeft toen het probleem opgelost, en ik heb het er maar bij gelaten.

Wel een vreemd verschijnsel: via een VPN van een andere locatie naar huis (OpenVPN in de router) en het gebruik van de DNS server van de router op dat moment had ik het probleem niet.

[DJVG]

xh3adshotx schreef op zondag 03 januari 2016 @ 14:08:
[...]


Destijds gebruikte ik een Asus AC68u in combinatie met een iPhone, iPad, MacBook Air en een Windows desktop. Pas na de update naar iOS 9 en OS X El Capitan kreeg ik last van pagina's die niet laden op Tweakers.net (ook alleen Tweakers.net). Mijn standaard configuratie was als volgt:

IP: DHCP assigned (192.168.1.x)
DNS: DHCP assigned (192.168.1.1 -> router welke de ISP (Solcon) dns servers gebruikte)
Gateway: DHCP assigned (192.168.1.1)

Daarna heb ik een aantal dingen geprobeerd om het probleem te verhelpen, zo heb ik geprobeerd om de DNS servers van Google te gebruiken (zowel rechtstreeks in het apparaat als in de router) en verschillende webbrowsers. Geen van deze dingen heeft toen het probleem opgelost, en ik heb het er maar bij gelaten.

Wel een vreemd verschijnsel: via een VPN van een andere locatie naar huis (OpenVPN in de router) en het gebruik van de DNS server van de router op dat moment had ik het probleem niet.

Is het probleem altijd reproduceerbaar? Krijg je het bijv als je 10 keer de pagina laad 5 keer of is het alleen als je voor het eerst van de dag tweakers.net opent? Als het vaker is, is het vaker binnen 1 minuut? Heb je het probleem ook op andere domeinen van tweakers zoals gathering.tweakers.net of ic.tweakimg.net?

Edit:

Eens gekeken die de headers van tweakers.net teruggeeft en een aantal headers staan er dubbel in:


rfc2616 zegt hier het volgende over:

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

Ook hierbij weet ik niet of het een probleem is bij Apple browsers, maar het lijkt erop dat dit niet volgende de specificatie gebeurd. Mogelijk dat dit gebeurd omdat headers door Apache en Varnish geset worden?

Edit 2:
Misschien dat het mogelijk is om even het IP van 1 iemand die er problemen mee heeft door te sturen aan iemand bij tweakers die even wat kan rondcatten om te kijken of er verbindingen worden afgebroken? Het is jammer dat safari zo weinig informatie teruggeeft over wat er precies niet lukt. Het lukt mij ook niet om het probleem te reproduceren met (de wat oudere) iPhone 3GS en iPad 2.

[ Voor 37% gewijzigd door DJVG op 03-01-2016 14:40 ]

[qless]

Ik heb het probleem hier ook, via iPhone 6s en WiFi op een Telenet lijn met IPv6

[Verwijderd]

Heb het probleem hier ook, iPhone 5S, Ziggo IPv4. Heb er eens per 2 weken een minuut of 2 last van.

[sdekker]

Ik heb het ook - iPhone 6, Wifi via xs4all fiber, Safari. Gebeurt zeer regelmatig. Moet dan 2, 3, 4 of 5 keer een refresh doen en dan komt de pagina wel binnen.

[xh3adshotx]

DJVG schreef op zondag 03 januari 2016 @ 14:23:
[...]


Is het probleem altijd reproduceerbaar? Krijg je het bijv als je 10 keer de pagina laad 5 keer of is het alleen als je voor het eerst van de dag tweakers.net opent? Als het vaker is, is het vaker binnen 1 minuut? Heb je het probleem ook op andere domeinen van tweakers zoals gathering.tweakers.net of ic.tweakimg.net?

Nee, bij mij trad het probleem willekeurig op. Soms was het na een normale refresh (dus niet legen van de cache o.i.d.) in 1x opgelost, de andere keer moest ik de pagina een aantal keer refreshen. Voor zover ik heb kunnen constateren was het alleen op tweakers.net en gathering.tweakers.net, maar ik heb niet echt op tweakimg.net gelet.

Op dit moment heb ik er geen last meer van (sinds de overstap op de Netgear R7000)

[Whatson]

Hier af en toe hetzelfde probleem (TP-Link WR1043ND op OpenWRT, iPhone 6 op iOS 9.2)

[ Voor 14% gewijzigd door Whatson op 03-01-2016 19:28 ]

[TomPlant0]

Zojuist aangepast. MRU aangepast naar meerdere verschillende waardes. Helaas heeft dit geen effect en blijft het probleem bestaan. Blij om te horen dat er toch meer mensen zijn die dit probleem hebben. Het is inderdaad apart. Ik zal straks met wireshark even een test doen en kijken wat voor headers ik krijgt.

[TomPlant0]

DJVG schreef op zondag 03 januari 2016 @ 14:23:
[...]
Eens gekeken die de headers van tweakers.net teruggeeft en een aantal headers staan er dubbel in:
[afbeelding]

rfc2616 zegt hier het volgende over:

[...]


Ook hierbij weet ik niet of het een probleem is bij Apple browsers, maar het lijkt erop dat dit niet volgende de specificatie gebeurd. Mogelijk dat dit gebeurd omdat headers door Apache en Varnish geset worden?

Edit 2:
Misschien dat het mogelijk is om even het IP van 1 iemand die er problemen mee heeft door te sturen aan iemand bij tweakers die even wat kan rondcatten om te kijken of er verbindingen worden afgebroken? Het is jammer dat safari zo weinig informatie teruggeeft over wat er precies niet lukt. Het lukt mij ook niet om het probleem te reproduceren met (de wat oudere) iPhone 3GS en iPad 2.

Zojuist even op mn macbook gekeken en zie daar hetzelfde. Zie onderstaande afbeelding;

[Brad Pitt]

Heb hier ook op Android, wel Ziggo (gebridged, Asus ac66).

[ZpAz]

Zat er ook al eens aan te denken om dit aan te kaarten, maar het gebeurt dus ook bij anderen. Heb dit hier thuis op mijn WiFi soms.

[ Voor 47% gewijzigd door ZpAz op 03-01-2016 21:54 ]

[TomPlant0]

Om nog even wat antwoorden te geven op ACM.

ACM schreef op zondag 03 januari 2016 @ 10:54:
[...]

Dus je hebt het alleen op je Wifi thuis?

Dat is correct. Ik heb het alleen thuis. Het doet zich ook alleen voor op mijn iPhone 6S. Op mijn andere apparaten heb ik hier geen last van. Alles is verder update-to-day. Mijn router runt de laatste firmware. De router-modem van ziggo stuurt al het verkeer door naar poort 1. Router functie op de modem heeft Ziggo uitgezet.

[...]

Hoe 'gebruik' je die? Want beide ip-adressen horen gewoon een werkende Tweakers.net te geven. Als je echter het ip-adres zelf in je browser intikt, dan zal je inderdaad een melding krijgen dat je een onbekende hostname hebt opgevraagd. Maar op zich is dat ook een bevestiging dat je goed bij ons uitkwam

Simpel. Ik voer in de browser http://213.239.154.20 in en krijg dan inderdaad een host error.

[...]

Ik vind dat een interessante conclusie, aangezien geen medewerkers van Tweakers in dat topic hebben gereageerd. Aangezien iPhone+Safari een tot de grootste browsers op Tweakers behoort, zijn we wel degelijk bereid daar moeite in te steken. Maar wij kunnen niets aan netwerkproblemen doen, tenzij het ons stukje van het Internet is.

Als ik het zo rond lees dan is het niet alleen iPhone i.c.m. Safari. Ik zal ook dat er gebruikers zijn met Andriod die hier last van hebben. Of het door de dubbele waarden komt in de headers van tweakers.net geen idee.

Ik heb een app gevonden die de header kan uitlezen en krijg dan ook net als op mijn MacBook dubbele waardes in de waardes. header. Zie screenshot hier onder:

http://i.imgur.com/4qpI3ib.jpg

[Z-Dragon]

Ik heb hetzelfde probleem al enige tijd (iOS 9). Alleen met T.net zover ik gemerkt heb. Alleen Wi-Fi of alleen 4G geeft geen problemen, maar met beide om de haverklap de genoemde fout.

[jordi1345]

Ook ik ondervind hier last van op mijn iPhone 5s, weet alleen niet zeker of het alleen gebeurt als ik op mijn Wi-Fi(Ziggo) zit.

[xbeam]

wat mij opvalt is dat MTU van tweakers minder is dan 1500 Als ik op mijn router de MTU ( kpn glasvezel ) verlaag naar 1492 dan kan ik geen enkele website laden behalve Tweakers.net die werkt dan wel.

Het lijkt mij dan dat tweeakters met lagere MTU werkt. Misschien is dat een probleem?
Zoveel verstand heb ik er ook niet van.

http://www.letmecheck.it/mtu-test.php
het ip van tweakers (213.239.154.20)

From the tests we did, we can assume that 1472 bytes is the largest unfragmented packet size

Zoals je kan is deze kleiner de 1500 die standaard is.

[ Voor 32% gewijzigd door xbeam op 04-01-2016 01:10 ]

[The Fatal]

hier ook problemen op een 5S icm Safari.
Via het Ziggo netwerk, modem in bridge, Mikrotik router met wifi.
Vaak na meerdere keren refreshen werkt het wel. Maar komt regelmatig voor.
Via 4G lijk ik er minder last van te hebben, maar is niet uitgesloten!

[ Voor 40% gewijzigd door The Fatal op 04-01-2016 00:28 ]

[GuntherDW]

xbeam, MTU heeft er niet zoveel mee te maken, buiten als je PMTU discovery niet goed functioneert. 1492 is een standaard MTU voor mensen die op DSL zitten,

Het feit dat je absoluut geen websites meer kan laden buiten tweakers toont aan dat je eens je interne netwerk mag nakijken (of richting je ISP).

[xbeam]

GuntherDW schreef op maandag 04 januari 2016 @ 00:37:
xbeam, MTU heeft er niet zoveel mee te maken, buiten als je PMTU discovery niet goed functioneert. 1492 is een standaard MTU voor mensen die op DSL zitten,

Het feit dat je absoluut geen websites meer kan laden buiten tweakers toont aan dat je eens je interne netwerk mag nakijken (of richting je ISP).

Ik snap niet wat je bedoelt met dit toont aan dat je interne netwerk mag na kijken ?

Mtu van 1492 komt niet door dsl maar door de PPPoE over vlan. PPPoE kan niet gelijk zijn aan de mtu van de vlan waar hij over gaat. 1492+8 is 1500 (de vlan snoept 8bit van je pakket grote af.)

Waardoor je router mss clamping moet gaan toepassen. omdat het verkeer altijd 1500 moet zijn. Als je PPPoE op 1492 draait dan gaat je firewall deze PPPoE Paketjes via mss clamping opdelen en aan elkaar plakker tot pakketjes van 1500 (kost extra cpu en snelheid) als je zonder mssclamping websites gaat opvragen met een mtu van 1492 is het niet kunnen opvragen van sites normaal gedrag .

Ik zou niet weten wat ik in mijn interne netwerk moet nakijken? Misschien begrijp is iets niet goed en kan je me helpen.

Als tweakers pakketjes verstuurt die kleiner zijn dan verwacht 1472 kan dit volgens mij miscommunicatie opleveren met als resultaten dat de pagina niet geladen kan worden. Omdat pmtu dan soms problemen heeft met de firewall en dan juist alle pakketjes dropt.

Dit is hoe ik het begrijp maar nogmaals ik ben geen expert.

[ Voor 8% gewijzigd door xbeam op 04-01-2016 01:51 ]

[Illusion]

Ik heb er ook last van iphone 6, ios 9.2. Maar pas sinds een maand ofzo? Dacht eerst dat het aan mijn fritzbox 7490 icm telfort vdsl lag, maar had er afgelopen week ook op een public wifi last van. (En die was verder superstabiel)

[gastje01]

Ik heb er ook last van op een iPhone 6S, laatste versie iOS. Zit op een glaslijn met fixed IP. Spul wordt verdeeld door een AirPort extreme. Op 4G doet het probleem zich niet voor. Het probleem lijkt niet per se reproduceerbaar, soms kan ik meerdere pagina's probleemloos opvragen, soms lukt het meerdere malen niet.

Ben vooral nieuwsgierig waar het aan ligt, wie weet leer ik er nog iets van :-)

[Kees]

DJVG schreef op zondag 03 januari 2016 @ 10:26:
Buiten het feit dat de nameservers van Tweakers niet goed geconfigureerd zijn om te antwoorden over TCP via IPv6 (geen vereiste opzich want pakketjes zijn kleiner dan 512B):
En is er iemand die IPv6 gebruikt die dit probleem heeft?

Dit zou natuurlijk een keuze kunnen zijn, maar kan zo 123 niet bedenken welke.

Dat ligt aan de loadbalancers die wij gebruiken, ik hoop dat dat met de nieuwe loadbalancers beter gaat. Opzich staan mijn firewall configs wel goed, maar die loadbalancer doet raar

Maar een 'verbroken netwerkverbinding' heeft niet echt iets met DNS te maken ben ik bang, dan zou je een 'kan de naam niet resolven' oid krijgen.

Daarbij valt het op dat de waardes in het SOA record afwijken van de recommended waarde:

SOA TTL van 300 terwijl 3600 wordt geadviseerd, meh, maakt niks uit.
Wat wel interessant is zijn de refresh, retry, expire, minimum waarde, ik weet niet wat de reden is geweest voor een refresh/retry van 300 seconden maar dit heeft geen enkele waarde en zorgt alleen maar voor onnodige bandbreedte/load op DNS slaves. De expire waarde staat dan op "maar" 10 dagen waarbij meer dan 14 dagen geadviseerd wordt. We moeten er voor het gemak maar van uit gaan dat Tweakers DNS fouten binnen 10 dagen kan oplossen in het ergste geval zijn ze na 10 dagen onbereikbaar.
De minimum waarde staat op 300, opzich prima aangezien ze alle records publishen met een TTL van 300, o nee toch niet:

Dit staat expres zo zodat de (transip) slaves elke 5 minuten checken of er wijzigingen zijn zodat ik niet een jaar op een dns wijziging hoef te wachten Helaas ondersteunen ze geen notify zodat ik het op deze manier moet doen.

Nu is dit natuurlijk geen probleem, 60 seconden is niet zo gek voor een dergelijke opstelling.

Maaarr, al deze factoren bij elkaar betekend wel dat bijna elke request opnieuw gevalideerd moet worden door de nameservers van Tweakers of dat een cache ergens op het pad tussen je browser en de nameservers van Tweakers een antwoord invalideert terwijl je het antwoord opvraagt, in theorie zou het dus mogelijk zijn dat je op 1 moment het A record van tweakers.net wilt opvragen terwijl die niet beschikbaar is en er dus voor zorgt dat je browser tweakers.net niet kan vinden.

Willen ze bij Tweakers het liefst elke query zelf afhandelen? Want die nameservers moeten serieus veel queries aan het afhandelen zijn met deze opstelling, onnodig.
Ik weet natuurlijk niet of dit er mee te maken heeft, daarvoor heb ik het probleem nooit echt onderzocht (wel tegengekomen in het verleden) maar wie weet stuurt dit iemand in de juiste richting

Zoals ACM al opmerkte; dat is voor GSLB, en ja we handelen op die manier vrij veel requests af op de nameservers

Bonus:
Het TXT record met de SPF definitie heeft dan wel weer een TTL van een dag en heeft geen policy (?all, zijn er medewerkers misschien met een @tweakers.net adres die mail afleveren bij MTA van Ziggo oid?) dus misschien draaien ze nog in test mode of durven ze en -all nog niet aan :

De vrijwilligers hebben ook allemaal een @tweakers.net mailadres, maar mailen niet altijd/allemaal via onze mailservers (meestal niet zelfs ). Dus krijg je vrijwilligers die hun @tweakers.net mail afleveren bij de MTA van ziggo inderdaad. Verder moet je bijna een SPF record hebben om met google te kunnen mailen, en je ip moet dan in die lijst voorkomen als je bv een mailinglist hebt ('normale mailtjes' van medewerkers gaat wel goed, password reset mailtjes e.d. niet).

Dus vandaar die SPF definitie expres zonder policy

---

Verder is dit probleem voor ons zeer lastig om te reproduceren, we hebben zelf geen iphones en de medewerkers die wel een iphone hebben ervaren deze problemen niet. We zijn dus afhankelijk van jullie Maar we houden het zeker in de gaten (persoonlijk hoop ik dat het met nieuwe loadbalancers opgelost is)

[DJVG]

Kees schreef op maandag 04 januari 2016 @ 09:37:
[...]

Dat ligt aan de loadbalancers die wij gebruiken, ik hoop dat dat met de nieuwe loadbalancers beter gaat. Opzich staan mijn firewall configs wel goed, maar die loadbalancer doet raar

Maar een 'verbroken netwerkverbinding' heeft niet echt iets met DNS te maken ben ik bang, dan zou je een 'kan de naam niet resolven' oid krijgen.

Het lastige is, vind ik, dat er weinig tot geen echte informatie is. De melding die safari geeft omschrijft niet wat er nou echt verkeerd gaat.
Dat is eigenlijk de reden waarom ik naar DNS keek en die dubbele HTTP headers. Ik denk ook dat het probleem ergens anders aan ligt, maar het is zo vaag dat ik graag niks uitsluit

Kees schreef op maandag 04 januari 2016 @ 09:37:
[...]

Dit staat expres zo zodat de (transip) slaves elke 5 minuten checken of er wijzigingen zijn zodat ik niet een jaar op een dns wijziging hoef te wachten Helaas ondersteunen ze geen notify zodat ik het op deze manier moet doen.

Duidelijk verhaal, zou ze sieren dat te verbteren.

Kees schreef op maandag 04 januari 2016 @ 09:37:
[...]
Zoals ACM al opmerkte; dat is voor GSLB, en ja we handelen op die manier vrij veel requests af op de nameservers

Ik kan mij ook niet voorstellen dat die ttl van 60 een probleem zou zijn, dit wordt veel toegepast en kent geen bekende problemen, was enkel stukje oberservatie.

Kees schreef op maandag 04 januari 2016 @ 09:37:

[...]

De vrijwilligers hebben ook allemaal een @tweakers.net mailadres, maar mailen niet altijd/allemaal via onze mailservers (meestal niet zelfs ). Dus krijg je vrijwilligers die hun @tweakers.net mail afleveren bij de MTA van ziggo inderdaad. Verder moet je bijna een SPF record hebben om met google te kunnen mailen, en je ip moet dan in die lijst voorkomen als je bv een mailinglist hebt ('normale mailtjes' van medewerkers gaat wel goed, password reset mailtjes e.d. niet).

Dus vandaar die SPF definitie expres zonder policy

Eens en was ook zeker geen onderdeel van dit probleem. zat gewoon wat rond te graven

[Kees]

Die dubbele headers kan ik trouwens nergens reproduceren (het zou een ander probleem kunnen oplossen). Waar zie je die langs komen?

code:

$ wget -O/dev/null http://tweakers.net -S -q --header "User-Agent:Mozilla/5.0 ...[knip]"
  HTTP/1.1 202 Accepted
  Server: Apache
  X-Tweakers-Server: pontus
  Set-Cookie: TnetID=[knip]
  Expires: -1
  Cache-Control: private, max-age=0
  P3P: CP="ALL DSP COR CURa ADMa DEVa HISa OUR STP UNI STA"
  Vary: Accept-Encoding
  Content-Type: text/html; charset=ISO-8859-15
  Content-Length: 3297
  Accept-Ranges: bytes
  Date: Mon, 04 Jan 2016 09:14:39 GMT
  X-Varnish: 2083512788
  Age: 0
  Via: 1.1 varnish
  Connection: keep-alive

Hm, blijkbaar komt het wel voor als ik inlog, dat gaan we even uitzoeken

[ Voor 18% gewijzigd door Kees op 04-01-2016 10:20 ]

[TomPlant0]

Het is inderdaad jammer dat het op de redactie niet na te bootsen is. Ondanks dat heb ik toch net even de tijd genomen om een video op mijn iPhone op te nemen Waar jullie het zelf in kunnen zien. Dit geeft natuurlijk een achtergrond informatie over wat er fout gaat. YouTube: Tweakers net safari iPhone 6S

Betreft de header met dubbele waardes. Die krijg ik ook als ik niet ingelogd ben op tweakesr.net op mijn iPhone. Ik check de headers met de app 'iCurlHTTP'. Gratis in de app store te downloaded.

Update: Zelfs als ik 4G gebruik krijg ik dubbele waardes in de header.

[ Voor 6% gewijzigd door TomPlant0 op 04-01-2016 10:39 ]

[Breezers]

TomPlant0 schreef op maandag 04 januari 2016 @ 10:34:
Het is inderdaad jammer dat het op de redactie niet na te bootsen is. Ondanks dat heb ik toch net even de tijd genomen om een video op mijn iPhone op te nemen Waar jullie het zelf in kunnen zien. Dit geeft natuurlijk een achtergrond informatie over wat er fout gaat. YouTube: Tweakers net safari iPhone 6S

Betreft de header met dubbele waardes. Die krijg ik ook als ik niet ingelogd ben op tweakesr.net op mijn iPhone. Ik check de headers met de app 'iCurlHTTP'. Gratis in de app store te downloaded.

Precies zoals het filmpje.

Als je dan 1 of 2 x pagina terug drukt (pijltje links onder) of een paar keer refresh drukt, dan krijg je meestal wel het item te zien.

[ACM]

Die dubbele headers gaan geen connectieproblemen veroorzaken. Sterker nog, je moet een goed werkende connectie hebben om die headers te kunnen krijgen

Dat is overigens ondertussen opgespoord en de fix komt morgen met onze reguliere release mee.

Het zou mij enorm verbazen als dat de connectieproblemen zou oplossen, dus ga er niet van uit dat dat daarmee opgelost is.

[Kek]

Ik heb hetzelfde probleem op mijn iphone 5s (met laatste ios) maar nooit op de ipad, of mijn macs met safari... allemaal op dezelfde wifi/bekabeld verbinding

[Brahiewahiewa]

xbeam schreef op maandag 04 januari 2016 @ 01:27:
...Als tweakers pakketjes verstuurt die kleiner zijn dan verwacht 1472 kan dit volgens mij miscommunicatie opleveren met als resultaten dat de pagina niet geladen kan worden. Omdat pmtu dan soms problemen heeft met de firewall en dan juist alle pakketjes dropt.

Dit is hoe ik het begrijp maar nogmaals ik ben geen expert.

Onzin. Pakketjes kleiner dat de PMTU moeten altijd doorkomen.

[Kees]

Ik heb wat dingen aangepast (waardoor ik bang ben dat server not responding weer terug gaat keren). Eens zien of dat helpt..

[TomPlant0]

Ik ga het eens testen Kees.

Update Helaas, bij mij blijven de meldingen bestaan. Ik moet wel zeggen dat ik de melding nu meer krijg dan normaal. Zie video: YouTube: YouTube.

[ Voor 78% gewijzigd door TomPlant0 op 04-01-2016 15:11 . Reden: update ]

[DJVG]

Kees schreef op maandag 04 januari 2016 @ 10:17:
Die dubbele headers kan ik trouwens nergens reproduceren (het zou een ander probleem kunnen oplossen). Waar zie je die langs komen?

code:

$ wget -O/dev/null http://tweakers.net -S -q --header "User-Agent:Mozilla/5.0 ...[knip]"
  HTTP/1.1 202 Accepted
  Server: Apache
  X-Tweakers-Server: pontus
  Set-Cookie: TnetID=[knip]
  Expires: -1
  Cache-Control: private, max-age=0
  P3P: CP="ALL DSP COR CURa ADMa DEVa HISa OUR STP UNI STA"
  Vary: Accept-Encoding
  Content-Type: text/html; charset=ISO-8859-15
  Content-Length: 3297
  Accept-Ranges: bytes
  Date: Mon, 04 Jan 2016 09:14:39 GMT
  X-Varnish: 2083512788
  Age: 0
  Via: 1.1 varnish
  Connection: keep-alive

Hm, blijkbaar komt het wel voor als ik inlog, dat gaan we even uitzoeken

Dit was op sommige pagina's wel en niet te zien, op de 404 kreeg ik hem bijvoorbeeld ook niet te zien, maar op de frontpage en ingelogd wel. Sowieso zou dit niet een dergelijk probleem moeten veroorzaken.

[Kees]

TomPlant0 schreef op maandag 04 januari 2016 @ 15:00:
Ik ga het eens testen Kees.

Update Helaas, bij mij blijven de meldingen bestaan. Ik moet wel zeggen dat ik de melding nu meer krijg dan normaal. Zie video: YouTube: YouTube.

Jammer. Dat was een optie die een RST stuurde naar onbekende connecties, ik had gehoopt dat het dit probleem zou veroorzaken/oplossen.

Het probleem dat ik in het netwerkverkeer zie is basically dat de connectie ineens gereset word, soms stuurt de iphone wel gewoon een request, en een andere keer niet en reset de loadbalancer na 2s ineens de verbinding. Ik heb geen idee waar dit door komt, en aangezien we die loadbalancers ook aan het vervangen zijn denk ik niet dat het zinnig is om hier heel veel tijd in te steken.

[TomPlant0]

Dan lijkt het probleem toch gevonden te zijn. Kan je aangeven wanneer deze eventueel vervangen zal gaan worden ? Dan weet ik hoe lang het probleem nog blijft ongeveer.

[xbeam]

Brahiewahiewa schreef op maandag 04 januari 2016 @ 13:22:
[...]

Onzin. Pakketjes kleiner dat de PMTU moeten altijd doorkomen.

Ik heb ook niet zelf verzonnen maar schijnt toch echt wel een bekend probleem te zijn.
Staat gewoon als bekend probleem bij wiki
Wikipedia: Path MTU Discovery

Many network security devices block all ICMP messages for perceived security benefits,[6] including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection.


A workaround used by some routers is to change the maximum segment size (MSS) of all TCP connections passing through links with MTU lower than the Ethernet default of 1500. This is known as MSS clamping.[9]

[ Voor 48% gewijzigd door xbeam op 04-01-2016 17:37 ]

[Brahiewahiewa]

Ondertussen way off topic, maar toch:

Ik bestrijd niet het statement dat pmtu-discovery wel eens misgaat
En ik bestrijd ook niet dat je dat met mss-clamping op kunt lossen.
Maar ik bestrijd wel jouw analyse dat een te kleine mtu bij tweakers.net voor connectieproblemen zou kunnen zorgen.

Überdem heeft tweakers.net helemaal geen kleinere mtu:

C:\>ping -l 1472 tweakers.net

Pinging tweakers.net [213.239.154.20] with 1472 bytes of data:
Reply from 213.239.154.20: bytes=1472 time=12ms TTL=57
Reply from 213.239.154.20: bytes=1472 time=12ms TTL=57
Reply from 213.239.154.20: bytes=1472 time=12ms TTL=57
Reply from 213.239.154.20: bytes=1472 time=13ms TTL=57

Ping statistics for 213.239.154.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 13ms, Average = 12ms

[xbeam]

Zoals ik eerder typte ik ben geen expert ik probeer dit soort dingen te begrijpen. In de hoop dat er ik iets van kan leren.

Het enige wat ik constateerde is dat tweakers.net een afwijkende mtu heeft. Waardoor ik deze met een kleiner mtu dan 1500 (1492) nog gewoon nog zonder problemen kan opvragen. Zonder mssclamping te gebruiken.. Terwijl andere site het laten afweten en mijn conclusie is dat zij dan een mtu van 1500 hanteren en tweakers niet.

Zo kom ik tot de conclusie dat ik 1500 naar tweakers stuur deze is voor tweakers te groot en die sturen mij terug icmp(to big)
Deze icmp kan dus soms verkeer geïnterpreteerd worden door je/mijn firewall (het bekende probleem) waardoor de verbinding gedropt wordt (de meldingen Connetion lost in de browser). Dat Kan ook een verklaring zijn van het onvoorspelbare gedrag en waardoor het niet te reproduceren is. Er zit geen regelmaat in de verkeerde icmp interpretatie van een firewall.


Waar kan jij nu zien dat tweakers geen kleinere mtu heeft jij stuurt nu toch juist een kleiner mtu uit 1472 inplaats van standaard 1500 en je krijgt zonder fragmentatie antwoord. Dat is toch normaal als tweakers een mtu 1472 heeft in plaats van 1500. Je moet toch een Ping doen met een mtu van 1500? Want dat is de mtu van je isp en router en andere webhosters. Of sla ik de plank nu helemaal mis?

[ Voor 47% gewijzigd door xbeam op 05-01-2016 01:36 ]

[Brahiewahiewa]

Ja. Een ICMP packet heeft een IP header van 20 bytes en een ICMP header van 8 bytes.
1472 + 20 + 8 = 1500

[Gomez12]

Z-Dragon schreef op zondag 03 januari 2016 @ 23:09:
Ik heb hetzelfde probleem al enige tijd (iOS 9). Alleen met T.net zover ik gemerkt heb. Alleen Wi-Fi of alleen 4G geeft geen problemen, maar met beide om de haverklap de genoemde fout.

Gewoon maar even een gedachte van een niet iPhone gebruiker , maar kan het niet zoals hier beschreven is een probleem zijn van en wifi en 4g aan hebben staan? Mijn samsung kent dan een modus als enhance internet oid (exacte naam weet ik even niet) waarbij hij als hij dus wifi te langzaam vind hij 4g bij wil gaan schakelen en ik meen dat de iPhone ook zo'n functie heeft.

Dus dat als je telefoon je wifi even te traag vind vanwege reden x/y/z dat hij via een andere verbinding verder probeert te gaan en dat dat halve verkeer via verbinding 1 en half verkeer via verbinding 2 niet lekker werkt op de loadbalancers.
En als je telefoon dan weer een beetje bedaard is met wel / niet aan/uit switchen van 4g dat je telefoon dan gewoon weer alles via 1 verbinding stuurt en dat het weer goed werkt, totdat je torrents / netflix / ftp weer een opleving krijgt en je telefoon besluit dat het weer tijd is voor enhanced modus met 4g erbij.

Het is maar een gedachte...

[Illusion]

Gomez12 schreef op dinsdag 05 januari 2016 @ 01:38:
[...]

Gewoon maar even een gedachte van een niet iPhone gebruiker , maar kan het niet zoals hier beschreven is een probleem zijn van en wifi en 4g aan hebben staan? Mijn samsung kent dan een modus als enhance internet oid (exacte naam weet ik even niet) waarbij hij als hij dus wifi te langzaam vind hij 4g bij wil gaan schakelen en ik meen dat de iPhone ook zo'n functie heeft.

Dus dat als je telefoon je wifi even te traag vind vanwege reden x/y/z dat hij via een andere verbinding verder probeert te gaan en dat dat halve verkeer via verbinding 1 en half verkeer via verbinding 2 niet lekker werkt op de loadbalancers.
En als je telefoon dan weer een beetje bedaard is met wel / niet aan/uit switchen van 4g dat je telefoon dan gewoon weer alles via 1 verbinding stuurt en dat het weer goed werkt, totdat je torrents / netflix / ftp weer een opleving krijgt en je telefoon besluit dat het weer tijd is voor enhanced modus met 4g erbij.

Het is maar een gedachte...

Dat heet bij een Iphone "wifi-Assist". Staat bij mij al tijden uit, en ik heb het probleem nog steeds.

Ik blijf het wel typisch vinden dat het dus alleen bij iphone's is, i.c.m. wifi, en voorzover ik zie ook alleen bij IOS 9 en nieuwer?
Je zou dan eerder aan een obscure IOS bug denken ipv aan iets in het serverpark van tweakers.

[Gomez12]

Illusion schreef op dinsdag 05 januari 2016 @ 02:11:
[...]
Dat heet bij een Iphone "wifi-Assist". Staat bij mij al tijden uit, en ik heb het probleem nog steeds.

Ok, het was maar een gedachte

Ik blijf het wel typisch vinden dat het dus alleen bij iphone's is, i.c.m. wifi, en voorzover ik zie ook alleen bij IOS 9 en nieuwer?
Je zou dan eerder aan een obscure IOS bug denken ipv aan iets in het serverpark van tweakers.

Het probleem is meer dat er volgens mij geen echte lijn in te zien is. Dus geen lijn qua IOS 9, iPhone op zichzelf.

bijv :
Tweakers laadt soms niet
Dat is een mac die het heeft
Ben ik de enige?
Daar is het juist weer opgelost met iOS 9

francoski schreef op zondag 03 januari 2016 @ 13:48:
Ik heb hier ook het probleem, op een Android met
. Heb inderdaad twee routers staan. Zal eens gaan kijken naar die MTU size.

En daar op een android device.

Verwijderd schreef op zondag 03 januari 2016 @ 16:11:
Heb het probleem hier ook, iPhone 5S, Ziggo IPv4. Heb er eens per 2 weken een minuut of 2 last van.

En op een iPhone 5S die bij andere juist wel weer werkt.

Illusion schreef op maandag 04 januari 2016 @ 01:51:
Ik heb er ook last van iphone 6, ios 9.2. Maar pas sinds een maand ofzo? Dacht eerst dat het aan mijn fritzbox 7490 icm telfort vdsl lag, maar had er afgelopen week ook op een public wifi last van. (En die was verder superstabiel)

En deze heeft het sinds een maand ofzo terwijl anderen er eerder last van hadden.

En dan heb je nog mensen die het alleen thuis hebben, terwijl anderen het ook op public wifi hebben.

Persoonlijk zou ik t.net als fout vermoeden ( te verspreid anders de meldingen) alleen dan waarschijnlijk wel op exotische setting gebied, wat alleen maar onder heel aparte omstandigheden optreed.
Wat ik alleen wel een heel wonderlijk vind is :

xtr3me schreef op zondag 03 januari 2016 @ 11:24:
Dit probleem heb ik dus ook, goed om te horen dat ik niet de enige ben.
9 van de 10 keer gebeurd dit inderdaad op tweakers.net (+ safari iOS) en als ik het daarna met chrome (iOS) probeer werkt het wel.

Ik dacht dat Apple op iOS alleen browsers als "windowdressing" toestond en dat de netwerkstack etc allemaal gebruikt moest worden van iOS oftewel dat Chrome hetzelfde probleem zou moeten hebben, want geen verbinding kunnen maken duidt op netwerkstack probleem.

Wellicht dat er iemand is die kan proberen of als die het heeft met safari of het weg is met chrome browser (wat het volgens mij niet zou moeten zijn)

Dus ik denk idd dat t.net er voorlopig goed aan doet om het eerst te gokken op nieuwe loadbalancers of er moet iemand een soort van inventarisatie gaan maken want voorlopig lijken het voornamelijk incidentele meldingen te zijn die geen lijn lijken te hebben.

[sebasmac]

Haha, en ik maar denken mm zal wel aan mij liggen... Ik heb hetzelfde probleem, wat wel opvalt is het volgende:

Je gaat naar de frontpage, dan klik je een artikel aan dan echt binnen een paar milliseonce krijg je die netwerk error, vreemd denk je dan... Maar als je dan op vorige klikt en waarbij je nu verwacht de frontpage weer te krijgen, het nieuws artikel ging mis. Krijg ik dan wel opeens het artikel, dus het lijkt erop:

Frontpage -> nieuwsartikel -> redirect....

De redirect geeft aan page not found, of network error. en zodra je de pagina terug gaat zit je op het nieuwsartikel, maar de redirect is er opeens uit. vreemd....

Waar ik overigens ook last van heb is dat zeker dehelft van de topic cats niet meer laden op mijn iPhone, ik zal vanavond even en screenshot hiervan posten. Ik kan op me iPhone 5S iOS9.2 dus geen forums meer openen.

[qless]

Dat had ik daarstraks ook, nieuws item aangeklikt, ik zie het nieuwsitem een fractie van seconden en dan de error pas.

[TomPlant0]

qless schreef op dinsdag 05 januari 2016 @ 16:29:
Dat had ik daarstraks ook, nieuws item aangeklikt, ik zie het nieuwsitem een fractie van seconden en dan de error pas.

Dat ook inderdaad. Dan denk je de pagina binnen te hebben. Uit eindelijk blijkt dat dan toch niet zo.

[MsG]

Ik krijg op Android ook regelmatig op wifi hier een connection reset in Chrome. Zal het ook eens in de gaten blijven houden. Had voorheen een oudere Android met de stock AOSP browser ipv Chrome en had toen nooit last. Weet zo uit mn hoofd niet of dat nou alleen om Tweakers ging, mobiel zit ik bijna alleen op Tweakers.

Heb hier een ziggo router en 2 omgebouwde routers als accesspoint, 1 op DD-WRT andere op OpenWRT.

[Z-Dragon]

Even iets rechtzetten. Eerder gaf ik aan dat ik het alleen heb met zowel Wi-Fi als 4G aan, maar niet met alleen Wi-Fi. Dat blijkt niet te kloppen. Met alleen Wi-Fi heb ik het ook. Met alleen 4G heb ik het nog niet gezien. Zo past het "ziektebeeld" hier beter bij dat van anderen.

[Thralas]

Nog even wat zaken rechtzetten, zij het offtopic

xbeam schreef op dinsdag 05 januari 2016 @ 01:03:
Zo kom ik tot de conclusie dat ik 1500 naar tweakers stuur deze is voor tweakers te groot en die sturen mij terug icmp(to big)

De frames zijn aan jouw kant waarschijnlijk groter dan hoe ze bij Tweakers aankomen, jij hebt immers 8 bytes verlies door PPPoE.

Je moet toch een Ping doen met een mtu van 1500? Want dat is de mtu van je isp en router en andere webhosters. Of sla ik de plank nu helemaal mis?

MTU slaat op het aantal bytes dat een ethernetframe als payload (!) kan bevatten. De parameter van 1472 die aan ping werd meegegeven slaat niet op de MTU, maar het aantal bytes dat je als ICMP payload meegeeft. Tel daarbij op 8 bytes ICMP header, 20 bytes IP header en je zit aan 1500. Dat voorbeeld was dus op een verbinding zonder PPPoE, want dat zou je nogmaals 8 bytes kosten. Over PPPoE kun je dus waarschijnlijk enkel ICMP packets met een payload van 1464 bytes versturen.

MTU is daarnaast geen 'eis' waaraan een ethernet frame moet voldoen, maar een maximum. Kleiner is dus nooit een probleem.

MSS clamping interpreteer je ook verkeerd, lees je quote van WIkipedia nog eens:

A workaround used by some routers is to change the maximum segment size (MSS) of all TCP connections passing through links with MTU lower than the Ethernet default of 1500. This is known as MSS clamping.

Dat wat je dacht te lezen - dat de MTU naar 1500 wordt gewijzigd - staat er niet, maar ik begrijp de verwarring

[Illusion]

Nog een aanvulling.. Het probleem doet zich bij mij nog steeds voor (iphone6), zowel op de frontpage als het forum, maar er valt me nog iets op:
** Het gaat in blokken: soms gaat het uren goed, soms ineens een paar minuten non-stop problemen
** Het is bij mij nog niet voorgekomen op de "root".. De standaard frontage gaat altijd goed, net als de "active topics". Soms wil een topic 10x achter elkaar niet laden, ga ik dan naar active topics, dan gaat dat voor mijn gevoel altijd in 1x goed. Zelfde met de frontpage: artikel laden gaat mis, maar frontpage zelf gaat goed.

Misschien toch iets met een cookie/session?

[TomPlant0]

Illusion schreef op maandag 11 januari 2016 @ 13:29:
Nog een aanvulling.. Het probleem doet zich bij mij nog steeds voor (iphone6), zowel op de frontpage als het forum, maar er valt me nog iets op:
** Het gaat in blokken: soms gaat het uren goed, soms ineens een paar minuten non-stop problemen
** Het is bij mij nog niet voorgekomen op de "root".. De standaard frontage gaat altijd goed, net als de "active topics". Soms wil een topic 10x achter elkaar niet laden, ga ik dan naar active topics, dan gaat dat voor mijn gevoel altijd in 1x goed. Zelfde met de frontpage: artikel laden gaat mis, maar frontpage zelf gaat goed.

Misschien toch iets met een cookie/session?

Daar kan ik mij inderdaad ook in vinden. Het gaat inderdaad in blokken en de homepage doet het altijd. O

[ACM]

Illusion schreef op maandag 11 januari 2016 @ 13:29:
De standaard frontage gaat altijd goed, net als de "active topics". Soms wil een topic 10x achter elkaar niet laden, ga ik dan naar active topics, dan gaat dat voor mijn gevoel altijd in 1x goed. Zelfde met de frontpage: artikel laden gaat mis, maar frontpage zelf gaat goed.

Misschien toch iets met een cookie/session?

Er zit alleen geen verschil in hoe cookies/sessies worden behandeld tussen ieder van die pagina's. Er kan/zal wat verschil zitten in advertenties die worden geserveerd, maar dat is pas na dat je onze pagina al binnen hebt gekregen.

Bovendien, als in de netwerken daarachter het probleem zou zitten, dan ligt het helemaal niet aan de communicatie met onze servers en dan is het probleem nog lastiger op te sporen

[Z-Dragon]

Mee eens dat de homepage het altijd doet - bij het kiezen van een artikel is het daarna meteen 'oja'. Van die blokken zou ik niet weten; zo vaak kijk ik ook weer niet op m'n telefoon.

[stijnos1991]

Bij mij wil vraag en aanbod--> alle advertenties niet laden. Verbinding verbroken krijg ik dan. iPad air 2 laatste IOS, OpenWRT en Ziggo in bridge. Ik denk niet dat het aan m'n setup van thuis ligt.

Als ik Vraag en aanbod aanklik en vervolgens op het getal van actieve advertenties wordt de lijst wel geladen... Zeg het maar

Inderdaad alleen op een iPad. Andere apparaten hebben nergens last van. Er zijn hier geen iPhones dus dat kan ik nu even niet testen.

[ Voor 42% gewijzigd door stijnos1991 op 02-02-2016 08:34 ]

[Z-Dragon]

Het ontbreekt mij ook een beetje aan informatie vanuit Tweakers hoe zij van plan zijn onze feedback op te pakken. Ik nader het punt dat ik geen moeite meer doe om Tweakers op m'n telefoon te bezoeken. Toch elke keer hetzelfde liedje...

[Illusion]

Kees schreef op maandag 04 januari 2016 @ 16:09:
[...]

Jammer. Dat was een optie die een RST stuurde naar onbekende connecties, ik had gehoopt dat het dit probleem zou veroorzaken/oplossen.

Het probleem dat ik in het netwerkverkeer zie is basically dat de connectie ineens gereset word, soms stuurt de iphone wel gewoon een request, en een andere keer niet en reset de loadbalancer na 2s ineens de verbinding. Ik heb geen idee waar dit door komt, en aangezien we die loadbalancers ook aan het vervangen zijn denk ik niet dat het zinnig is om hier heel veel tijd in te steken.

De vraag is dus wanneer de loadbalancers vervangen worden. Want tot die tijd heeft het blijkbaar geen prioriteit.

[Kees]

Illusion schreef op dinsdag 02 februari 2016 @ 18:37:
[...]

De vraag is dus wanneer de loadbalancers vervangen worden. Want tot die tijd heeft het blijkbaar geen prioriteit.

Daar ben ik heel erg druk mee bezig. Ik verwacht die toch wel (afhankelijk van de gekozen oplossing en levertijden e.d.) binnen 2 weken de beslissing te nemen en hopelijk binnen 2 maand er live mee te gaan.

[xbeam]

Beste iedereen,

Ik heb nog steeds last van het probleem dat de verbinding met tweakers weg valt tijdens het browsen.

Alleen merk dat dit voornamelijk voorkomt als ik via 5ghz WiFi connect. Op 2,4ghz lijkt het probleem niet voor te komen.

Wat zou het probleem kunnen zijn op interne netwerkt ?