beste



bel 0800/22700 optie 1 vervolgens optie 4, dit kan dagelijks tot 22u00



muisje

---

we zijn nu 3 dagen na het telefoontje met de technische dienst en ik moet helaas nog steeds geen verbetering van de situatie vaststellen...integendeel the timeout requests worden meer en meer frequent :(



C:\>tracert 74.125.230.132



Tracing route to 74.125.230.132 over a maximum of 30 hops



1 <1 ms <1 ms <1 ms 192.168.1.1

2 21 ms 20 ms 20 ms 1.3-182-91.adsl-dyn.isp.belgacom.be [91.182.3.1]

3 3384 ms * * 8.241-183-91.adsl-static.isp.belgacom.be [91.183.241.8]

4 22 ms 22 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]

5 22 ms 22 ms 22 ms bru-22-r7-t7-2.car.belbone.be [80.84.21.166]

6 58 ms 209 ms 29 ms 94.102.162.86

7 28 ms 27 ms 28 ms lnd-ix-r3-t3-4.car.belbone.be [80.84.18.0]

8 75 ms 27 ms 29 ms 74.125.50.21

9 28 ms 28 ms 37 ms 209.85.252.76

10 28 ms 28 ms 28 ms 209.85.251.58

11 27 ms 29 ms 27 ms 74.125.230.132



Trace complete.

---

vreemd dat andere adressen in dezelfde range geen problemen geven...

---

Beste DrLoco,



Deze case zal nagekeken worden.

Zodra ik u meer informatie kan geven zal deze hier gepost worden.



Mvg,



Eva van Belgacom

---

misschien dat dit ook handig is?





C:\>ping 91.183.241.8 -l 40000



Pinging 91.183.241.8 with 40000 bytes of data:



Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.



Ping statistics for 91.183.241.8:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

---

Gaat wel lekker vooruit zo...we zijn weer 10 dagen verder en nog steeds geen deftig antwoord, geen telefoontje, geen verbetering, ..... enige dat uiteraard correct loopt is de rekening, die zit weer mooi in de bus...niet voor de diensten die je hebt kunnen gebruiken, maar voor de diensten die je zou willen gebruiken!





C:\>tracert 74.125.230.132



Tracing route to 74.125.230.132 over a maximum of 30 hops



1 <1 ms <1 ms <1 ms 192.168.1.1

2 24 ms 21 ms 21 ms 1.47-182-91.adsl-dyn.isp.belgacom.be [91.182.47.1]

3 3052 ms * 3180 ms 8.241-183-91.adsl-static.isp.belgacom.be [91.183.241.8]

4 23 ms 22 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]

5 22 ms 22 ms 25 ms bru-22-r7-t3-2.car.belbone.be [80.84.21.106]

6 28 ms 27 ms 27 ms lnd-thn-r4-t1-2.car.belbone.be [80.84.18.177]

7 28 ms 27 ms 31 ms 94.102.162.208

8 28 ms 27 ms 27 ms 74.125.50.21

9 28 ms 27 ms 28 ms 209.85.252.76

10 27 ms 28 ms 27 ms 209.85.251.58

11 28 ms 27 ms 27 ms 74.125.230.132



Trace complete.



C:\>

---

Bon ik bel vandaag nog 1 maal en wacht tot morgen.

Als er dan nog geen oplossing of reactie gekomen is, zeg ik op zonder opbrekingsvergoeding wegens het in gebreke blijven door Belgacom EN de laatste faktuur die jullie sture mogen jullie dan ook oproken, aangezien ik niet de dienstverlening gekregen heb waarvoor ik getekend heb.

---

Beste DrLoco,



We zijn u zeker niet vergeten,

Ik tracht zo veel mogelijk druk te zetten om u spoedig een antwoord te kunnen geven.



Alles ligt nu in de handen van ons engineering team.

Gelieve ons nog even respijt te geven.



Mvg,





Eva van Belgacom

---

11 dagen ondertussen "Eva"





Ik hoop dat ik dat verschil ook op m'n faktuur ga zien!

---

12 dagen ondertussen



C:\>tracert 8.8.8.8



Tracing route to google-public-dns-a.google.com [8.8.8.8]

over a maximum of 30 hops:



1 <1 ms <1 ms <1 ms 192.168.1.1

2 20 ms 25 ms 21 ms 1.195-182-91.adsl-dyn.isp.belgacom.be [91.182.19

5.1]

3 3236 ms 3537 ms * 8.241-183-91.adsl-static.isp.belgacom.be [91.183

.241.8]

4 25 ms 22 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.18

3.247.36]

5 22 ms 22 ms 22 ms bru-22-r7-t3-2.car.belbone.be [80.84.21.106]

6 26 ms 22 ms 22 ms 94.102.162.86

7 27 ms 27 ms 27 ms lnd-ix-r3-t3-4.car.belbone.be [80.84.18.0]

8 27 ms 27 ms 27 ms 74.125.50.21

9 27 ms 28 ms 28 ms 209.85.255.175

10 28 ms 30 ms 28 ms 209.85.253.94

11 55 ms 34 ms 34 ms 66.249.95.173

12 33 ms 33 ms 33 ms 209.85.251.231

13 38 ms 46 ms 35 ms 209.85.243.73

14 34 ms 33 ms 33 ms google-public-dns-a.google.com [8.8.8.8]



Trace complete.



C:\>



En voor Belgacom nog 4 dagen. Zondag niet opgelost...ikke weg! En iedereen die ik mee weg kan krijgen ook.



Jullie behandelen mensen al veel te lang als domme uilen!

---

Is duidelijk een probleem op je lijn en mischien ook de aansluiting in de rop



Bel naar 080022424 en volg de instructies



Waarschijnlijk staat je lijn op een repair profile

---

Ik heb hetzelfde, maar helaas, dat nummer daar kreeg ik enkel een fluittoon te horen... (bijna symbolisch).



Nog steeds hoge en hogere pingtijden... games is er momenteel niet meer mee mogelijk, en de packetloss is ook de pan aan het uitswingen. Youtube laadt ook slechter en slechter (of helemaal niet) ....



Paradoxaal genoeg was dit issue ook hetgeen waar ik bij telenet ben voor gaan lopen (slechte lijnkwaliteit), blijkbaar is belgacom/scarlet in hetzelfde bedje ziek, zei het dan via een andere technologie.



Een oplossing graag...



C:\>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]over a maximum of 30 hops:





1 1 ms 1 ms 1 ms home.home [192.168.1.1]

2 18 ms 17 ms 17 ms ip-83-134-91-1.dsl.scarlet.be [83.134.91.1]

3 2397 ms 3090 ms 3022 ms 66.241-183-91.adsl-static.isp.belgacom.be [91.183.241.66]

4 20 ms 21 ms 20 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]

5 22 ms 20 ms 20 ms bru-22-r7-t3-1.car.belbone.be [80.84.21.102]

6 27 ms 25 ms 25 ms lnd-thn-r4-t1-2.car.belbone.be [80.84.18.177]

7 25 ms 26 ms 25 ms 94.102.162.208

8 47 ms 27 ms 25 ms 74.125.50.21

9 25 ms 25 ms 25 ms 209.85.252.76

10 65 ms 28 ms 25 ms 209.85.253.92

11 43 ms 33 ms 36 ms 66.249.95.173

12 40 ms 31 ms 31 ms 209.85.251.231

13 32 ms 34 ms 35 ms 209.85.243.85

14 31 ms 31 ms 32 ms google-public-dns-a.google.com [8.8.8.8]



Trace complete.

---

hey patrick.2060,



Bedankt voor je oplossing, misschien moet je het dat engineeringteam dat hier mee bezig is even snel gaan uitleggen, aangezien de oplossing zo overduidelijk is.



Ik vind het al bijna vreemd dat ik hoegenaamd VDSL2 kan hebben dan, want volgens jou theorie lijkt die lijn me wel HEEL lang, aangezien strimbello centrum Antwerpen zit (geloof ik), ik Steenhuffel en de 3 andere personen in het topic van patrick... heb ik niet kunnen achterhalen waar, maar moet wel 1 gigantisch lange lijn zijn. of een ROP die over verschillende provincies gaat. Moet knap geweest zijn toen ze die plaatsten.



Sorry voor m'n sarcasme, maar zoals homer simpson het stelde (maar dan met andere woorden)...no computer make me go something something....zeker als ik afspraken heb waar ik voor thuis moet zijn en waar werken via VPN nu al geruime tijd onmogelijk blijkt!



Ik kan aannemen dat niet alles op 1...2...3 opgelost is. Maar een f*ing prognose met feedback over wat het probleem nu net is had na meer dan 12 dagen wel gemogen...ook voor een bedrijf als Belgacom dat systematisch alle interne problemen blijft ontkennen en moet liegen tegen de klant.

Ik snap niet dat ze NOG STEEDS niet geleerd hebben dat iedereen (en dus ook elk bedrijf) fouten maakt en dat er OVERAL dingen fout gaan. Belangrijk is hoe je er over communiceert en wanneer!



Met mensen als domme uilen te verslijten geraak je geen stap verder...integendeel!





ahja EVA ... NOG 3 dagen!

---

Helemaal mee eens DrLoco,... centrum Antwerpen hier, plus dat ik ook wel eens zou willen weten wat zo'n 'engineering team' dan als status kan geven. Een update hier zetten kan toch niet zo moeilijk zijn? Case nr + kleine beschrijving van de huidige status. Zo weet iedereen iets meer en moeten er geen twitters en forums volgeschreven worden door klanten die het ko**beu zijn.



PS: en nee, ik ga niet nog eens naar een helpdesk bellen, ik zit bij Scarlet, niet bij Belgacom:) en vermits het probleem bij belgacom ligt moet Scarlet maar naar die mannen hun toffe wachtmuziekskes luisteren (Vivaldi, waarschijnlijk).

---

Aangezien de informatie flow in 1 richting loopt, nog een leuke bijgedaan die misschien de impact van het issue doet beseffen:





My traceroute [v0.73]

copperhop (0.0.0.0) Fri Jun 24 13:55:43 2011

Keys: Help Display mode Restart statistics Order of fields quit

Packets Pings

Host Loss% Snt Last Avg Best Wrst StDev

1. 194.119.228.2 0.0% 66 1.2 0.7 0.1 1.3 0.5

2. 194.119.228.169 0.0% 66 0.2 0.7 0.2 1.3 0.5

3. 195.207.176.245 0.0% 66 0.9 3.1 0.8 80.3 10.2

4. be2.intlstr2.isp.belgacom.be 0.0% 66 1.7 1.6 0.9 2.4 0.6

5. 33.247-183-91.adsl-static.isp.be 70.8% 66 1.6 5.0 1.0 40.5 8.7

6. 67.241-183-91.adsl-static.isp.be 0.0% 66 3.3 3.9 3.3 4.5 0.5

7. ???



70% packet loss !!!



---

20 dagen later...nog steeds geen oplossing en evenmin geen feedback...toffe boel!

---

DrLoco de gegevens die je hier post tonen geen echt probleem van enig belang ... je eerste traceroute komt aan tot aan de eindbestemming met een RTT van gemiddeld 27 miliseconden. indien de router/verbinding op hop 3 echt een probleem had dan zouden alle volgende hops eenzelfde 'vertraging' aantonen.



Vergeet niet dat routers als taak hebben om data zo vlug mogelijk door te sturen, antwoorden op ping/tracert worden door routers meestal behandeld met zeer lage prioriteit en dan nog voor een beperkt aantal van deze pings/tracert.





Grumph.

---

@ Dr Loco:Ik denk niet dat lopen bulderen u probleem sneller gaat oplossen.Iedereen bij Belgacom doet zijn best om U verder te helpen.Als men U antwoord met ik kan U hiervoor niet helpen of een dergelijk antwoord dan zou ik even nadenken over da manier waarop het telefoongesprek verlopen is.Moest ik telefoon krijgen van een klant die op exact dezelfde manier zoals deze post zijn storing uitlegt dan zou ik ook niet veel zin hebben om te helpen.Vriendelijk get's you a long way!Ik begrijp U frustratie maar toch...



@ Strimbello: Het streamen van youtube filmpjes kan soms ook aan de server van youtube liggen.Ik heb zelf een internet intense en sommige filmpjes streamen nu eenmaal rapper dan andere.Net zoals je op ene microsoft website een update kan downloaden aan een aanzienlijk hogere snelheid dan op andere sites...

---

C:\Users\ric>ping -l 40000 74.125.230.132



Pinging 74.125.230.132 with 40000 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.



Ping statistics for 74.125.230.132:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),



Is dit normaal ?

---

@ricy je tracht een paket te versturen dat 40.028 (40000 icmp + 8 icmp header + 20 IP) bytes groot is ... de meeste ADSL-ppp verbindingen ondersteunen paketten die maximaal 1492 bytes groot zijn.



Dus om je 40.000 bytes te versturen gaat je PC/Modem dit opsplitsen in kleinen deetljes die wel binnen de 1492 limiet liggen.



De eindebestemming wordt dan verondersteld om alle afzonderlijk deeltjes weer aaneen te plakken en vervolgens een gepaste actie nemen.



Helaas kunnen mensen met slechte bedoelingen op deze manier een server (zonder bescherming maatregelen) in de problemen brengen.



Daarom beperken de meeste server de groote van deze onvolledig ontvangen paketten in grote en tijd.



Op mijn verbinding ligt die grens op 8755 bytes payload...



PS. Het ligt eigenlijk een beetje complexer want eerst zal je PC die 40.008 bytes groot icmp pakket op splitsen in deeltjes van 1480 bytes icmp (+ 20 bytes ip-header) en vervolgens zal je modem elk deeltje van 1500 bytes opnieuw opsplitsen in één pakket van 1472 (+ 20 bytes IP) en een tweede van 8 (+ 20 bytes IP)



Voor een meer uitgebreidere uitleg: http://penguin.dcs.bbk.ac.uk/academic/networks/network-layer/fragmentation/index.php

---

@Grompy, bedankt voor je uitgebreide uitleg.



'k heb nog eens geprobeerd en pas als ik afdaal tot 33240 (bij herhaaldelijk pingen met zelfde pakket grootte) heb ik geen pakket verlies meer.



C:\Users\ric>ping 74.125.230.132 -l 33240



Pinging 74.125.230.132 with 33240 bytes of data:

Reply from 74.125.230.132: bytes=33240 time=141ms TTL=54

Reply from 74.125.230.132: bytes=33240 time=146ms TTL=54

Reply from 74.125.230.132: bytes=33240 time=153ms TTL=54

Reply from 74.125.230.132: bytes=33240 time=143ms TTL=54



Ping statistics for 74.125.230.132:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 141ms, Maximum = 153ms, Average = 145ms

---

@ https:///people/9a5f0c31ce



Dr Loco:Ik denk niet dat lopen bulderen u probleem sneller gaat oplossen.Iedereen bij Belgacom doet zijn best om U verder te helpen.Als men U antwoord met ik kan U hiervoor niet helpen of een dergelijk antwoord dan zou ik even nadenken over da manier waarop het telefoongesprek verlopen is.Moest ik telefoon krijgen van een klant die op exact dezelfde manier zoals deze post zijn storing uitlegt dan zou ik ook niet veel zin hebben om te helpen.Vriendelijk get's you a long way!Ik begrijp U frustratie maar toch...



------------



Ik zou best uw reactie eens willen zien als het surfen je nagenoeg onmogelijk gemaakt wordt, maar de rekeningen toch mooi blijven komen.

Ik heb dit probleem initieel deftig telefonisch gemeld, dan 10 dagen lang geprobeerd om zoveel mogelijk informatie door te sturen...zonder reactie. En het is net de: zonder reactie de de toon van de posts heeft doen wijzigen.



Onder de theorie dat klagers, zagers en roepers het meest gedaan krijgen, heb ik de initieel vriendelijke toon na 10 dagen zonder verdere uitleg of reactie, noch oplossing voor m'n probleem, gewijzigd. Blijkbaar zitten we in de fase dat er enkel nog op brieven van de ombudsdienst of je advokaat gereageerd wordt, aangezien de andere toon geen meerwaarde gebleken heeft....of misschien toch, want sinds afgelopen weekend zijn de tijden bemoedigender en terwijl dit voor mij blijkbaar geen effect heeft, merk ik toch ZEER duidelijk het verschil.



C:\>tracert 8.8.8.8



Tracing route to google-public-dns-a.google.com [8.8.8.8]

over a maximum of 30 hops:



1 <1 ms <1 ms <1 ms 192.168.1.1

2 27 ms 20 ms 21 ms 1.85-182-91.adsl-dyn.isp.belgacom.be [91.182.85.1]

3 869 ms * * 8.241-183-91.adsl-static.isp.belgacom.be [91.183.241.8]

4 23 ms 22 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]

5 25 ms 22 ms 22 ms bru-22-r7-t7-2.car.belbone.be [80.84.21.166]

6 28 ms 27 ms 27 ms lnd-thn-r4-t1-2.car.belbone.be [80.84.18.177]

7 27 ms 28 ms 27 ms 94.102.162.208

8 30 ms 27 ms 27 ms 74.125.50.21

9 28 ms 27 ms 41 ms 209.85.252.76

10 31 ms 28 ms 37 ms 209.85.253.88

11 34 ms 34 ms 35 ms 66.249.95.173

12 33 ms 34 ms 34 ms 209.85.251.231

13 42 ms 34 ms 38 ms 209.85.243.85

14 33 ms 33 ms 33 ms google-public-dns-a.google.com [8.8.8.8]



Trace complete.



packet loss naar 61%





@Grompy

volgende en vorige router in het netwerk gaan perfect hoor, enkel de range 91.183.241 geeft issues:



C:\>ping 91.183.247.36 -l 40000



Pinging 91.183.247.36 with 40000 bytes of data:



Reply from 91.183.247.36: bytes=40000 time=165ms TTL=252

Reply from 91.183.247.36: bytes=40000 time=162ms TTL=252

Reply from 91.183.247.36: bytes=40000 time=161ms TTL=252

Reply from 91.183.247.36: bytes=40000 time=170ms TTL=252



Ping statistics for 91.183.247.36:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 161ms, Maximum = 170ms, Average = 164ms



C:\>ping 91.183.241.8 -l 40000



Pinging 91.183.241.8 with 40000 bytes of data:



Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.



Ping statistics for 91.183.241.8:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms





ohja...we zijn ondertussen 24 dagen later!

volle pot betalen...percentje krijgen

---

Lijkt me geen algemeen probleem en verder zeker eens lezen wat Grompy heeft gepost.

---

83.134.114.88



My traceroute [v0.73]

copperhop (0.0.0.0) Tue Jul 5 11:55:17 2011

Keys: Help Display mode Restart statistics Order of fields quit

Packets Pings

Host Loss% Snt Last Avg Best Wrst StDev

1. 194.119.228.2 0.0% 45 1.3 0.7 0.1 1.3 0.5

2. 194.119.228.161 0.0% 45 1.3 0.7 0.2 1.3 0.5

3. 195.207.176.245 0.0% 45 0.8 2.4 0.8 20.6 3.8

4. be2.intlmar2.isp.belgacom.be 0.0% 44 1.2 1.6 0.9 2.4 0.5

5. 37.247-183-91.adsl-static.isp.be 0.0% 44 1.4 5.0 1.0 96.7 14.5

6. 67.241-183-91.adsl-static.isp.be 0.0% 44 4.3 3.8 3.2 4.4 0.5

7. ip-83-134-114-88.dsl.scarlet.be 0.0% 44 20.2 20.1 19.1 21.3 0.5





geen packet loss op die range.













mtr 81.11.221.33



My traceroute [v0.73]

copperhop (0.0.0.0) Tue Jul 5 11:56:23 2011

Keys: Help Display mode Restart statistics Order of fields quit

Packets Pings

Host Loss% Snt Last Avg Best Wrst StDev

1. 194.119.228.2 0.0% 42 0.1 0.7 0.1 1.3 0.5

2. 194.119.228.169 0.0% 42 1.3 0.7 0.1 2.0 0.6

3. 195.207.176.245 0.0% 42 1.9 1.4 0.8 2.0 0.5

4. be1.intlstr2.isp.belgacom.be 0.0% 42 1.8 1.5 0.8 2.0 0.5

5. 33.247-183-91.adsl-static.isp.be 58.5% 42 1.0 3.9 1.0 33.9 7.8

6. 67.241-183-91.adsl-static.isp.be 0.0% 42 4.4 3.7 3.2 4.4 0.5

7. ???



Zoals aangegeven is het reeds beter, maar nog niet opgelost.





Wanneer mag ik eindelijk nog eens een officiële update verwachten van iemand van BGC?















@axs



Bedankt voor je bijdrage, maar met assumpties ben ik helaas niets. Als je de ganse post doorneemt, is dit geen algemeen probleem. Dat toon ik boven ook aan. Probleem bevindt zich in bepaalde range. En zoals reeds aangegeven door anderen, ben ik niet alleen hier de dupe van.

Een test vanop werk toont tevens duidelijk aan dat ieder die langs die range passeert hier problemen van ondervindt. Maar die gegevens mag ik helaas niet posten. Is trouwens niet nodig, de informatie in dit topic is onweerlegbaar.

---

Idd de informatie is onweerlegbaar ... op basis van de informatie uit mtr heb je GEEN probleem!

---