Experiabox verbreekt eigen webserver verbinding

  • 16 februari 2016
  • 14 reacties
  • 756 keer bekeken

Ik heb een probleem met de Experia Box v9 die elke keer na zo'n 500KB gewoon een kill commando geeft

2016/02/16 01:58:29 [info] 14527#0: *5 client prematurely closed connection (104: Connection reset by peer) while sending to client, client: 192.168.2.254, server: localhost.

Dat is leuk als je je eigen foto's online zet. Schijnbaar doet de Experiabox firewall meer dan alleen maar stateful packet inspection.

benader ik de website lokaal dan is er geen probleem en ja de ip is toch echt van de experiabox.


14 reacties

Reputatie 7
Badge +30

HakkaH schreef op 21 feb '16 om 19:10u

hmm leuk een bug die er dus na al die tijd er nog in zit. Ik dacht die allang uit v9 en v10 waren gehaald.



ik dacht dat dit klinklare onzin is. De V10 heeft geen NAT Loopback probleem. Alleen de V9. En ach, als het alleen voor een webservertje is pas je je hosts file toch even aan


HakkaH schreef op 21 feb '16 om 19:10u

Dat is dan jammer want ik kan op dit moment geen ipv6 erop gooien zonder de portomonee open te trekken. En de plan is om uiteindelijk gewoon weer een v8 te gaan bridgen dan ben ik van dit half spul iig af.



Succes!

Robin

hmm leuk een bug die er dus na al die tijd er nog in zit. Ik dacht die allang uit v9 en v10 waren gehaald.

Dat is dan jammer want ik kan op dit moment geen ipv6 erop gooien zonder de portomonee open te trekken. En de plan is om uiteindelijk gewoon weer een v8 te gaan bridgen dan ben ik van dit half spul iig af.

Reputatie 4
Badge +5
Ik heb dit zelf met mijn web server "opgelost" door gebruik te maken van IPv6..., maar ik weet niet of jij dat ook al hebt. Dan heb je geen last van deze bug omdat je geen NAT gebruikt.

Reputatie 4
Badge +5
Ohhhh..., het zijn dus toch interne PC's die hier last van hebben....

Dan is het antwoord simpel en irritant: NAT loopback bug van de experiabox.

En nee..., ik heb de hoop al opgegeven dat KPN dit gaat oplossen ;-(

Nou waar zou ik het anders moeten bekijken? zodra de communicatie op LAN niveau is gaat alles perfect. zodra dat ik het via de externe ip danwel DNS doe krijg de 104 die zegt dat de router (192.168.2.254) de verbinding voortijdig afbreekt.

dus 192.168.2.2/test/file.zip (1 van 100 MB) gaat goed

77.100.100.100/test/file.zip stopt gelijk

mijndns/test/file.zip stopt gelijk

extern heeft niemand er trouwens last van het is dus puur lokale pc's die extern connecten wanneer het gebeurd.

Reputatie 7
Mijn V10 staat constant backups te synchroniseren met een NAS op een andere locatie en ook dat is geen enkel probleem. Ook ik denk dus niet dat de oorzaak voor dit probleem in de Experia Box gezocht moet worden.

Reputatie 4
Badge +5
HakkaH schreef op 20 feb '16 om 14:49u
Fijn dat je mee wilt denken Pontifex. Ik draai PHP-FPM in socket mode.

De webserver ligt direct aan de Experiabox aan een 500/500 verbinding dus snelheid is het probleem niet de server komt ook niet boven de 10% cpu gebruik uit en geheugen is ook bij lange na niet vol.

Met wat andere lui ook gechat gehad op het irc kanaal van nginx en die noemen het gewoon een Man in the Middle attack maar zover wil ik niet gaan, maar het vreemde is juist dat het wordt afgebroken door de router maar de firewall zelf zegt vervolgens er helemaal niets over. Juist omdat het over een LAN niet gebeurt en via een DNS danwel externe IP wel vermoed ik dat de experiabox dus wel degelijk iets doet wat niet hoort.

max_input_time 3600 (vanwege owncloud)

max_execution_time 3600 (vanwege owncloud)

request_terminate_timeout (niet gedefineerd dus standard)

 OK, duidelijk.

Ik vroeg me af: zou het misschien mogelijk zijn dat je als test de PHP-FPM module disabled op de web server, een bestand neerzet van minimaal 1GB (in de root van de web server) en dat dan via HTTP (over Internet) gaat downloaden…

Als dat zou mislukken dan verwacht ik een duidelijke HTTP error code, zowel in de logs als op de (download) client.

In geval het downloaden dan niet afgebroken wordt, en dat verwacht ik eerlijk gezegd, dan hoeven we dus niet meer naar de Experiabox te kijken… Tuurlijk..., niet de firewall op de Experiabox maar bijvoorbeeld de TCP/IP stack op de Experiabox zou fouten kunnen bevatten..., maar dan zou dit forum helemaal vol staan van de klachten. Net als  verwacht ik hier het probleem niet...

Heb je trouwens als test al eens de request_terminate_timeout verhoogt..?

Standaard waardes kunnen soms best wel laag zijn…

 
Reputatie 7
Badge +11
Je zult het toch ergens anders moeten vinden dan in de firewall van de Experia Box, want ik ben er 99% zeker van dat dat niet het probleem is.

Fijn dat je mee wilt denken Pontifex. Ik draai PHP-FPM in socket mode.

De webserver ligt direct aan de Experiabox aan een 500/500 verbinding dus snelheid is het probleem niet de server komt ook niet boven de 10% cpu gebruik uit en geheugen is ook bij lange na niet vol.

Met wat andere lui ook gechat gehad op het irc kanaal van nginx en die noemen het gewoon een Man in the Middle attack maar zover wil ik niet gaan, maar het vreemde is juist dat het wordt afgebroken door de router maar de firewall zelf zegt vervolgens er helemaal niets over. Juist omdat het over een LAN niet gebeurt en via een DNS danwel externe IP wel vermoed ik dat de experiabox dus wel degelijk iets doet wat niet hoort.

max_input_time 3600 (vanwege owncloud)

max_execution_time 3600 (vanwege owncloud)

request_terminate_timeout (niet gedefineerd dus standard)

Reputatie 4
Badge +5
HakkaH schreef op 16 feb '16 om 11:50u
Het staat er volgens mij duidelijk genoeg maar ik zal hetzelfde nogmaals beantwoorden.

1: De experiabox verbreekt de verbinding zoals de access log van de webserver de thuis staat laat zien. Dus foto's die vaak groter zijn 500 KB worden maar deels geladen omdat de experiabox schijnbaar bepaald heeft dat ie genoeg heeft dus de verbinding verbreekt vandaar de 104: connection reset by peer in de log.

2: Nginx 1.8 die ik hier thuis draai om projecten te kunnen testen en voor mijn eigen foto's.

3: alles wat extern dus via de dns danwel de externe ip de webserver benaderd maw zodra het door de experiabox gaat. Zodra ik de webserver lokaal benader gebeurt het niet. Om die reden weet ik dus ook dat de webserver goed is (al was het toen ik bij Ziggo zat ook gewoon goed want het is dezelfde server) en dat het gebeurt wanneer het door de Experiabox gaat.

 Ik heb weinig ervaring met Nginx maar kan je wel vertellen dat “104: Connection reset by peer” geen HTTP error code is.

En dat kan wel van belang zijn als je de oorzaak probeert te vinden…

Het is waarschijnlijk niet primair de web server waarmee de verbinding wordt verbroken…, maar waarschijnlijk de python of PHP framework, al dan niet geladen binnen de web server code.

Je zegt dat over de LAN de fout niet optreedt, en concludeert dat het dus aan de Experiabox moet liggen.

Ik ga hier deels in mee: maar ik vermoed eerder dat het probleem niet in de Experiabox zit maar in het feit dat de WAN verbinding naar de web server veel minder snel is dan de LAN verbinding. En dus dat er een timeout optreedt op een LAN verbinding aanmerkelijk kleiner is dan dat er een timeout optreedt met een langzamere WAN verbinding. 

Heb je PHP-FPM of een python module geladen binnen Nginx?

Zo ja, wat zijn de instellingen van bijv.: max_input_time, max_execution_time, request_terminate_timeout?

My two cents

 
Reputatie 7
Badge +30
Hoi,

Ik heb gisteravond dit geprobeerd om te zien of ik het na kon bootsen, maar dat is mij (nog) niet gelukt.

Wel heb ik dit gevonden, maar het lijkt er op alsof er nog geen antwoord/oplossing is: http://stackoverflow.com/questions/4804822/client-closed-prematurely-connection-while-sending-to-client-in-nginx

Verder denk ik zelf niet dat de Firewall in de Experiabox hier invloed op heeft. Op de V10, werkte de nginx server gewoon, en met de H220N (praktisch gelijk aan de V9) had ik ook geen problemen.

, ?

Robin
Dus...

Het probleem bestaat nog steeds en is eigenlijk mijn vraag sinds wanneer verbreekt een router actief een verbinding? want normaal is het zeker niet en de enige reden die ik kan bedenken waarom de router dat zou doen is door de firewall die aanstaat in de experiabox maar die je niet kan wijzigen.

Het staat er volgens mij duidelijk genoeg maar ik zal hetzelfde nogmaals beantwoorden.

1: De experiabox verbreekt de verbinding zoals de access log van de webserver de thuis staat laat zien. Dus foto's die vaak groter zijn 500 KB worden maar deels geladen omdat de experiabox schijnbaar bepaald heeft dat ie genoeg heeft dus de verbinding verbreekt vandaar de 104: connection reset by peer in de log.

2: Nginx 1.8 die ik hier thuis draai om projecten te kunnen testen en voor mijn eigen foto's.

3: alles wat extern dus via de dns danwel de externe ip de webserver benaderd maw zodra het door de experiabox gaat. Zodra ik de webserver lokaal benader gebeurt het niet. Om die reden weet ik dus ook dat de webserver goed is (al was het toen ik bij Ziggo zat ook gewoon goed want het is dezelfde server) en dat het gebeurt wanneer het door de Experiabox gaat.

Reputatie 7
Badge +30
Maar, wat is nu precies het geval? Over wat voor webserver praten we? Wanneer heb je er last van?

Reageer