Trage opbouw internetpagina's - TCP dup/retransmissions

[Korakal]

Wie is er een beetje handig in het lezen van wireshark captures?

Ik heb vage problemen met internet vanaf alle computers/tablets/telefoons en ik wil graag (opnieuw) wat oorzaken gaan afstrepen. De pagina's laden erg langzaam, maar het is soms wel goed en soms niet; ik kan er geen lijn in vinden. Basically heb ik door te proberen te elimineren ofwel alles uitgesloten, ofwel is werkelijk ieder component stuk - ik ben even lost...

Het trage laden gebeurt op ieder device, wired of wireless, en de uiteindelijke doorvoersnelheid als ik bijv een speedtest doe is gewoon maximaal van wat de DSL verbinding kan halen. Lange pingreeksen zie ik ook geen onderbrekingen in.

Nu bedacht ik mij om eens te kijken of ik wat gerichter kan gaan zoeken, want er moet iets mis zijn. Dus ik heb een wireshark capture vanaf één van de computers gemaakt (192.168.0.60; router is .1). Ik zie vooral veel TCP Dup en TCP Retransmission. Ik begrijp er niet voldoende van. Heb gelezen dat ik in dat geval naar broadcasts zou moeten zoeken, maar ik zie met de kennis die ik ervan heb niets iets wat mij opvalt.

http://www.korakal.nl/got/wscap.pcapng
Geprobeerd met twee pagina's die typisch langzaam laden: bokt.nl (voor the miss) en linkedin.nl

Thanks alvast voor meedenken/meekijken!

[Gravit0n]

Retransmissies krijg je doordat er pakketjes tussenuit vallen, dan moeten ze opnieuw verzonden worden. Dat is hoe TCP werkt.

Waarom je duplicate acknowledgements krijgt weet ik niet, dat gaat mijn TCP kennis even te buiten.

Broadcasts hoef je niet aan te denken, dat is laag 2 & 3. Wanneer het daar al fout gaat heb je andere symptomen (verbindingen die helemaal niet worden opgebouwd).

Doen je devices het buiten je WiFi wel gewoon (aannames zijn gevaarlijk )?

[mclegodude]

Duplicate acks krijg je omdat je ook retransmissies doet, je verstuurd iets een 2e keer, maar je pc wacht zo lang op een antwoord dat hij het nog een keer verstuurd. in de periode dat die verstuurd wacht heeft de server het ontvangen en stuurt een ackje. toch krijgt hij nog een pakketje binnen, met hetzelfde nummer. en stuurt hij dus nog een ack, een duplicate ack!

ergens is dus zo'n grote delay dat het pakketje time-out, en hij het opnieuw verstuurt. kun je eens een tracert naar die sites doen, en ook ping -t naar beide sites en daarvan de resultaten hier plaatsen?

[dion_b]

Allicht nuttig om netwerkonderdelen (modem, router, switches etc) te noemen.

Dit zou echt van alles kunnen zijn (van duplex mismatch tot foute PMTU discovery)

[Korakal]

Thanks voor julllie reacties!

Gravit0n schreef op donderdag 02 juni 2016 @ 08:39:
Doen je devices het buiten je WiFi wel gewoon (aannames zijn gevaarlijk )?

Yes. Ik schakel zelfs regelmatig over naar mijn telefoon als hotspot, dat gaat echt zóveel sneller en 'snappier' dan de DSL verbinding. Overigens is het zowel bedraad als draadloos het geval, voor de duidelijkheid!

mclegodude schreef op donderdag 02 juni 2016 @ 09:16:
ergens is dus zo'n grote delay dat het pakketje time-out, en hij het opnieuw verstuurt. kun je eens een tracert naar die sites doen, en ook ping -t naar beide sites en daarvan de resultaten hier plaatsen?

Okay, vanaf een willekeurige computer, aan de kabel en wifi uit.
Bokt is in ieder geval niet te laden... staat nu al een dikke minuut wisselend op connecting-loading-finding-etc. Mijn telefoon laadt dezelfde site, via 4G, gewoon supersnel, dus aan de aanbodkant is niks mis. Op hetzelfde moment heb ik een aantal traceroutes uitgevoerd.

Het valt mij op dat bepaalde onderdelen tijdens het lang laden ook weer apart zichtbaar waren: googlesyndication.com en boktimg.nl, dus die heb ik allebei ook meegenomen.

code:

C:\Users\hurkm>tracert bokt.nl

Tracing route to bokt.nl [82.161.230.90]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.254
  2    18 ms    18 ms    18 ms  82-170-155-254.ip.telfort.nl [82.170.155.254]
  3    19 ms    19 ms    20 ms  ams-ix.sara.xs4all.net [80.249.208.48]
  4    19 ms    19 ms    19 ms  0.ae4.xr3.3d12.xs4all.net [194.109.5.5]
  5    19 ms    19 ms    19 ms  0.ae11.xrc1.1d12.xs4all.net [194.109.5.102]
  6    19 ms    19 ms    19 ms  www.bokt.nl [82.161.230.90]

Trace complete.

C:\Users\hurkm>tracert googlesyndication.com

Tracing route to googlesyndication.com [216.58.211.164]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  192.168.2.254
  2    18 ms    17 ms    37 ms  82-170-155-254.ip.telfort.nl [82.170.155.254]
  3    19 ms    19 ms    18 ms  ae10.524.ibr1.asd-nh.ip.telfort.nl [195.240.64.3
3]
  4    19 ms    18 ms    18 ms  195-240-240-194.ip.telfort.nl [195.240.240.194]

  5    19 ms    19 ms    19 ms  209.85.240.111
  6    20 ms    19 ms    19 ms  209.85.251.25
  7    32 ms    32 ms    42 ms  72.14.233.250
  8    32 ms    31 ms    31 ms  209.85.241.139
  9    31 ms    32 ms    31 ms  dub08s01-in-f4.1e100.net [216.58.211.164]

Trace complete.

C:\Users\hurkm>tracert boktimg.nl

Tracing route to boktimg.nl [82.161.230.91]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.254
  2    18 ms    18 ms    18 ms  82-170-155-254.ip.telfort.nl [82.170.155.254]
  3    19 ms    19 ms    19 ms  ams-ix.sara.xs4all.net [80.249.208.48]
  4    19 ms    19 ms    20 ms  0.ae4.xr3.3d12.xs4all.net [194.109.5.5]
  5    19 ms    19 ms    20 ms  0.ae10.xrc2.3d12.xs4all.net [194.109.5.118]
  6    19 ms    19 ms    20 ms  img.bokt.nl [82.161.230.91]

Trace complete.

C:\Users\hurkm>tracert linkedin.com

Tracing route to linkedin.com [108.174.10.10]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.254
  2    18 ms    18 ms    18 ms  82-170-155-254.ip.telfort.nl [82.170.155.254]
  3    19 ms    18 ms    18 ms  ae10.524.ibr1.asd-nh.ip.telfort.nl [195.240.64.3
3]
  4    19 ms    19 ms    19 ms  kpn-nso.telecity2.jointtransit.nl [217.170.20.13
0]
  5    20 ms    20 ms    19 ms  adm-b2-link.telia.net [62.115.145.74]
  6    19 ms    19 ms    19 ms  adm-bb3-link.telia.net [213.155.137.210]
  7    27 ms    27 ms    27 ms  ldn-bb3-link.telia.net [213.155.136.98]
  8   103 ms   104 ms   104 ms  ash-bb3-link.telia.net [80.91.249.101]
  9   104 ms   104 ms   104 ms  ash-b1-link.telia.net [62.115.113.209]
 10   100 ms   101 ms   102 ms  linkedin-ic-301441-ash-b1.c.telia.net [213.248.1
03.190]
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13   102 ms   102 ms   103 ms  108-174-10-10.fwd.linkedin.com [108.174.10.10]

Trace complete.

En die pings:

code:

C:\Users\hurkm>ping -t bokt.nl

Pinging bokt.nl [82.161.230.90] with 32 bytes of data:
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=20ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58
Reply from 82.161.230.90: bytes=32 time=19ms TTL=58

Pinging linkedin.com [108.174.10.10] with 32 bytes of data:
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=103ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=103ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=103ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55
Reply from 108.174.10.10: bytes=32 time=102ms TTL=55

Beiden gingen door zonder timeouts of pieken...

dion_b schreef op donderdag 02 juni 2016 @ 15:14:
Allicht nuttig om netwerkonderdelen (modem, router, switches etc) te noemen.

Dit zou echt van alles kunnen zijn (van duplex mismatch tot foute PMTU discovery)

Check.

DSL komt binnen op een Telfort Experiabox V8, routed. Telfort ondersteunt geen bridgemode (formeel) en daarom staat ie nu weer in routed. (in de routes hierboven: 192.168.2.254). Wireless is uit.
Er hangen twee devices aan: IPTV STB (apart VLAN) en een Dlink DIR868L router (192.168.2.1 aan WAN, 192.168.0.1 aan LAN-zijde). Deze routeert ook. De Dlink staat in de DMZ van de Experiabox. Wel of niet in de DMZ plaatsen maakt overigens geen verschil.

De Dlink is voor het LAN de DHCP server. Eén kabel naar een Asus unmanaged gigabit switch met PC, Mac Mini en Time Capsule. Eén kabel naar een Synology DS412+ NAS. De rest is wireless, voor zover mogelijk op 5GHz N/AC geconfigureerd.

[mclegodude]

Kun je op de Xperia box eens kijken naar fec errors? Er staat waarschijnlijk ook wel iets over line usability, ik verwacht dat jouw dsl lijntje ergens een heleboel verliest onderweg.

[Korakal]

Sinds gisteren:

code:

Indicator Name  Upstream    Downstream
FEC Error             14    31222
CRC Error              0    3

Ik dacht overigens dat ik het in mijn startpost had gemeld, maar dat is dan een ander bericht geweest. Er is gisteren een monteur in opdracht van Telfort geweest en hij heeft de koperlijn doorgemeten, zowel vanuit huis als vanuit de centrale. 0.1% foutmarge t.o.v. 3% toegestaan. De kwaliteit was daarmee goed. De FEC Errors waren geen verontrustende waarden volgens hem.

Overigens voor de volledigheid alle waarden van de statuspagina:

code:

VDSL Status Information:

Status:
                    Configured      Current
Line Status         ---             SHOWTIME
Trained Mode        Auto            PROFILE_8B

VDSL Data Rate:
                    Upstream        Downstream
Actual Data Rate    1861 (Kbps.)    25756 (Kbps.)
Attainable Rate     2080 (Kbps.)    25821 (Kbps.)

Operation Data / Defect Indication:
Operation Data      Upstream        Downstream
Noise Margin        5.8 dB          6.1 dB
Attenuation         34.6 dB         28.5 dB

Indicator Name      Upstream        Downstream
FEC Error           14              31732
CRC Error           0               3

DTU Counters:
                    Upstream        Downstream
corrected DTU Counter       0       0
uncorrected DTU Counter     0       0

Showtime Counter:
Showtime Counter    1 days, 5 Hours, 47 Minutes, 55 Seconds

[ Voor 43% gewijzigd door Korakal op 02-06-2016 15:51 ]

[mclegodude]

Hmm, allemaal goeie waarden idd, zowel van je modem als van je traceroutes. het enige wat ik nog kan bedenken is een laptop of iets dergelijks eens bekabeld aan de xperiabox hangen, daarmee sluit je voor de rest alles lokaal uit en kun je het probleem bij telfort leggen als het nog steeds aan de orde is.

[Korakal]

Hmmm ik heb nu alles losgekoppeld, laptop via kabel op de EB, en dat gaat een stuk beter.
Dit matcht overigens niet met het beeld wat ik er eerder op dezelfde manier van heb gekregen (eerder ook traag bij deze directe aansluiting).

Mijn verdenking gaat nu even uit naar de Dlink. Iemand enig idee wat ik er aan zou kunnen instellen wat dit veroorzaakt?

[Korakal]

Ik heb zojuist de Dlink voorzien van (opnieuw) de laatste firmware en naar fabrieksinstellingen hersteld. Nu weer via de Dlink met kabel geconnect. Andere apparatuur los. En het resultaat... tja, ik weet het niet. Het is wel degelijk weer iets beter, maar dat is het soms na herstart ook. Alleen toch ook nog wel weer hickups. Alsof er gewoon af en toe iets dwars zit. Maar dit helpt wel weer iets in de goede richting!

Ik heb IPV6 uitgezet, maar dat maakt nog geen verschil. Wat zou ik verder nog kunnen veranderen?

[edit]

Ik heb de Dlink nu maar eens even als accesspoint neergezet (kabel vanaf de Experiabox in een LAN poort en DHCP uit) en dat gaat voor nu eigenlijk wel heel prima. De reden dat ik het overigens liever niet gebruik op deze manier is dat de NAT tabel van de Experiabox nogal snel volloopt als ik naar buiten toe VPN connectie opzet. Dan wordt ineens alles traag...

[ Voor 36% gewijzigd door Korakal op 02-06-2016 18:31 ]

[daxy]

Klopt het dat je een Mac gebruikt? ("Powered by Apple")
Open je terminal app eens en tik in "sudo ifconfig awdl0 down" en kijk eens of het goed gaat.

[Korakal]

Ik gebruik o.a. een Mac maar ook pc's, iPhones en iPads. Ze hebben (hadden) er allemaal last van. Nu met de Dlink als router er tussenuit gaat het internetten op alle devices vlotter.
Gek genoeg deed 'ie het in bridgemode wel prima, dus het lijkt erop dat de Experiabox-router en de Dlink-router elkaar niet zo aardig vinden. Maar waarom...?

[steppert]

eventueel als het in te stellen is ,kan je de beacon interval verlagen. die waarde zorgt ervoor hoe vaak per seconde de modem een wifi pakketje stuurt. bij een lagere waarde worden er sneller pakketjes verstuurd, waardoor verschillende lagen van internet paginas sneller worden geladen.