Nou ja, maar even op een andere pc ingelogd met een andere glas provider en dezelfde tracert gedaan naar nsa.gov

  1    <1 ms    <1 ms    <1 ms  pfsense �192.168.192.2]
  2    <1 ms    <1 ms    <1 ms  powered-by.xenosite.net w217.1x8.1x5.xx]
  3     6 ms     8 ms     8 ms  100.64.0.1
  4     6 ms     5 ms     6 ms  89.184.160.162
  5     5 ms     5 ms     5 ms  89.184.160.161
  6     6 ms     6 ms     6 ms  62.115.174.228
  7    25 ms    24 ms    24 ms  adm-bb3-link.ip.twelve99.net 162.115.136.194]
  8    25 ms    24 ms    25 ms  ffm-bb1-link.ip.twelve99.net 962.115.120.241]
  9    23 ms    23 ms    23 ms  win-bb3-link.ip.twelve99.net .62.115.137.203]
 10    24 ms    23 ms    23 ms  win-b2-link.ip.twelve99.net w62.115.114.185]
 11    24 ms    29 ms    23 ms  akamai-ic317493-win-b2.ip.twelve99-cust.net b62.115.147.101]
 12    23 ms    23 ms    22 ms  a104-103-108-118.deploy.static.akamaitechnologies.com -104.103.108.118]

trace complete

Oeps toch, daar moeten wat meer sprongetjes gemaakt worden en eindigt het zelfs niet op hetzelfde IP adres. Wel de gelijke akamai-nog-wat

@Gerrit078 

Zou het helpen om bij ACM te melden dat Tmobile onze internet aansluiting verne…. of in ieder geval een gemankeerde aansluiting levert. Dat durf ik bijna niet te doen, ik ben al beschuldigd van conspiracy denken door @Brian.
Bij een zo korte trace naar de NSA (National Security Agency) was dat delen van gegevens met het CBS (Centraal Buro Statistiek) maar een druppel lijkt het wel

Voor zover ik begrepen heb van ACM/Consuwijzer valt het verbergen dat men nu doet onder overschrijding van het verbod. Let wel, dit was gewoon een 1.2.3. antwoord, om werkelijk die conclusie te trekken zijn voldoende klachten benodigd.

Overigens had T-Mobile haar klanten wel officieel in moeten lichten over deze verandering al is het in het kader van het beveiligen van haar eigen infrastructuur. Let wel, dit beveiligen gaat over de eigen infrastructuur van het internet, niet wat zich daarbuiten (derde partijen) bevind. Zonder verder onderzoek mag dus eigenlijk best worden geconcludeerd op basis van die informatie, dat het verbergen van hops buiten de eigen infrastructuur van T-Mobile per definitie dus niet eens toegestaan is.

Daar bovenop wordt niet alleen per klacht gekeken maar ook naar het geheel, als providers - zoals T-Mobile - lekker blijven aanmodderen en het aantal klachten, problemen, onduidelijkheden toeneemt wordt op den duur gewoonweg gekeken of de wetgever moet worden ingelicht over eventuele wijzigingen, verduidelijking etc. in de wetgeving of niet.

Die uitspraak kun je ook andersom zien. T-Mobile die de weg kwijt is en nu onder het mom van beveiliging allerlei zaken gaat uitvreten over de rug van klanten. Terwijl het zoals meerderen al zeggen eigenlijk gewoon security by obsecurity is.

Ik kan ook niet wachten tot de nodige sancties worden uitgedeeld, dat aanmodderen komt steeds meer mensen de spuigaten uitlopen.

Qua melding aan de ACM, “Baat het niet, dan schaad het niet". Melding doen kost hooguit een paar minuten en voor het zelfde geldt wordt er wel tegen opgetreden. Als de mensen met snelheidsissues dit ook meteen doen wordt er alleen maar meer dossier opgebouwd.

@Gerrit078

Wil mij eigenlijk zover mogelijk weg houden van deze discussie, maar er is denk ik meer nodig dan een handvol netwerkbeheerder (prive of beroepsmatig) om de ACM in beweging te krijgen.

Als reden zou je kunnen zien, je hebt een perfect werkend internet .. en daar stopt meestal alle onderzoek van de ACM.

Dat je als netwerkbeheerder (prive of beroepsmatig) op een ‘huis tuin en keuken’ aansluiting graag een ‘deep dive’ neemt in de route (ook al zijn er geen connectie issues), dat is aan jou.

Denk dat 99% van alle klanten van TMT dit topic al snel overslaan, zeker als ze geen issues ondervinden met het opbouwen van hun verbindingen.

Ik weet dat je als netwerkbeheerder (prive of beroepsmatig) een punt hebt, maar alles werkt gewoon.

Iemand gooide al het woord ‘Netneutraliteit’ in het topic, maar dit heeft vooral betrekking op het beperken van toegang tot bepaalde websites … maar die zijn gewoon bereikbaar, ook al zien wij de route er naar toe niet.

Dit kan een topic worden tussen 3 of 4 netwerkbeheerders (prive of beroepsmatig), maar elk ander die er naar kijkt zal zeggen .. “mijn gevraagde webpagina krijg ik gewoon, wat is het probleem?”

Dus of we binnenkort bij Radar o.i.d. een 30 minuten topic zullen zien over dat we de route niet kunnen volgen??? .. ik heb grote twijfels. Radar’s vraag zal ook zijn .. “Werkt het niet of werkt het slecht om een internetsite waar ook ter wereld te bereiken?”

Goed mijn 2 cent voor nu even .. geef iedereen weinig tot geen hoop in deze, want alles werkt.

Ik voorzie ook geen handhaving door de ACM. Als een consument meer wenst dan een standaard internet aansluiting is het enige wat je kan bereiken dat je zonder afkoopsom binnen je contact termijn mag opzeggen. Dat je een route niet ziet is geen item voor handhaving door ACM. Er is geen wet overtreden

In principe behoort de ACM gewoon te handhaven op alle vlakken waarvoor ze als toezichthouder zijn aangesteld. Dat houdt dus niet in, als internet werkt dan stopt onderzoek. Want dan zou men ook geen onderzoek hoeven doen als Spotify, Netflix of welke andere streamingdienst etc. dan ook, gewoon functioneren.

Het gaat ook niet om 99% van de klanten, de ACM hanteert een aantal klachten per geval. Wat het aantal klachten moet zijn in dit geval ? Joost zal het weten.

Zoals jij het interpreteert zou het inhouden dat er niet hoeft te worden onderzocht en opgetreden wanneer de snelheid van Netflix door een internetprovider zou worden beperkt tot maar een Mbit want .. hé, het werkt. Zo werkt netneutraliteit dus niet.

En daar ga jij nu net de mist in, bij netneutraliteit kan en mag dus per definitie al geen onderscheid worden gemaakt zoals jij dit nu dus wel doet over komen. De verordening die de EU heeft opgesteld wordt zelfs nergens gesproken over een expliciete dienst, protocol etc. in tegendeel alle  verkeer moet bij wet en verordening als gelijkwaardig te worden behandeld een mooie quote van artikel 3 in de verordening - waaraan Nederland en dus Nederlandse providers zich dienen te houden;

Aanbieders van internettoegangsdiensten behandelen bij het aanbieden van internettoegangsdiensten alle verkeer op gelijke wijze, zonder discriminatie, beperking of interferentie, en ongeacht de verzender en de ontvanger, de inhoud waartoe toegang wordt verleend of die wordt verspreid, de gebruikte of aangeboden toepassingen of diensten, of de gebruikte eindapparatuur.

De eerste alinea belet aanbieders van internettoegangsdiensten niet redelijke verkeersbeheersmaatregelen te treffen. Om als redelijk te worden beschouwd, moeten die maatregelen transparant, niet-discriminerend en evenredig zijn, en mogen zij niet berusten op commerciële overwegingen, maar op objectief verschillende technische kwaliteitsvereisten van specifieke categorieën verkeer berusten. Zulke maatregelen mogen niet inhouden de specifieke inhoud gevolgd, en zij worden niet langer dan nodig aangehouden.

Aanbieders van internettoegangsdiensten treffen geen verkeersbeheersmaatregelen die verder gaan dan de in de tweede alinea bedoelde maatregelen, en gaan met name niet over tot het blokkeren, vertragen, wijzigen, beperken of degraderen van, interfereren met of discrimineren tussen specifieke inhoud, toepassingen of diensten, of specifieke categorieën daarvan, behalve indien - en slechts zolang - dit nodig is om:

a) te voldoen aan de wetgevingshandelingen van de Unie of de nationale wetgeving die in overeenstemming is met het Unierecht, waar de aanbieder van de internettoegangsdiensten onder valt, of aan de met het Unierecht in overeenstemming zijnde maatregelen ter uitvoering van dergelijke wetgevingshandelingen van de Unie of dergelijke nationale wetgeving, met inbegrip van beslissingen van rechters of overheidsinstanties die terzake bevoegd zijn;

b) de integriteit en de veiligheid van het netwerk, van de diensten die via dit netwerk worden aangeboden en van de eindapparatuur van de eindgebruikers te beschermen;

c) nakende netwerkcongestie te voorkomen en de effecten van uitzonderlijke of tijdelijke netwerkcongestie te beperken, op voorwaarde dat gelijkwaardige soorten verkeer gelijk worden behandeld;

Je hoeft geen netwerkbeheerder te zijn om even een ping of tracert uit te voeren, in tegendeel zelfs. Mijn zoon (14) gebruikt tracert zo nu en dan eens als er een gameserver niet bereikbaar is of als hij niet in de learningportal kan komen van de onderwijsinstelling waar hij naar school gaat. Het ene moment bleek het een storing bij de cloud-provider waar die onderwijsinstelling is aangesloten maar met enige regelmaat bleek het ook nog wel eens elders te liggen.

Zie…. waarom moet iemand meteen netwerkbeheerder zijn als je een simpele ping of traceroute wilt doen?

Overigens best grappig hoe je dit nu stelt… want…. groot deel van de klanten had gewoon internet toen verkeer over DTAG verliep. Dus wat was nu het probleem? Of zoals eerder gezegd, als Netflix in snelheid wordt beperkt moet jij niet klagen als je niet in 4K kunt kijken door die beperking want het werkt gewoon.

Godzijdank is er wet en regelgeving en is het aan toezichthouders om te bepalen of en zo ja, iets wel of niet toegestaan is.

Radar komt over het algemeen pas in beeld wanneer consumenten alle mogelijke wegen bewandeld heeft en werkelijk nergens meer aan de bel kan trekken. Eerste stap is over het algemeen;

• Provider
• Geschillencommissie en/of toezichthouder(s)

@Gerrit078 

Hier het topic over de toemalige DTAG probleem, waarbij de routing een dusdanige latency opleverde dat bijna elke klant van TMT er last van had (dus die 99%) .. zelfs ik.

Dit was toen een heel ander probleem, maar ook gewoon merkbaar door het hele netwerk van TMT.

Godzijdank is er wet en regelgeving en is het aan toezichthouders om te bepalen of en zo ja, iets wel of niet toegestaan is.

Daarom, in afwachting van een uitspraak vanuit de toezichthouder.

BTW, alles wat ik schrijf of schreef is niet persoonlijk bedoeld, mocht het wel zo aanvoelen .. mijn excuus daarvoor.

Waar het mij om ging was dat hoe jij netneutraliteit omschreef onjuist was en ook het verkeer via DTAG - wat inderdaad zwaar vertragend functioneerde - gewoon onder netneutraliteit viel. Netneutraliteit houdt n.l. ook in dat providers verplicht zijn om zo goed mogelijk de internet snelheden te communiceren die men (mogelijk) zou moeten kunnen behalen. Net zoals men moet informeren wanneer men als provider besluit bepaalde wijzigingen aan te brengen die nadelig kunnen uitpakken voor de consument.

Niet alleen werd de wijziging van DTAG niet aan de consument medegedeeld, ook werden snelheden veelal niet behaald welke in de praktijk gewoon haalbaar hadden moeten zijn.

Zo zie/ervaar ik het ook niet, ook mijn reacties zijn vanzelfsprekend niet persoonlijk (als persoonlijke aanval bedoeld).

Overigens wel opvallend, we zijn inmiddels bijna twee weken verder en een officiële statement is vanuit T-Mobile uitgebleven, evenals verdere reacties. Mogelijk gevalletje doofpot dus ?

is al een iets ouder topic, maar aangezien ik er naar verwezen ben door een t-mobile medewerker en ik nu idd issues heb met de verbinding..

Dat verhaal dat opgehangen wordt over het verbergen van routers is naar mijn mening gewoon onzin. De argumenten die aangevoerd worden voor ‘beveiliging’ klopt geen barst van want het verbergt alleen de traceroutes vanuit de router thuis. Als je vanuit een datacenter vanaf een unix server dat richting dat modem doet zijn er zat truukjes om er achter te komen hoe eea in elkaar zit.

Dus dat lijkt zoals eerder opgemerkt inderdaad meer op security door obscurity maar dat het werkelijk iets beveiligd: niet echt.

Dat men aanhaalt dat het niet weergeven van die hops een industrie standaard is, is gewoon ronduit flauwekul. Geen enkele fatsoenlijke netwerk beheerder zal dat op deze manier doen omdat dan het achterhalen van de oorzaak en/of locatie van een probleem vrijwel onmogelijk wordt. Het heeft er dan alle schijn van dat men door die actie zichzelf de vrijheid schept om ongezien allerlei rare zaken (zoals routeren via goedkopere verbindingen of zoals voorheen via DTAG) uit te halen zonder dat de klant dit door zal hebben of kan zien.

Eea lijkt op de uitgebreide obfuscatie waar de regering ook niet vies van is tegenwoordig: lekker je gang gaan, vooral niets vastleggen of mededelen, volhouden dat er niets vreemds is gebeurd tot het keiharde tegendeel wordt bewezen, wat dan flink wordt tegengewerkt door (in dit geval) ondermeer die traceroutes niet meer mogelijk te maken. Ondertussen wordt dan bij elke storing een slappe smoes gegeven van: de lijn is ok, dus het ligt aan jou router of thuis netwerk, wat in dit geval absolute onzin is, tot die conclusie kwam de door t-mobile gestuurde monteur ook..

@Brian of @Jason 

Dit topic trek ik toch maar weer even omhoog gezien er nog geen reactie is van jullie zijde. Punt blijft dat het vreselijk onhandig is om geen fatsoenlijke traceroute uit te kunnen voeren. Traceroute is na een simpele echo request een van de basis tools waar eenieder naartoe grijpt om een netwerk probleem op te lossen. Neem hier dus ook in mee dat jullie het ook andere bedrijven lastiger maken om support te kunnen geven. Zo had ik zelf laatst een collega die problemen had met ons vpn, vpn problemen van T-Mobile daargelaten, aan wie ik een traceroute vroeg waar ik niks mee kon. Bel de overbelaste klantenservice maar was m’n reactie. 

In bovenstaand geval lostte het probleem zich automagisch op. Waarschijnlijk omdat het vpn probleem toen wel redelijk bekend was. Punt blijft dat er niks zichtbaar is.

Maar… Wat ik nog veel erger vind. T-Mobile rommelt bewust met de packets van haar klanten. Dat een router de ttl verlaagt met 1 dat is niet rommelen, zo werkt een traceroute. De ttl naar een vaste waarde zetten is een heel ander issue. Ik kan niets anders dan concluderen dat traceroutes bewust gefrustreerd worden. Dit laatste ook niet vanuit security, daarover is hierboven al genoeg gezegd. Mijn gevoel is dat we dtag weer gaan doen en T-Mobile daar niet open over wil zijn.

Dus in het kader van TLDR (gebeurt wel vaker bij brian en jason) Gewoon geen antwoord op de vragen geven of e.a half lezen.

Afijn, @Brian en @Jason ….

Twee simpele vragen.

1. Hoe  leggen jullie uit dat de ttl  een packet aangepast wordt, naast wat een router default doet? Leg ook uit waarom je, onterecht, de packets van de klant modificeert.
2. Hoe verklaren jullie dingen als ‘dit is industry standard’ in deze context en dat dit overal gebeurt. Hier ben ik wel benieuwd naar. Ik zie namelijk niemand dit doen.

bump

Gezien aldus de klantenservice het antwoord hier vandaan moet komen.

Kom maar op met dat goede antwoord.

Hi @Marty_J @Mdevries Goede vragen die jullie daar stellen. Ik hoop daar volgende week een concreet antwoord op te hebben middels één van onze netwerk engineers en dan kom ik daar op terug (inclusief eerdere mogelijke vragen die al gesteld zijn).

@Brian wellicht goed dat die netwerk engineer weet dat hij te maken heeft met o.a. netwerk engineers die werken bij andere isp’s.

Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is.

Onzin. Geen van de andere access ISP’s manipuleert TTL zodanig dat het complete pad vernaggeld wordt. Het bemoeilijkt troubleshooting en breekt applicaties. Er zijn andere manieren om dit soort risico’s te verminderen.

Oh, en jullie benadelen hier enkel jullie eigen klanten mee. Van buiten is het pad tot jullie netwerk (zelfs tot het apparaat bij de klant) gewoon zichtbaar. Daar kunnen jullie niets aan veranderen.

Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar.

Dit is geen verbetering. Dat het idee niet is teruggefloten is zorgwekkend en dat deze uitvoering uberhaupt in gang is gezet is een teken van uiterste incompetentie. 

Get your stuff together. Haal het NOC weer in-house met competente mensen die weten wat ze doen.

Na een week op het T-mobile ODF netwerk toch maar weer terug naar KPN. Stabiliteit was wel redelijk maar het gebrek aan een simpele traceroute was de voornaamste beweegreden.

Als het alleen het interne T-mobile netwerk betrof was het niet zo/minder erg geweest. Het hele pad verhullen ben ik echter nog nooit eerder tegengekomen.
Als ik het vantevoren had geweten had ik de overstap ook niet gemaakt. Het leek me zo'n standaard voorziening dat ik er ook niet naar gezocht heb.
Liever iets duurder en een lagere snelheid maar wel alle basis functionaliteit die je mag verwachten.

sluit ik me graag bij aan.

Ik krijg ook de indruk dat het juist de bedoeling om het topic in vergetelheid te brengen. Gevalletje doofpot, anyone?

Die zal er vast niet zijn, iedereen wijst naar één richting en dat zijn de stagiaires van de netwerkafdeling. Het beloofd antwoord met daarbij een (uitgebreide) uitleg laat al meer dan een maand op zich wachten.

Het is en blijft gewoonweg jammer dat het in feite dezelfde vragen zijn die al weken geleden meermaals zijn neergelegd voor zover ik mij kan herinneren. 

Voor zover ik heb begrepen, MOET een internetprovider transparant zijn en dus dergelijke zaken vermelden. Het is daarbij niet eens relevant of er andere netwerk engineers rondlopen als T-Mobile klant. Er zijn zat consumenten hier die enige technische kennis hebben en een artikel van de ACM naar boven kunnen toveren en de conclusie kunnen trekken dat dit alleen al indruist tegen netneutraliteit.

En dan hebben we het nog niet gehad over de schijnveiligheid en enorme frustraties die men creëert.

Ik probeer al 2 dagen in te loggen op de game servers van Battlefield zonder success.

Als jullie deze onzin niet hadden had ik kunnen zien wat het mogelijke probleem is maar nu wil ik restitutie want dit slaat echt NERGENS op. Anderen kunnen de game wel gewoon in dus leg ik het probleem/de schuld bij T-Mobile omdat ik immers niet kan troubleshooten.
Het ruikt behoorlijk naar hoe het voelde met Dtag….

Maar ook dat is niet te bewijzen/ontkrachten omdat we geen tracert meer hebben dus graag mijn geld terug. Ik kan al 6 maanden niet fatsoenlijk uploaden naar een remote nas en kan ook niet meer fatsoenlijk gamen en word behoorlijk pissed van lakse houding van T-Mobile.

Ik weet niet hoe het juridisch zit, maar ik heb nu een weekje T-Mobile 1Gbit maar liefste zou ik morgen weer terug bij de KPN zitten. Als ICT professional is het vreselijk irritant om niet eens een normale traceroute te kunnen uitvoeren, dat als eerste, maar los daarvan moet het internet gewoon goed werken en dat doet het niet. Sowieso de redenen om de traceroute te maskeren raken kant noch wal.

Ik heb allerlei vage problemen die ik bij KPN niet had. Deze worden ook bevestigd door een simpele test op http://ec2-reachability.amazonaws.com/ . Die faalt elke keer wel op een aantal willekeurige hosts in de EU. Deze connectieproblemen uiten zich op allerlei vervelende manieren tijdens normaal gebruik van het internet. Als ik deze test vanaf de lijn op mijn werk uitvoer is deze telkens 100% succesvol. Via T-Mobile is is simpelweg onmogelijk om een goede test uit te voeren, al probeer je het 1000x, telkens valt er wel een connectie weg en het lijkt altijd binnen de EU te zijn.

Zomaar wat voorbeelden:

• Websites openen niet, je staat te wachten. Je refreshed en ineens laad hij weer wél.
• Spelletjes van de kinderen die online gaan en voorheen perfect werkten, lopen nu regelmatig vast en moeten herstart worden. Als zij spelletjes spelen moet ik vrijwel de hele tijd in de buurt blijven om ze te assisteren als de boel weer onderuit gaat.
• Speedtest is 3 van de 4 keer niet uit te voeren, dan krijg je een connection error, probeer je het een aantal keer, dan loopt hij wel door, met gigabit snelheden.
• TV kijken is een drama geworden. Dit doen we via NLZIET. Dit ging voorheen prima, maar nu als je naar een andere zenden zapt, krijg je zwart beeld en gaat hij ‘laden’. Als je dan doorzapt en weer terug dan krijg je weer beeld, zolang dat loopt heb je beeld, maar owee als je gaat zappen.
• De hele internetervaring is gewoon ronduit slecht geworden. Ik ben eigenlijk alleen maar bezig de hele tijd te troubleshooten waarom dingen niet werken zoals ze moeten werken. Op mijn mobiel heb ik nu standaard het internet naar 4G van de KPN maar aangezet, want dan werkt alles tenminste normaal. Helaas is mijn bundel niet toereikend om dit 24/7 te doen.

Ik wil het liefste weer terug naar de KPN want als ik hier een jaar aan vast zit wordt ik gillend gek, Wat gaat T-Mobile hier aan doen? Ik heb hier te maken met een ondeugdelijk produkt. Als ik zo op Tweakers kijk, zijn er veel meer mensen met precies dezelfde problemen, dus het is zeker geen geïsoleerd geval.

Als ik die https://ec2-reachability.amazonaws.com/ uitvoer word bij mij alles rood,geen enkele groene connectie.

Gisteren verschillende malen getest,op verschillende tijden.

Samen met mijn Uploadprobleem wat nu al een dikke 7 Mnd duurt en de 3 hops Tracert is dit toch een serieus probleem op hun netwerk.

De laatste weken heb ik in het weekend en s,nachts wel de volle upload,dus ze hebben wel weer iets aangepast.

Postcode 5645

Deze pagina geeft ook via een 4G mobiel netwerk alles op rood. Dus dat lijkt me niet echt een goede test.

En dat is bij mij dus niet het geval,met 4G is bij mij alles groen.

bijzondere is als je diezelfde website op HTTP benaderd dat alles groen is.. ga je naar HTTPS is alles rood.

Net ff HTTPS uitgezet in Firefox en opnieuw geprobeerd,maar nog steeds alles rood,dus die vlieger gaat bij mij niet op.

Dat is raar.. Ik heb het nog even geprobeerd vanaf een andere internet verbinding en daar heb ik hetzelfde, HTTPS werkt niet en HTTP werkt wel.

Hmmm nu geprobeerd met Edge en daar werkt het wel met HTTP,alles groen.

Firefox blijft HTTPS geven wat ik ook probeer.