Telenet knijpt bittorrent: hoe ze het doen
Geplaatst: 26 jun 2011, 01:08
Intro
Enkele maanden terug deed ik een upgrade van Turbonet XL naar Fibernet Business L om van de onzin van "vrij downloaden" af te zijn.
Met vrij downloaden wist ik nooit waar ik stond: meetbare en objectieve criteria ontbraken en ik moest mij maar tevreden stellen met een JPEG met standje 0 tot 9. Als ik dan over de vage en niet objectieve limiet ging, en youtube en alle soorten streaming onkijkbaar geworden waren, weigerde telenet mij het gemiddelde mede te delen van alle gebruikers met mijn product, iets waar ik contractueel recht op had want het was deel van hun voorwaarden. Maar telenet vertikte het.
Dus deed ik de upgrade naar Fibernet Business L. Ik betaal relatief meer dan de consumer abbonnementen, heb vaste limiet van 1 Terrabyte, en een specificatie van 60 mbps down en 3.5 mbps down. Na onze verhuis van een boerengat naar een gemeente vlakbij Gent, stelde ik vast dat ik via bittorrent een debiel lage snelheid haalde.
Wel bekende protocollen zoals HTTP deden wel de volle snelheid op het moment dat torrent afgeknepen werd, dus dit kon onmogelijk aan een verzadigde node of netwerk liggen, maar aan shaping.
Via de pers en sites zoals deze werd mijn vermoede bevestigt: telenet knijpt torrents dicht. Omdat ik premium betaal om een harde limiet te kunnen gebruiken, wil ik dan nog enige snelheid overhouden. Anders heeft een fantastische specificatie geen enkele zin, en kan ik maar beter een adsl/vdsl lijntje nemen waar ik voor 40 eur geen limiet heb en een 16.5 mbps lijnprofiel.
helpdesk
Vrijdag 2x gebeld, helpdesk viel uit de lucht. Toen ik ze er op attent maakte dat het op alle IT en userbase-alike sites stond, viel ze weeral uit de lucht.
Worden telenet helpdeskers opgeleid om zich voor den domme uit te geven of zijn ze effectief ....
Ik heb ondertussen ook al een klacht neergelegd via het klachtenformulier, maar geen reactie.
Observaties
Waar ik in de vorige woning maximale snelheden haalde met torrent, haal ik op de nieuwe locatie slechts zo'n 10 mbps down en naar gelang het moment 0.5mbps tot 1 mbps up. Dit is dan nog met torrent encryptie aan. Enkel 's nachts gaat het echt vooruit, maar daarvoor betaal ik geen premium bedrag. Ik krijg nu dezelfde service als een klant met vrij downloaden die als grootgebruiker gebrandmerkt werd, zelfs zonder aan mijn 1 Terrabyte limiet te komen.
Als ik tijdens het dichtknijpen van torrent tegelijkterijd een speedtest doe naar een officiële site, haal ik waanzinnige waardes: tot 70 mbps down, en 4.5mbps up.
Als mijn bittorrent traffic encrypted is, hoe kan telenet alsnog de boel vertragen ? Ik heb het antwoord daarop gevonden.
Achtergrond
Ik heb een half jaar met packet shapers mogen spelen als test design engineer bij een bedrijf wat satellietcommunicatie verkoopt.
Ik heb dus heel wat traffic testen geschreven waarbij mensen via een FUP systeem selectief en gradueel vertraagt werden, zelfs tot 10.000 clients.
Ik heb dus wel wat baggage om 't een en 't ander dus toe te lichten.
De vuile was van de telenet shaper
Volgens mijn research kan telenet niet in encrypted packets kijken, maar ze correleren wel het bestaan van tracker traffic, om zo de niet gekende protocollen alsnog te vertragen.
Het bestaan van tracker verkeer triggert de telenet shaper om alle onbekende protocollen te straffen
Het bewijs
1) Als bittorrent openstaat, maar alle downloads & uploads zijn gepauzeerd, maar er is tracker communicatie
![Afbeelding](http://img6.imageshack.us/img6/8991/idletorrent.png)
- telenet vertraagt alle uploads van ongekende protocollen tussen de 0.5 en 1.5 mbps (we betalen voor 3.5mbps)
Dit zijn de logs van iperf testjes aan de serverzijde (de ontvangende kant), waarbij ik traffic stuur van mijn NAS achter een Telenet Fibernet Business Large naar m'n datacenter machine die 100mbps vlot doet:
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 33353
[ 4] 0.0-10.6 sec 1.74 MBytes 1.38 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 33354
[ 5] 0.0-10.6 sec 1.73 MBytes 1.38 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59928
[ 4] 0.0-10.3 sec 1.68 MBytes 1.36 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59929
[ 5] 0.0-10.1 sec 1.57 MBytes 1.30 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59931
[ 4] 0.0-10.5 sec 1.73 MBytes 1.38 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59932
[ 5] 0.0-10.6 sec 1.74 MBytes 1.38 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59933
[ 4] 0.0-10.2 sec 1.71 MBytes 1.41 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59934
[ 5] 0.0-10.4 sec 1.71 MBytes 1.38 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 48452
[ 4] 0.0-10.3 sec 1.70 MBytes 1.39 Mbits/sec
En de bijhorende spike op m'n router die aan telenet hangt tijdens zo'n iperf testje:
![Afbeelding](http://img855.imageshack.us/img855/1214/iperftestmetidletorrent.png)
Je ziet dat de telenet lijn buiten de spike zo goed als idle is !
Zo'n spike geeft 1 van de tiental testjes zoals hierboven beschreven weer.
2) Als de torrent client enkele minuten uit staat, krijgen we terug de volle snelheid van telenet voor uploads:
Alle http connecties naar de torrent tracker zijn verdwenen. Let goed wat de telenet shaper dan doet:
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 60405
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.8 sec 5.96 MBytes 4.62 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 60406
[ 5] 0.0-10.8 sec 5.96 MBytes 4.64 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 60407
[ 4] 0.0-11.1 sec 6.15 MBytes 4.64 Mbits/sec
Yep, de upload wordt plots terug de volle specificatie van mijn product.
![Afbeelding](http://img26.imageshack.us/img26/4420/iperftestzonderidletorr.png)
De upload spikes van dezelfde iperf test bewijzen dit. Ditmaal zonder idle torrent tracker verkeer.
Elke rode bult is zo'n traffic burst van iperf die 10 seconden duurt.
DUS TELENET VERTRAAGT ALLE ONGEKENDE PROTOCOLLEN ALS ZE P2P DETECTEREN
3) Leggen we nu opnieuw een torrent client aan, met idle traffic en enkel tracker communicatie
Dan begint de telenet shaper opnieuw te knijpen tot 1.40mbit
# iperf -s -p 80
------------------------------------------------------------
Server listening on TCP port 80
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 45536
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.2 sec 1.70 MBytes 1.40 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 45537
[ 5] 0.0-10.2 sec 1.71 MBytes 1.41 Mbits/sec
![Afbeelding](http://img837.imageshack.us/img837/1214/iperftestmetidletorrent.png)
Als we na deze iperf test en onze idle torrent client nog steeds actief een speedtest draaien, dan krijgen we wel een totaal ander resultaat:
![Afbeelding](http://img833.imageshack.us/img833/9117/speedtestwordtnietgesha.png)
Speedtest, http en andere favoriete protocollen in de shaperdefinitie worden dus nooit geknepen, maar onze iperf test dus wel. Nochtans is iperf geen P2P verkeer en gewoon een onschuldige snelheidstest.
En om aan te tonen dat speedtest niet liegt nog maar even de router graphs:
![Afbeelding](http://img11.imageshack.us/img11/341/speedtestrouter.png)
Je kan mooi de volgorde van de speedtest zien: eerst download die over de 60 mbps gaat, en dan de upload.
Hoe werkt de telenet shaper
* protocollen die telenet graag ziet krijgen de full speed, dus ook de speedtest sites, ongeacht of je nu torrents hebt openstaan
* non-encrypted torrent krijgt een debiel lage speed, bvb 10 kbyte upstream
* onbekende protocollen krijgen ook full speed, tenzij torrent tracker communicatie wordt gespot
* in dat laatste geval krijgen onbekende protocollen ook een lagere snelheid, omdat telenet dan ervan uitgaat dat al wat niet gekend is, bittorrent moet zijn (encryptie)
* deze verlaagde snelheid is niet even debiel laag als non-encrypted torrent, omdat ze dan misschien te zwaar in voip of video knippen en er teveel klachten zouden komen
Dus:
- de telenet shaper is gebaseerd op deep packet inspection en/of correlatie
- hij correleert onbekende traffiek met tracker traffiek, de torrent traffic is immers rc4 encrypted
- als hij P2P tracker traffic ziet, policed hij alle onbekende traffic zwaar, ook de onschuldige iperf testjes
Ook IMAPS moet sneuvelen:
http://userbase.be/forum/viewtopic.php? ... 40#p385897
En dit kan volgens ons niet. Hier gaat telenet te ver. Ik heb hiermee bewezen dat Telenet een gebrekkig product levert.
Wie mijn verhaal begrijpt zal nu ook snappen hoe de telenet shaper helemaal te bypassen.
Enkele maanden terug deed ik een upgrade van Turbonet XL naar Fibernet Business L om van de onzin van "vrij downloaden" af te zijn.
Met vrij downloaden wist ik nooit waar ik stond: meetbare en objectieve criteria ontbraken en ik moest mij maar tevreden stellen met een JPEG met standje 0 tot 9. Als ik dan over de vage en niet objectieve limiet ging, en youtube en alle soorten streaming onkijkbaar geworden waren, weigerde telenet mij het gemiddelde mede te delen van alle gebruikers met mijn product, iets waar ik contractueel recht op had want het was deel van hun voorwaarden. Maar telenet vertikte het.
Dus deed ik de upgrade naar Fibernet Business L. Ik betaal relatief meer dan de consumer abbonnementen, heb vaste limiet van 1 Terrabyte, en een specificatie van 60 mbps down en 3.5 mbps down. Na onze verhuis van een boerengat naar een gemeente vlakbij Gent, stelde ik vast dat ik via bittorrent een debiel lage snelheid haalde.
Wel bekende protocollen zoals HTTP deden wel de volle snelheid op het moment dat torrent afgeknepen werd, dus dit kon onmogelijk aan een verzadigde node of netwerk liggen, maar aan shaping.
Via de pers en sites zoals deze werd mijn vermoede bevestigt: telenet knijpt torrents dicht. Omdat ik premium betaal om een harde limiet te kunnen gebruiken, wil ik dan nog enige snelheid overhouden. Anders heeft een fantastische specificatie geen enkele zin, en kan ik maar beter een adsl/vdsl lijntje nemen waar ik voor 40 eur geen limiet heb en een 16.5 mbps lijnprofiel.
helpdesk
Vrijdag 2x gebeld, helpdesk viel uit de lucht. Toen ik ze er op attent maakte dat het op alle IT en userbase-alike sites stond, viel ze weeral uit de lucht.
Worden telenet helpdeskers opgeleid om zich voor den domme uit te geven of zijn ze effectief ....
Ik heb ondertussen ook al een klacht neergelegd via het klachtenformulier, maar geen reactie.
Observaties
Waar ik in de vorige woning maximale snelheden haalde met torrent, haal ik op de nieuwe locatie slechts zo'n 10 mbps down en naar gelang het moment 0.5mbps tot 1 mbps up. Dit is dan nog met torrent encryptie aan. Enkel 's nachts gaat het echt vooruit, maar daarvoor betaal ik geen premium bedrag. Ik krijg nu dezelfde service als een klant met vrij downloaden die als grootgebruiker gebrandmerkt werd, zelfs zonder aan mijn 1 Terrabyte limiet te komen.
Als ik tijdens het dichtknijpen van torrent tegelijkterijd een speedtest doe naar een officiële site, haal ik waanzinnige waardes: tot 70 mbps down, en 4.5mbps up.
Als mijn bittorrent traffic encrypted is, hoe kan telenet alsnog de boel vertragen ? Ik heb het antwoord daarop gevonden.
Achtergrond
Ik heb een half jaar met packet shapers mogen spelen als test design engineer bij een bedrijf wat satellietcommunicatie verkoopt.
Ik heb dus heel wat traffic testen geschreven waarbij mensen via een FUP systeem selectief en gradueel vertraagt werden, zelfs tot 10.000 clients.
Ik heb dus wel wat baggage om 't een en 't ander dus toe te lichten.
De vuile was van de telenet shaper
Volgens mijn research kan telenet niet in encrypted packets kijken, maar ze correleren wel het bestaan van tracker traffic, om zo de niet gekende protocollen alsnog te vertragen.
Het bestaan van tracker verkeer triggert de telenet shaper om alle onbekende protocollen te straffen
Het bewijs
1) Als bittorrent openstaat, maar alle downloads & uploads zijn gepauzeerd, maar er is tracker communicatie
![Afbeelding](http://img6.imageshack.us/img6/8991/idletorrent.png)
- telenet vertraagt alle uploads van ongekende protocollen tussen de 0.5 en 1.5 mbps (we betalen voor 3.5mbps)
Dit zijn de logs van iperf testjes aan de serverzijde (de ontvangende kant), waarbij ik traffic stuur van mijn NAS achter een Telenet Fibernet Business Large naar m'n datacenter machine die 100mbps vlot doet:
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 33353
[ 4] 0.0-10.6 sec 1.74 MBytes 1.38 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 33354
[ 5] 0.0-10.6 sec 1.73 MBytes 1.38 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59928
[ 4] 0.0-10.3 sec 1.68 MBytes 1.36 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59929
[ 5] 0.0-10.1 sec 1.57 MBytes 1.30 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59931
[ 4] 0.0-10.5 sec 1.73 MBytes 1.38 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59932
[ 5] 0.0-10.6 sec 1.74 MBytes 1.38 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59933
[ 4] 0.0-10.2 sec 1.71 MBytes 1.41 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 59934
[ 5] 0.0-10.4 sec 1.71 MBytes 1.38 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 48452
[ 4] 0.0-10.3 sec 1.70 MBytes 1.39 Mbits/sec
En de bijhorende spike op m'n router die aan telenet hangt tijdens zo'n iperf testje:
![Afbeelding](http://img855.imageshack.us/img855/1214/iperftestmetidletorrent.png)
Je ziet dat de telenet lijn buiten de spike zo goed als idle is !
Zo'n spike geeft 1 van de tiental testjes zoals hierboven beschreven weer.
2) Als de torrent client enkele minuten uit staat, krijgen we terug de volle snelheid van telenet voor uploads:
Alle http connecties naar de torrent tracker zijn verdwenen. Let goed wat de telenet shaper dan doet:
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 60405
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.8 sec 5.96 MBytes 4.62 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 60406
[ 5] 0.0-10.8 sec 5.96 MBytes 4.64 Mbits/sec
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 60407
[ 4] 0.0-11.1 sec 6.15 MBytes 4.64 Mbits/sec
Yep, de upload wordt plots terug de volle specificatie van mijn product.
![Afbeelding](http://img26.imageshack.us/img26/4420/iperftestzonderidletorr.png)
De upload spikes van dezelfde iperf test bewijzen dit. Ditmaal zonder idle torrent tracker verkeer.
Elke rode bult is zo'n traffic burst van iperf die 10 seconden duurt.
DUS TELENET VERTRAAGT ALLE ONGEKENDE PROTOCOLLEN ALS ZE P2P DETECTEREN
3) Leggen we nu opnieuw een torrent client aan, met idle traffic en enkel tracker communicatie
Dan begint de telenet shaper opnieuw te knijpen tot 1.40mbit
# iperf -s -p 80
------------------------------------------------------------
Server listening on TCP port 80
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 45536
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.2 sec 1.70 MBytes 1.40 Mbits/sec
[ 5] local 109.68.XXX.YYY port 80 connected with 81.82.AAA.BBB port 45537
[ 5] 0.0-10.2 sec 1.71 MBytes 1.41 Mbits/sec
![Afbeelding](http://img837.imageshack.us/img837/1214/iperftestmetidletorrent.png)
Als we na deze iperf test en onze idle torrent client nog steeds actief een speedtest draaien, dan krijgen we wel een totaal ander resultaat:
![Afbeelding](http://img833.imageshack.us/img833/9117/speedtestwordtnietgesha.png)
Speedtest, http en andere favoriete protocollen in de shaperdefinitie worden dus nooit geknepen, maar onze iperf test dus wel. Nochtans is iperf geen P2P verkeer en gewoon een onschuldige snelheidstest.
En om aan te tonen dat speedtest niet liegt nog maar even de router graphs:
![Afbeelding](http://img11.imageshack.us/img11/341/speedtestrouter.png)
Je kan mooi de volgorde van de speedtest zien: eerst download die over de 60 mbps gaat, en dan de upload.
Hoe werkt de telenet shaper
* protocollen die telenet graag ziet krijgen de full speed, dus ook de speedtest sites, ongeacht of je nu torrents hebt openstaan
* non-encrypted torrent krijgt een debiel lage speed, bvb 10 kbyte upstream
* onbekende protocollen krijgen ook full speed, tenzij torrent tracker communicatie wordt gespot
* in dat laatste geval krijgen onbekende protocollen ook een lagere snelheid, omdat telenet dan ervan uitgaat dat al wat niet gekend is, bittorrent moet zijn (encryptie)
* deze verlaagde snelheid is niet even debiel laag als non-encrypted torrent, omdat ze dan misschien te zwaar in voip of video knippen en er teveel klachten zouden komen
Dus:
- de telenet shaper is gebaseerd op deep packet inspection en/of correlatie
- hij correleert onbekende traffiek met tracker traffiek, de torrent traffic is immers rc4 encrypted
- als hij P2P tracker traffic ziet, policed hij alle onbekende traffic zwaar, ook de onschuldige iperf testjes
Ook IMAPS moet sneuvelen:
http://userbase.be/forum/viewtopic.php? ... 40#p385897
En dit kan volgens ons niet. Hier gaat telenet te ver. Ik heb hiermee bewezen dat Telenet een gebrekkig product levert.
Wie mijn verhaal begrijpt zal nu ook snappen hoe de telenet shaper helemaal te bypassen.