Beantwoord

Graag weer een volledige MTR / Traceroute / Sniffing / DPI

Toon eerste reactie

110 reacties

M
Reputatie 3

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. 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. 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. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

@Brian Ofwel je bent voor de 2e keer met een mooi verhaal terug gestuurd.

 

Zoals hier boven al gezegd prima als t-mobile niet wil laten zien hoe hun eigen netwerk eruit ziet.

Maar het verbergen / niet inzichtelijk maken van netwerken van andere partijen ….

Maar goed om te weten dat t-mobile zich aan de 'industry standard’ houd en de rest van de wereld niet. 

Voor een klein overzichtje van netwerken dat zich dan niet aan de 'industry standard’  houd.

kpn

ziggo

ntt

lumen / level3 

upc

bit

unet

eurofiber

comcast

surfnet

amazon

microsoft

google

bt

RIPE NCC 

DigitalOcean

Magyar Telekom Nyrt (mm grappig heeft hetzelfde logo.)

@Gerrit078 kan je delen hoever jij komt met dit verhaal. Gezien jij contact het via de mail. (een van de andere wegen die t-mobile zelf aanbied om in contact te komen..)

Volgens https://www.t-mobile.nl/klantenservice#contact heb je 3 opties tot contact. Lijkt me handig dat ze dan deze opties ook allemaal juist ondersteunen.

 

….

M
Reputatie 3

@Amy @Hajar @David @Willem @Mitch @Sander @Brian 
Mocht een klant nu een storing melden en jullie hebben voor analyse een mrt / Traceroute nodig. Dit gaat zolang die TTL nog word herschreven / verhoogt niet helpen.

M
Reputatie 3

@Boris een idee wanneer je weer kan vragen om een MTR als iemand problemen meld?

A

@Brian Aanvullend op wat @Thomas_R hierboven al zegt, en ik in mijn uiteenzetting hierboven:

Zoals Thomas stelt is de huidige manier een fix met schijnveiligheid. Met een IP Record Route ping kun je dit al omzeilen, met dus ook een aantal hops intern uit het T-Mobile netwerk.

Volgens mij is die niet helemaal compleet, tenminste … laatste keer dat ik een volledige traceroute had, zaten er heel wat meer IP-Adressen (hops) tussen. Volgens mij ontbreken er dus nog best een aantal. 

Maar goed, is het niet gewoon een kwestie voor kwaadwillende om een kijkje te nemen naar een lijst en daar gewoon te sniffen of gewoon direct ip-addressen binnen de subnet's eindigend op .1 en .254 een flinke DDos voor de kiezen te gooien?

 

A

Hallo heren @Mdevries @mdanielsnl @DirkTe  ,

Ik heb zojuist vernomen dat het onderzoek wat is uitgezet bij onze IT specialisten is gesloten. De terugkoppeling die ik heb ontvangen hierover, is dat de trace routes aankomen en dat er daardoor geen problemen zijn aan de routering. 

Volgens mij zegt ook nergens iemand niet hier - maar zelfs ook niet op Tweakers - dat de trace routes niet aan komen maar dat ze gelimiteerd worden in wat ze in werkelijkheid behoren te zijn. Precies wat @ijansen dus al zegt… je wordt (net als menig consument al geruime tijd wordt) van het kluitje in het riet gestuurd.

 

Ik begrijp dat dit niet het antwoord is wat duidelijkheid geeft en wil daarom kijken hoe we het best het probleem kunnen aankaarten. Ik wil jullie daarom vragen om na te gaan hoe de problemen met de trace hops zich manifesteren. Hoe ervaar je het probleem en hoe zie je dit terug? Op die manier kunnen we het concreter maken voor onze specialisten en werken naar een oplossing voor jullie. Ik hoor het graag! 

 

Doordat alle tussenliggende routes/switches worden verborgen is het voor menigeen niet langer mogelijk om te zien of een website of andere dienst niet bereikt kan worden door een storing bij T-Mobile, een tussenliggende partij of zelfs bij de partij alwaar de website of andere dienst zich bevind.

Een mooi voorbeeld met een Virtual Private Server (VPN) die ik voor deze ellende maar even besteld heb bij een toko waarbij je kunt garanderen dat ze geen directe verbinding hebben met T-Mobile en dus geen peering overeenkomsten hebben waardoor gebruik gemaakt wordt van Transit partijen;

Start: 2021-03-08T16:33:26+0100
HOST: anonymous                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS50266  143.178.32.1         0.0%     4    2.8   2.9   2.7   3.0   0.1
  2. AS35916  173.82.121.xxx       0.0%     4  155.3 155.8 155.3 156.7   0.7

 

T-Mobile doet hiermee voor komen alsof ze een directe verbinding hebben met de target wat totaal niet het geval is. Want, wat schetst ineens de verbazing, als vanaf diezelfde target plots naar een T-Mobile Thuis IP-Adres een trace route wordt gedaan, dan is deze plotseling;

Start: 2021-03-08T16:37:21+0100
HOST: ns2                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS35916  72.44.73.193         0.0%     4    0.3   2.9   0.3  10.3   4.9
  2. AS35916  72.44.66.201         0.0%     4    0.9   1.3   0.9   2.1   0.5
  3. AS174    38.99.219.57         0.0%     4    0.7   0.7   0.7   0.9   0.1
  4. AS174    154.54.40.146        0.0%     4   12.9  13.0  12.9  13.1   0.1
  5. AS174    154.54.5.102         0.0%     4   13.4  13.5  13.4  13.6   0.1
  6. AS174    154.54.11.206        0.0%     4   11.1  13.1  11.0  19.0   3.9
  7. AS1273   195.2.24.98          0.0%     4  153.0 152.9 152.6 153.0   0.2
  8. AS1273   195.2.31.6           0.0%     4  155.1 155.0 154.3 155.3   0.5
  9. AS1273   195.2.28.37          0.0%     4  145.2 145.5 145.2 145.6   0.2
 10. AS1273   195.2.3.245          0.0%     4  157.0 157.8 154.8 160.6   2.5
 11. AS1273   217.161.69.142       0.0%     4  154.8 154.9 154.8 154.9   0.0
 12. AS???    ???                 100.0     4    0.0   0.0   0.0   0.0   0.0
 13. AS50266  143.178.xxx.xxx       0.0%     4  155.7 155.3 155.1 155.7   0.3

 

Waarom mensen trace routes willen zien? Als zich nu plots ellende afspeelt bij bijvoorbeeld AS1273 en het uiteindelijke doel niet bereikt kan worden willen mensen wel weten of de ellende zich afspeelt bij T-Mobile of elders in de routering. Iets wat T-Mobile nu bewust lijkt te verhullen.

Ergens riekt dit naar misleiding naar je klanten (huidige en toekomstige). Doen alsof T-Mobile directe verbindingen heeft met allerhande aan partijen wat in feite totaal niet het geval is. 

Nog slordiger is het dat T-Mobile deze keus bewust lijkt te hebben gemaakt zonder ook maar enige consument op de hoogte te hebben gebracht. Ergens hadden klanten de hoop dat T-Mobile inmiddels wel wat geleerd heeft van de DTAG problemen, maar klaarblijkelijk is T-Mobile een heel stuk hardleerser dan de concurrentie.

A

@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.

 

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.

 

 

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

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 ?

 

H
Reputatie 4

Zozo ik krijg ineens meer dan 1 hop te zien weer:

 

>tracert nu.nl

Tracing route to nu.nl [13.224.228.82]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  172.16.0.1
  2     2 ms     2 ms     2 ms  1-192-187-31.ftth.glasoperator.nl [31.187.192.1]
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5    14 ms    34 ms    14 ms  ae23-xcr1.ltw.cw.net [195.2.31.13]
  6     8 ms     9 ms     8 ms  195.89.101.53
  7    14 ms    15 ms    14 ms  ae23-xcr1.ltw.cw.net [195.2.31.13]
  8    14 ms    14 ms    17 ms  99.83.70.82
  9     *        *        *     Request timed out.
 10    14 ms    14 ms    14 ms  150.222.65.99
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16    15 ms    14 ms    14 ms  server-13-224-228-82.lhr61.r.cloudfront.net [13.224.228.82]



Nou hier is er nog altijd niets veranderd. 

 

C:\Windows\System32>tracert 13.224.228.82

Tracing route to server-13-224-228-82.lhr61.r.cloudfront.net [13.224.228.82]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2     2 ms     2 ms     2 ms  1-224-178-143.ftth.glasoperator.nl [143.178.224.1]
  3     8 ms     8 ms     8 ms  server-13-224-228-82.lhr61.r.cloudfront.net [13.224.228.82]

Trace complete.


Hier is toch iets veranderd. ik heb nu voor het eerste weer normale traceroutes en frappant genoeg zijn alle rode stoppen van de connectie checker als sneeuw voor de zon vertrokken.
 

C:\Windows\System32>tracert 13.224.228.82

Tracing route to server-13-224-228-82.lhr61.r.cloudfront.net [13.224.228.82]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2     2 ms     2 ms     2 ms  1-224-178-143.ftth.glasoperator.nl [143.178.224.1]
  3     4 ms     4 ms     4 ms  10.10.10.170
  4    18 ms     3 ms     3 ms  195.89.101.53
  5     3 ms     3 ms     3 ms  195.89.101.53
  6     8 ms     8 ms     8 ms  ae23-xcr1.ltw.cw.net [195.2.31.13]
  7     9 ms     9 ms     9 ms  99.83.70.82
  8     *        *        *     Request timed out.
  9     8 ms     8 ms     8 ms  150.222.65.107
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     8 ms     8 ms     8 ms  server-13-224-228-82.lhr61.r.cloudfront.net [13.224.228.82]

Trace complete.



Nu de upload nog T-Mobile je ben er bijna.  Maar dat lijkt me toch echt een capaciteit probleem want vannacht had ik op bijna lle servers volle upload en download en mijn download is zelfs 20 mbit sneller als het de afgelopen 6 maanden geweest is. maar upload hangt overdag nog gewoon rond de 300 max.
Of het geheel stabiel is valt nog te zien. Gister rond 11 uur in de avond voor het laatst offline momentje gehad. Zelfs de tv had er geen zin meer in.

A

Toch nog vreemde resultaten voor een traceroute naar nu.nl ……

 

tracert nu.nl

Tracing route to nu.nl [13.224.66.25]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  172.16.0.1
  2     3 ms     2 ms     2 ms  1-192-187-31.ftth.glasoperator.nl [31.187.192.1]

 30     *        *        *     Request timed out.

 

Het lijkt me sterk dat naar nu.nl meer dan 30 hops is.

 

nu.nl draait bij Cloudfront, 

Als je die timeouts er tussenuit haalt zit je op 17-18 hops.

 

Was in het verleden ook niet veel anders trouwens.

Boris
Rank
Reputatie 7

Hoi @Mdevries @mdanielsnl ,

Dank jullie wel voor het aangeven van de situatie! Ik ga dit graag voor jullie oppakken. Wil je ook jouw tracert met ons delen @mdanielsnl , dan kunnen we beide situaties naast elkaar neerleggen en onderzoeken. Ik hoor het graag!

M
Reputatie 3

@Boris 

vanaf 81.21.136.3 naar 31.201.232.247 zijn de ping gegevens

64 bytes from 247-232-201-31.ftth.glasoperator.nl (31.201.232.247): icmp_seq=1 ttl=248 time=7.84 ms

vanaf 31.201.232.247 naar 81.21.136.3

64 bytes from 81.21.136.3: icmp_seq=0 ttl=57 time=8.957 ms

Ik heb de TTL tijden vet gemaakt zodat het duidelijk zichtbaar is.


Zelfs naar Australië heb je geen TTL van 248 nodig.

Trace met TTL verandering.

                                                     My traceroute  [v0.93]
MV-Mac (172.17.102.4)                                                                                   2021-02-02T12:23:48+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                        Packets               Pings
 Host                                                                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    172.17.102.254 (172.17.102.254)                                           0.0%    14    1.7   1.9   1.3   3.6   0.7
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)                            0.0%    14    4.8   4.0   2.5   9.5   1.9
 3. AS16509  ec2-13-210-46-145.ap-southeast-2.compute.amazonaws.com (13.210.46.145)    0.0%    13  283.2 284.5 282.8 289.5   2.2

Trace zonder TTL verandering

 

                                                             My traceroute  [v0.92]
signet01.ring.nlnog.net (81.21.136.3)                                                                                  2021-02-02T11:24:45+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                       Packets               Pings
 Host                                                                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. son-er-dc1.signet.nl                                                                              0.0%     7    3.9   3.6   0.4   8.2   3.2
 2. ams-cr2-sara.v92.signet.nl                                                                        0.0%     7   13.4   5.5   1.8  13.4   4.2
 3. ams-cr1-gls.tc.signet.nl                                                                          0.0%     7    2.6   2.5   2.3   2.6   0.1
 4. be10-300.cr1.nkf.as49685.net                                                                      0.0%     7    4.0   4.3   2.6  11.8   3.4
 5. a3718.as49685.atom86.net                                                                          0.0%     7    3.8   3.3   2.4   5.4   1.1
 6. available.atom86.net                                                                              0.0%     7    2.5   3.6   2.4   6.4   1.6
 7. ???
 8. i-1008.ulcn-core01.telstraglobal.net                                                              0.0%     7   16.9  16.8  16.7  16.9   0.1
 9. 202.84.249.174                                                                                    0.0%     7   83.1  81.7  80.3  83.1   1.2
10. i-10748.paix-core02.telstraglobal.net                                                             0.0%     7  147.0 148.3 147.0 149.0   0.7
11. i-37.sydo-core03.telstraglobal.net                                                                0.0%     7  286.8 287.1 286.4 288.1   0.7
12. bundle-ether3.oxf-gw11.sydney.telstra.net                                                         0.0%     7  285.4 286.0 285.4 286.5   0.4
13. bundle-ether1.chw-core10.sydney.telstra.net                                                       0.0%     7  287.3 287.3 286.6 287.7   0.3
14. bundle-ether1.chw-edge903.sydney.telstra.net                                                      0.0%     7  286.1 286.3 286.1 286.6   0.2
15. ama3305026.lnk.telstra.net                                                                        0.0%     7  286.3 286.5 286.2 287.1   0.3
16. ???
17. ???
18. ???
19. ???
20. ???
21. ???
22. ???
23. ???
24. ???
25. ???
26. ???
27. amazon08.ring.nlnog.net                                                                           0.0%     6  286.9 286.9 286.9 287.0   0.0

 

yalerta
Reputatie 7
Badge +5

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 [217.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 [62.115.136.194]
  8    25 ms    24 ms    25 ms  ffm-bb1-link.ip.twelve99.net [62.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 [62.115.114.185]
 11    24 ms    29 ms    23 ms  akamai-ic317493-win-b2.ip.twelve99-cust.net [62.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 :kissing_smiling_eyes:

Komt tijd, komt raad. En ik maar raden waar de tijd blijft maar doe ondertussen of ik er verstand van heb
A

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. 

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.

Dat durf ik bijna niet te doen, ik ben al beschuldigd van conspiracy denken door @Brian.

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.

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 :kissing_smiling_eyes:

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.

 

Pieter_B
Rank
Reputatie 7
Badge +3

@mdanielsnl 

TTL is bepaald door de OS of type device.

Common TTL values

  • Router - 255
  • Windows - 128
  • Linux-Mac - 64

Default Time To Live (TTL) values

LET OP gewoon Medeklant. Glasvezel sinds 2016 (1Gb and never needs more) - Linux gebruiker sinds 2006 ( Current: Kubuntu mantic 23.10 )- DIY Router/Firewall: pfSense 2.7.0 met 4 port INTEL NIC & Switch Unifi 8 poort 60w POE & Switch Unifi 8 poort & Wifi Unifi AP-AC Pro
A

Aangezien je blijkbaar nergens een lap tekst kwijt kan aan T-Mobile, probeer ik het eerst hier. Ik wil dat T-Mobile hierop gaat reageren met iets concreets:

 

Je eigen tekst kun je gerust kwijt, maar T-Mobile lijkt het bewust te hebben verstopt zodat iedereen naar het forum gaat, ook als je belt worden mensen in dit soort gevallen doorverwezen naar jawel… verrassing het forum!

Mensen die klachten/problemen hebben of T-Mobile gewoonweg in gebreke willen stellen, kunnen aankaarten door een e-mail sturen naar klantenservice@t-mobilethuis.nl. met in de subject hun klantnummer. Nog mooier wordt het als je hierin ook direct ACM Consuwijzer ( info@consuwijzer.nl ) even CC't 

Mooiste is wanneer iedereen in dat geval direct screenshots stuurt en alles zo goed mogelijk onderbouwt.  Vergeet niet ook even te verwijzen naar dit forum topic, zodat de ACM hier eventueel nog meer kan terugvinden.

D

Hier ook hetzelfde issue:

 

 Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. fritz.box                                             0.0%     9    0.4   0.4   0.4   0.5   0.0
 2. 1-224-145-85.ftth.glasoperator.nl                     0.0%     9    2.0   1.9   1.7   2.2   0.2
 3. dns.google                                            0.0%     9    6.6   6.6   6.4   7.0   0.2

Pieter_B
Rank
Reputatie 7
Badge +3

@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.

LET OP gewoon Medeklant. Glasvezel sinds 2016 (1Gb and never needs more) - Linux gebruiker sinds 2006 ( Current: Kubuntu mantic 23.10 )- DIY Router/Firewall: pfSense 2.7.0 met 4 port INTEL NIC & Switch Unifi 8 poort 60w POE & Switch Unifi 8 poort & Wifi Unifi AP-AC Pro
D

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.

D
Reputatie 2

 

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

sluit ik me graag bij aan.

 

 

M
Reputatie 3

@mdanielsnl

TTL is bepaald door de OS of type device.

Common TTL values

  • Router - 255
  • Windows - 128
  • Linux-Mac - 64

Default Time To Live (TTL) values

@Pieter_B met een TTL van 3 hoor ik google niet te kunnen pingen. Immers in het echt zitten er meer dan 3 hops tussen mij en google in.
Echter door die TTL rewrite gaat het allemaal helemaal prima.

ping -m 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=119 time=7.569 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.795 ms

bijbehorende mrt:

                                       My traceroute  [v0.93]
MV-Mac (172.17.102.4)                                                      2021-02-02T15:11:05+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                           Packets               Pings
 Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    172.17.102.254 (172.17.102.254)              0.0%    12    1.6   2.7   1.3   8.3   2.5
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16  0.0%    11    2.9   4.0   2.6   9.6   2.6
 3. AS15169  dns.google (8.8.8.8)                         0.0%    11    5.4   6.2   5.0  11.7   1.9

Dat werkt over de t-mobile glas. (hier zet ik zal de TTL op 3 )
man ping:
-m ttl  Set the IP Time To Live for outgoing packets.  If not specified, the kernel uses the value of the net.inet.ip.ttl MIB variable.

zelfde maar dan met een t-mobile simkaart:

 ping -m 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C
--- 8.8.8.8 ping statistics ---

 

met als mrt:

                                       My traceroute  [v0.93]
MV-Mac (192.168.206.70)                                                    2021-02-02T15:10:34+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                           Packets               Pings
 Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    192.168.206.216 (192.168.206.216)            0.0%     3   13.1  14.7   3.6  27.5  12.0
 2. (waiting for reply)
 3. (waiting for reply)
 4. (waiting for reply)
 5. (waiting for reply)
 6. AS31615  84.241.225.42 (84.241.225.42)                0.0%     2  156.3 156.3 156.3 156.3   0.0
 7. AS15169  72.14.196.142 (72.14.196.142)                0.0%     2   52.0  52.0  52.0  52.0   0.0
 8. AS15169  108.170.241.193 (108.170.241.193)            0.0%     2  510.3 510.3 510.3 510.3   0.0
 9. AS15169  108.170.236.139 (108.170.236.139)            0.0%     2  404.9 404.9 404.9 404.9   0.0
10. AS15169  dns.google (8.8.8.8)                         0.0%     2  299.6 299.6 299.6 299.6   0.0

is.

 

Hop 6-9 zitten zeker ook bij de glas verbinding echter door die rewrite zie je het niet.

M
Reputatie 3

pff zucht.

MacBook-Pro.local (172.17.102.6) -> transip.nl                                2021-05-23T14:29:24+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                              Packets               Pings
 Host                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    172.17.102.254 (172.17.102.254)                 0.0%    11  104.8  40.1   1.2 104.8  40.7
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)  0.0%    11    2.5  65.9   2.0 223.6  82.2
 3. AS???    10.10.10.153 (10.10.10.153)                     0.0%    11  125.3  95.9   7.2 196.6  61.6
 4. AS???    10.10.80.137 (10.10.80.137)                     0.0%    11   27.3  31.9   7.8 102.7  30.1
 5. AS20857  e1-a0.r1.ams0.transip.net (157.97.168.8)        0.0%    11   11.0  57.5   8.1 154.7  61.0
 6. AS???    m6.e1.ams0.transip.net (80.249.208.244)         0.0%    10  128.8  60.2   7.2 155.9  57.5
 7. AS20857  e1-a0.r1.ams0.transip.net (157.97.168.8)        0.0%    10   27.1  58.6   7.1 145.2  51.5
 8. AS20857  r1.s2.t2.ams0.transip.net (37.97.252.131)       0.0%    10  163.9  90.8  21.9 183.4  62.5
 9. AS20857  s2.l4.t2.ams0.transip.net (37.97.252.71)        0.0%    10   49.8  99.7  26.6 181.3  48.3
10. AS20857  www.transip.nl (37.97.254.1)                    0.0%    10    8.0  60.0   7.5 189.7  64.1

Geen idee wat ze nu weer aan het doen zijn.

Maar een router bereiken bij hop 5 die je ook bij hop 7 heb …

Nee transip is niet de enige:

MacBook-Pro.local (172.17.102.6) -> google.nl                                 2021-05-23T14:30:20+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                              Packets               Pings
 Host                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    172.17.102.254 (172.17.102.254)                 0.0%    10    2.3   1.7   0.9   3.2   0.7
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)  0.0%    10    2.4   3.0   2.2   4.6   0.8
 3. AS???    10.10.10.153 (10.10.10.153)                     0.0%    10    8.4   8.1   7.0   9.4   0.8
 4. AS???    10.10.80.137 (10.10.80.137)                     0.0%    10    7.7   7.7   7.3   9.0   0.5
 5. AS15169  108.170.241.225 (108.170.241.225)               0.0%    10    9.0   9.4   8.1  10.7   0.9
 6. (waiting for reply)
 7. AS15169  108.170.241.225 (108.170.241.225)               0.0%    10    9.3   8.8   7.8  10.3   0.7
 8. AS15169  108.170.241.236 (108.170.241.236)               0.0%    10    7.5   8.5   7.0  12.3   1.5
 9. AS15169  209.85.255.230 (209.85.255.230)                66.7%    10   24.7  18.9   8.7  24.7   8.8
10. AS15169  108.170.234.119 (108.170.234.119)              75.0%     9   13.9  14.2  13.9  14.5   0.4
11. AS15169  216.239.59.4 (216.239.59.4)                     0.0%     9   13.5  14.0  13.3  16.2   0.8
12. AS15169  74.125.242.65 (74.125.242.65)                   0.0%     9   13.0  13.6  12.8  15.1   0.7
13. AS15169  142.250.215.125 (142.250.215.125)               0.0%     9   12.9  13.2  12.7  14.6   0.6
14. AS15169  lhr48s27-in-f3.1e100.net (142.250.178.3)        0.0%     9   15.4  14.4  13.8  15.6   0.7

 

en 

 

MacBook-Pro.local (172.17.102.6) -> community.t-mobile.nl                     2021-05-23T14:31:15+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                              Packets               Pings
 Host                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    172.17.102.254 (172.17.102.254)                 0.0%     6    0.9   1.5   0.9   2.1   0.4
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)  0.0%     6    2.0   2.4   2.0   3.5   0.6
 3. AS???    10.10.10.153 (10.10.10.153)                     0.0%     6    6.9   7.8   6.9   9.4   0.9
 4. AS???    10.10.80.137 (10.10.80.137)                     0.0%     6    7.9   8.3   7.3   9.9   1.1
 5. AS???    52.93.0.102 (52.93.0.102)                       0.0%     6    9.2   8.6   8.1   9.2   0.4
 6. AS???    amsix01-ams1.amazon.com (80.249.210.100)        0.0%     6    6.9   8.8   6.9  11.4   1.5
 7. AS???    52.93.0.102 (52.93.0.102)                       0.0%     6   13.2  10.0   8.4  13.2   1.7
 8. AS???    150.222.107.9 (150.222.107.9)                   0.0%     6    7.6   8.3   7.6   9.9   0.9
 9. (waiting for reply)
10. (waiting for reply)
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. AS16509  server-52-222-139-107.ams50.r.cloudfront.net (  0.0%     5    7.5   8.1   7.2   9.1   0.9

 

Kan al die “slimmigheid” en “industrie standaard” geneuzel er gewoon uit?

M
Reputatie 1

Man wat is dit nou weer voor een gepruts, ik heb het ook vanaf mijn t-mobile lijn.

Tracing route to transip.nl [37.97.254.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  172.16.0.1
  2     2 ms     2 ms     2 ms  1-192-187-31.ftth.glasoperator.nl [31.187.192.1]
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     9 ms     9 ms     9 ms  e1-a0.r1.ams0.transip.net [157.97.168.8]
  6     9 ms     9 ms     9 ms  m6.e1.ams0.transip.net [80.249.208.244]
  7     9 ms     9 ms     9 ms  e1-a0.r1.ams0.transip.net [157.97.168.8]
  8    23 ms    20 ms    58 ms  r1.s1.t2.ams0.transip.net [37.97.252.129]
  9    23 ms    21 ms    22 ms  s1.l4.t2.ams0.transip.net [37.97.252.7]
 10     8 ms     8 ms     9 ms  www.transip.nl [37.97.254.1]

Trace complete.

M
Reputatie 3

@Brian 

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

Dit waren de vragen die ik acht dagen geleden stelde. Je zou destijds daar ‘volgende week’ antwoord op geven. Tot op heden heb ik nog geen antwoord gezien, nog sterker geen enkele reactie meer.

Om heel eerlijk te zijn snap ik niet dat je dit uberhaupt moet navragen. Het lijkt me dat een change als het slopen van alle traceroutes eerst intern besproken wordt en iedereen daarvan op de hoogte is.

G

Tracing route to transip.nl [37.97.254.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2     2 ms     1 ms     1 ms  1-16-144-85.ftth.glasoperator.nl [85.144.16.1]
  3     7 ms     7 ms     7 ms  10.10.10.153
  4     7 ms     6 ms     6 ms  10.10.80.137
  5     7 ms     7 ms     7 ms  e1-a0.r1.ams0.transip.net [157.97.168.8]
  6     7 ms     6 ms     6 ms  m6.e1.ams0.transip.net [80.249.208.244]
  7    15 ms     7 ms     6 ms  e1-a0.r1.ams0.transip.net [157.97.168.8]
  8    25 ms    19 ms    19 ms  r1.s1.t2.ams0.transip.net [37.97.252.129]
  9    25 ms    19 ms    19 ms  s1.l4.t2.ams0.transip.net [37.97.252.7]
 10     7 ms     7 ms     7 ms  www.transip.nl [37.97.254.1]


Yep 5 en 7 hetzelfde

M
Reputatie 3

@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.
J
Reputatie 3

Bij mij zijn de traceroutes nog net zo stuk en gefilterd als ze altijd al geweest zijn. Ik woon in WBA gebied (Emmen). T-Mobile heeft blijkbaar alleen voor een aantal regio’s de situatie aangepast, en niet voor iedereen.

Ontwikkelaar & auteur van https://antennekaart.nl | https://www.antenneforum.nl

Reageer


ForumvoorwaardenCookie instellingen