Userbase

Deze topic ging initieel over een modem probleem, en gezien dit een nieuw probleem heeft blootgelegd bij Telenet, lijkt het nuttig om hierover een afgesplitste topic aan te maken.

viewtopic.php?t=67585

We hebben de laatste week diverse traffic testcases opgezet, en concluderen het volgende:

1. van zodra er P2P traffic wordt gedetecteerd door Telenet, ongeacht de snelheid, en ongeacht of er effectieve up- of download is (e.g. enkel idle torrent protocol verkeer in de orde van enkele kilobytes/s - dus de snelheid van een jaren 90 inbelmodem, is al genoeg om de vertraging uit te lokken), dan begint Telenet zich te moeien met reguliere HTTPS connecties

- een deel van de HTTPS connecties start zeer traag, tot wel 8 a 11 seconden duurtijd terwijl dit normaal een fractie van een seconde duurt
- en zelfs bij een zeer lage lijnbelasting
- sommige HTTPS connecties worden zelfs gereset, waardoor bepaalde applicaties falen, bvb Tidal + Roon

Dit kan makkelijk getest worden door een curl command in repeat te draaien met een pauze van bvb 1 seconde. Dit commando is standaard in Linux, en in WIndows kan je dit makkelijk via WSL testen.

Code: Selecteer alles

while sleep 1; do curl https://site.be > /dev/null; done

Vervang de site door uw eigen site. Doe de test met en zonder een idle of low speed torrent. Je kan in vrijwel elke torrent client de up en down beperken, zodat de lijn niet stampvol zit, waardoor je onmogelijk hinder kan veroorzaken naar andere klanten.

2. als we de P2P traffic, die 100% legitiem kan zijn, doorheen een VPN tunnel trekken, en de rest van de traffic direct naar buiten laten gaan, dan stoppen de gemeten vertragingen en resets onmiddelijk. Telenet kan het torent verkeer niet meer detecteren. De shaper schiet dan niet in actie. Het ging dan nog om een 100% legitieme Linux ISO van 4 GB die aan 100 a 200 kbyte/s binnenkwam.

Telenet heeft niet het recht om voor mij te bepalen dat ik een Linux ISO niet mag downloaden via P2P ipv via een reguliere mirror, want van zodra ik dit nu doe, worden andere connecties op de lijn afgestraft, en breken zelfs bepaalde applicaties. Ook merk je bij bepaalde sites dat er een wachttijd is van ongeveer 8 seconden, en dan laadt de site plots instant.

Dit sooort traffic shaping is zeer agressief, en ik overweeg nu verdere stappen, indien telenet dit niet oplost. Deze problemen werden bij Telenet gerapporteerd via een formulier, maar Telenet antwoordt hier niet op. Nochthans is de shaping nu bewezen.

FredericV schreef: Dit sooort traffic shaping is zeer agressief, en ik overweeg nu verdere stappen, indien telenet dit niet oplost. Deze problemen werden bij Telenet gerapporteerd via een formulier, maar Telenet antwoordt hier niet op. Nochthans is de shaping nu bewezen.

Die stappen had je al vanaf dag 1 moeten ondernemen toen je klant werd. Je bent namelijk met Telenet overeengekomen dat ze "traffic shaping" kunnen toepassen: https://www2.telenet.be/residential/nl/klantenservice/internet/meer-over-je-internet/wat-is-telenet-netwerkbeheer/

Ter info: op het coaxkabelnetwerk deel je de bandbreedte, op een node er is 3000 à 4000 Mbps downstream bandbreedte beschikbaar voor gemiddeld meer dan 200 internetklanten. Er is 200 Mbps upstream bandbreedte beschikbaar. Telenet moet de upstream dus zwaar "shapen" zodat de veiligheidscamera's of videocalls van hun klanten niet zouden uitvallen.

Telenet gaat dit beleid niet uit zichzelf wijzigen, traffic shaping is de enige manier om op het huidige coaxkabelnetwerk kunstmatig hoge downloadsnelheden van 500 Mbps of 1000 Mbps te kunnen verkopen. Voor de upstream is traffic shaping gewoon een bittere noodzaak. Anders zou één klant door de upstream vol te trekken een hele node kunnen "platleggen".

Als je toch iets wil doen, neem je best onmiddellijk een advocaat onder de arm en argumenteer je juridisch waarom Telenet de Verordening (EU) 2015/2120 zou schenden.

Je kan die juridisch onderbouwde klacht dan (laten) indienen bij het BIPT: https://www.bipt.be/consumenten/telefoo ... utraliteit
Het BIPT zal je klacht dan onderzoeken en eventueel Telenet op de vingers tikken.

De gemakkelijkste oplossing voor je probleem is echter onmiddellijk overstappen op VDSL of glasvezel. Op deze vaste netwerken bestaat zulke "traffic shaping" niet: Beheer van het vaste en mobiele internetverkeer op het Proximus-netwerk

@raf1 akkoord indien we de lijn zouden satureren, maar dat doen we niet. Van mij mogen ze torrent vertragen of een lagere prio geven. Maar een idle torrent die de snelheid van een inbelmodem op het netwerk zet, maakt dat HTTPS connecties extreem vertraagd of zelfs gereset worden. Op geen enkele manier veroorzaken we traffic die andere klanten sterk zouden benadelen.

Dit is geen EERLIJKE verdeling van de vrije bandbreedte:

Verdeling bandbreedte
Eerlijke verdeling van vrije bandbreedte.

We verdelen de vrije bandbreedte op ons netwerk zo eerlijk mogelijk over alle gebruikers. Zo profiteren onze klanten van supersnel internet. Op extra drukke momenten beperken we de maximale snelheid van bepaald dataverkeer (bv. downloads, FTP,...) op plaatsen waar ons netwerk dreigt verzadigd te raken. Zo zorgen we ervoor dat onze klanten altijd vlot kunnen blijven streamen, browsen, gamen,...

Er is conceptueel nog een sterk verschil tussen het beperken van de maximale snelheid, en het resetten (saboteren) van nieuwe HTTPS connecties.

Telenet doet helaas ook dat laatste.

Ik kan alleen maar herhalen dat Telenet dit beleid niet uit zichzelf zal wijzigen omdat een technisch onderlegde klant dat toevallig "ontdekt" heeft. Het is al decennialang bekend dat Telenet aan traffic shaping doet op coaxkabel en het zal alleen maar verergeren naarmate Telenet snellere DOCSIS-abonnementen lanceert.

De extreme overboeking van bandbreedte op coaxkabel en de bijhorende zware "traffic shaping" om deze business in stand te houden is behoorlijk schandalig. Maar dat is nu precies het businessmodel van Telenet: onwetende klanten lokken met hoge downloadsnelheden die totaal "fake" blijken te zijn als je die download of upload eens langer dan een half uurtje volledig dichttrekt tijdens de piekuren.

Ofwel trek je juridisch ten strijde en zal Telenet na een eventuele zware boete wegens schending "netneutraliteit" in de toekomst wat meer nodes opsplitsen om de overboeking te verminderen, ofwel verlaat je de coaxkabel.

Au fond heb je als individuele klant niet echt macht om Telenet te dwingen om hun traffic shaper aan te passen.

Op de site van het BIPT lees ik

NB jouw operator mag redelijke maatregelen van verkeersbeheer toepassen (wat onder kan bestaan in een vertraging van het verkeer), maar enkel als deze noodzakelijk zijn voor de vlotte werking van het netwerk, en als ze transparant en niet-discriminerend zijn.

Het gaat nog steeds om vertragen van verkeer, niet het volledig resetten van verkeer.

https://www.bipt.be/consumenten/telefoo ... utraliteit

Het resetten van verkeer lijkt op een vorm van interferentie:

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

https://www.bipt.be/file/cc73d96153bbd5 ... 025-nl.pdf

Het discriminerend aspect is ook van toepassing, gezien bij gebruik van P2P andere protocollen worden afgestraft, zelfs als de lijn amper wordt gebruikt.

Het is zeer goed mogelijk dat Telenet de wettelijke bepalingen rond netneutraliteit schendt.
Klacht indienen of Telenet vaarwel zeggen zijn je enige opties.

Ben begonnen met een eerste kennisgeving, via het support formulier, met uitleg in de pdf en wat ze precies schenden.

Gelieve kennis te nemen van de brief in bijlage, waarin ik Telenet formeel verzoek om de regels rond net neutraliteit te respecteren, en HTTPS niet langer nadeling te beïnvloeden, en dus geen interferentie te veroorzaken.

Mijn ervaring met bemiddeling- en klachtenprocedures, is de partij eerst te laten kennis nemen.

FredericV schreef: 1 week geleden
1. van zodra er P2P traffic wordt gedetecteerd door Telenet, ongeacht de snelheid, en ongeacht of er effectieve up- of download is (e.g. enkel idle torrent protocol verkeer in de orde van enkele kilobytes/s - dus de snelheid van een jaren 90 inbelmodem, is al genoeg om de vertraging uit te lokken), dan begint Telenet zich te moeien met reguliere HTTPS connecties

- een deel van de HTTPS connecties start zeer traag, tot wel 8 a 11 seconden duurtijd terwijl dit normaal een fractie van een seconde duurt
- en zelfs bij een zeer lage lijnbelasting
- sommige HTTPS connecties worden zelfs gereset, waardoor bepaalde applicaties falen, bvb Tidal + Roon

Traffic shaping (Telenet netwerkbeheer) gebeurt niet op basis van een actuele meting van de lijnbelasting, maar is een preventieve maatregel.
Voor zover ik het gebrijp, gebeurt het als volgt:

Telenet heeft een continu bewaking van de lijncapaciteit en traffic op iedere node.
Van zodra een node dreigt verzadigd te geraken wordt de shaper geactiveerd op deze node.
Dit houdt in dat gedurende drukke momenten, bepaalde traffiek (oa P2P) geknepen wordt.
Dit zolang de shaper actief is, en ongeacht het verkeer op dat moment.
Zonodig zal Telenet die meest verzadigde nodes proberen te ontlasten (vb uitbreiding van het downloadfrequentiebereik naar 1GHz, ontdubbelen van de node, etc ...)
Van zodra de "dreiging" tot oververzadiging wegvalt, zal de shaper gestopt worden, de traffiek wordt verder gemonitored.
Indien nodig zal de shaper opnieuw geactiveerd worden.

Kort samengevat:

traffic shaping wordt toegepast op individuele nodes.
traffix shaping wordt alleen toegepast op bepaalde drukke tijdstippen (dit valt niet noodzakelijk samen met de piek- en daluren van de FUP).
traffix shaping houdt geen rekening met de belasting op dat moment, maar is preventief.

Blijkbaar heb jij pech, gezien de shaper op jouw node geactiveerd is?

Kan je bevestigen dat dit alleen op bepaalde tijdstippen gebeurt? Of zie je dat fenomeen 24/24u?

Zoals @raf1 ook schreef: hoe meer gigabit abonnementen Telenet verkoopt, en dus hoe meer overbooking op de beperkte up- en downloadcapaciteit van de coax, hoe meer nodes "dreigen" oververzadigd te worden ...

@philippe_d Ik heb momenteel een scheduler draaien in Deluge, die alles op pauze zet tussen 10:00 en 24:00, om geen last te hebben van de shaper tot ze het probleem oplossen. Maar als ik deze even uitzet heb ik direct prijs (nu om 19u):

curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to userbase.be:443

Ik zal op andere tijdstippen testen, misschien maak ik een cronjob die de docker aanzet en dan een paar curl metingen, en dan alles weer uit. Dan weten we exact op welk uur de Telenet shaper toeslaat. Ik ga ook nog eens tcpdumpen om te kijken wat ze precies uitspoken. Naar m'n eigen site krijg ik geen connection reset, maar duurt een HTTPS connectie ellendig lang om een simpele GET / te doen (tot wel 11s).

Bij userbase en de roon api krijg ik dan die reset.

Met de Deluge scheduler aan en dus torrents uit, mag ik de hele werkdag de duurtijd van een https request naar m'n site meten, en zie gewoon nooit een vertraging.

19u: curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to userbase.be:443 (getest met userbase)

21u: tot wel 8s vertraging op HTTPS als torrent even actief wordt gezet (met eigen site)
na 4s: curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to userbase.be:443

Toegevoegd na 2 uren 50 minuten 18 seconden:
21u55u - van zodra we de torrents enablen door de schedule op groen te zetten, en noch download noch upload maar enkel protocol verkeer, dan knalt HTTPS er vrijwel direct uit.

Telenet is hier duidelijk in gebreke en schendt de net neutraliteit.

Toegevoegd na 55 minuten 1 seconde:
~ 22u50: we doen nu de curl test op 2 linux machines, links direct via het WAN IP van mijn Mikrotik, rechts zelfde test, via onze VPN, waarbij ik de default gw door de VPN trek. Rechts is de machine met Roon, waarmee dit onderzoek begon, omdat we daar in de logs SSL errors zagen en telkens uit Tidal werden gegooid.

P2P staat nu aan, en protocol traffic minder dan 64 kbit.

Zoals je kan zien, prutst Telenet niet met het verkeer wat door de VPN gaat, als P2P actief is.

We gaan nu kijken of Tidal + Roon doorheen de VPN blijft spelen. Net voor het opzetten van de VPN op de Roon machine, zagen we de SSL errors terugkomen in de logs:

Code: Selecteer alles

10/16 22:39:46 Warn: [easyhttp] [449] GET https://api.roonlabs.net/push-manager/1/connect web exception without response: socketmsg (ConnectionReset):  The SSL connection could not be established, see inner exception. The SSL connection could not be established, see inner exception.

Sinds Roon machine door de VPN connect ipv direct zien we geen SSL errors meer in de log, en nog geen Tidal logouts.

Toegevoegd na 9 uren 18 minuten 12 seconden:
08u05: ~ 64 kbit P2P protocol verkeer

directe https: curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to userbase.be:443
via VPN: geen vertraging, geen connection reset

Telenet schendt de net neutraliteit rond 8u 's ochtends.

Hoedje af met de info die je hier aanlevert.
Benieuwd hoe dit verder gaat geraken dan hun 1st line.

Hou ons hier zeker op de hoogte!

9u voormiddag, even kort torrents aan, en hup weer prijs. Zoals je kan zien in de interface stats van de WAN, is deze traffic niet iets wat de lijn volstampt.

Toegevoegd na 5 minuten 40 seconden:

Hier nog een bijkomende speedtest, na de torrent test, en P2P blijft actief.

P2P (groen) vs P2P + speedtest (rood)

De P2P test stelt dus niks voor tov de P2P + speedtest, waar net geen 50 mbps upstream wordt gehaald.

Als TN al bij de groene belasting met HTTPS traffic klooit, dan schenden ze de net neutraliteit. Op geen enkele manier wordt de lijn zo belast dat andere klanten tijdens het groene window hier last van gaan hebben.

Dit lijkt inderdaad niet op traffic shaping zoals Phillipe het over had

Oud nieuws: https://tweakers.net/nieuws/75196/telen ... rkeer.html

De tech pers werd nu ook geïnformeerd, gezien uitblijven reactie van Telenet.

Hoe lang heb je ze tijd gegeven? Want volgens je vorige post is dat zelfs nog geen dag.

@devilkin heb dit al op 10 oktober gemeld via email. Bevestiging gehad:

"Vandaag werd de TV filter vervangen, en eerder deze week de modem. Helaas worden onze SSL verbindingen nog steeds gereset, en zien we sporadisch zeer hoge latency tot wel 8 seconden om een SSL verbinding op te zetten. In bijlage de technische update met metingen, van het probleem dat zich nog steeds stelt. We kunnen dus geen deluge draaien zonder impact naar andere applicaties, terwijl de traffic de lijn nooit verzadigt. Zie PDF achteraan voor de update & testing vandaag."

Geen reactie. Maandag de 13e helpdesk gebeld, geraak niet verder dan first line, die mij sust dat ze mij gaan contacteren. Maar dat doen ze niet.

Toegevoegd na 22 minuten 18 seconden:
Ze hebben net gebeld. De first line kan dit niet oplossen. Ze kunnen mijn probleem niet zelf doorsturen naar hun meditation dienst.

Dus ik moet de PDF opnieuw submitten via deze link, dus naar de dienst die klachten behandelt:

https://www2.telenet.be/residential/nl/ ... aints.html

raf1 schreef: 1 week geleden Klacht indienen of Telenet vaarwel zeggen zijn je enige opties.

Maak daar maar een 'en' van.

hier ooit eens met mobiel veel data verbruikt in één weekend (170GB, op een 300GB abo), plots merkte ik dat ik nergens meer data kon gebruiken, Gent? Niets, niet eens ICMP ging erdoor.

Waar ik woon (de data werd aan de andere kant van BE verbruikt, op 5G, vooral s'avonds), had ik 7Mbps op Telenet met vrij zicht, 36Mbps met een USA roaming SIM (die ik nodig had aangezien ik geen sites kon openen in Gent...).

De roaming SIM zat ook op het Telenet netwerk en de verklaring waarom Telenet trager is dan de USA roaming SIM was: verkeer legt een andere weg af (naar USA en terug: 200ms latency), wat het sneller maakt. Logica is ver te zoeken, maar de ombudsman telecom ging hier in mee.

Dus... spaar jezelf de moeite en stap over, die klachten doen toch niets in mijn ervaring...

We zijn nu net na middernacht. P2P staat terug aan door de scheduler. We zien protocol verkeer in de orde van een ouderwetse 64 kbit ISDN lijn, en er is maar één open connectie. Er zijn geen actieve P2P down- of uploads. Op deze manier gaat een connection table nooit vollopen:

: tele-sabotage.png (3.67 KiB) 1323 keer bekeken

En hup, Telenet knipt weer in HTTPS ...

curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to userbase.be:443

Terwijl ze HTTPS resetten, is er volgens de fast speedtest niks aan de hand (P2P staat nog steeds aan tijdens de fast test):

Dus ja, voor mij is dit bedrog.

Ik heb Chrome's debug mode aangezet op fast.com, om te kijken naar welke URL deze gaat, voor het fetchen van de speedtest file.

Ik heb dan een curl laten lopen naar userbase (telenet vertraagt/reset) en tegelijkertijd naar een netflix cdn machine (niks wordt vertraagd).

Hier is duidelijk sprake van discriminatie:

Volgens het BIPT:

The right to equal treatment of Internet traffic
Internet service providers shall treat internet traffic equally and without discrimination, and irrespective of the sender and receiver, the content accessed or distributed, the applications or services used or provided, or the terminal equipment used.

This means that your operator may not, for instance, slow down the traffic for certain applications or websites.

https://www.bipt.be/consumers/telephone ... neutrality

Maar voor zover ik het versta, vertragen ze niet je traffiek "for certain applications or websites", maar vertragen ze *al* je verkeer.
Volgens mij ontlopen ze zo het neutraliteitsprobleem.

Dien toch onmiddellijk klacht in bij het BIPT, dit is de bevoegde instantie om klachten over netneutraliteit te behandelen. Telenet zal uit zichzelf hun beleid niet aanpassen, extreme overboeking van bandbreedte met zware traffic shaping is hun businessmodel op coaxkabel.

Het BIPT moet je klacht dan onderzoeken en baseert zich daarvoor op de BEREC Guidelines on the Implementation of the Open Internet Regulation
In dat document staat duidelijk aan welke voorwaarden "traffic management" moet voldoen.

Maar gezien het "track record" van Telenet raad ik aan om de coaxkabel vaarwel te zeggen. Providers die er de "kantjes van aflopen" moet je niet blijven financieren. Kies een provider die de netneutraliteit respecteert!

ITnetadmin schreef: 6 dagen geleden Maar voor zover ik het versta, vertragen ze niet je traffiek "for certain applications or websites", maar vertragen ze *al* je verkeer.
Volgens mij ontlopen ze zo het neutraliteitsprobleem.

Van zodra er idle P2P verkeer is (protocol verkeer, geen up- of downloads), waarbij protocol verkeer niet meer is dan een ouderwetse 64 kpbs ISDN lijn:

1. fast.com en speedtest sites gaan aan full speed, geen enkele https delay of connection reset
2. andere sites zoals de roon api, userbase en mijn eigen site: vertraging tot wel 8 a 11s, en connection resets, ook via https
3. applicaties die droppen omdat ze hier niet mee om kunnen, bvb Roon + Tidal

P2P verkeer door een VPN en probleem 2 en 3 doen zich niet voor
P2P verkeer direct via TN en applicaties die last hebben van 2 + 3 door een VPN: geen probleem meer

Ondanks de technisch onderbouwde informatie correct lijkt, kan ik dit absoluut niet reproduceren en heb ik dit ook nog nooit voorgehad in alle jaren (20+) dat ik Telenet klant ben.

Ik had dit vroeger wél voor met goedkope firewalls ... P2P verkeer verzadigde de firewall waardoor er (bijna) geen nieuwe connecties opgezet konden worden met zelfde resultaat. Nergens in jouw informatie zie ik daar iets over ?
- Hoeveel connecties laat je toe in jouw torrent client ?
- Welke firewall/router gebruik je ?
- Doet jouw firewall iets van inspectie ?
...

Ter info, ik heb nu thuis een Business Fibernet abbo, dus ik ben geen goed voorbeeld (meer), maar ook voor ik business klant was had ik dat niet. Ik heb dat ooit voorgehad toen ik een Watchguard T30-W thuis had gezet, en die was ondermaats voor de lijnperformatie én kon absoluut niet goed overweg met P2P traffiek, waardoor ik het aantal connecties moest dichtschroeven om nog te kunnen surfen tijdens een P2P download.

Misschien een piste ?

@Sasuke

Het heeft met de firewall wellicht niks te maken (de iptables firewall op een Mikrotik RB1100ah2), gezien het aantal connecties dat deze aan kan, veel hoger is dan wat er in de state table staat. Als dit zou vollopen dan staat dit in de logs. Verder is de test ook reproduceerbaar met de Deluge doos direct op de Telenet modem.

En het maakt niet uit hoeveel connecties, die in Deluge default op 200 staat: deze omlaag trekken naar 50, of zelfs in de praktijk 1 vd 50 connecties actief: van zodra TN dit detecteert, klooien ze met mijn HTTPS.

Vreemd ... zoals ik al zei, ik heb dit nooit zelf meegemaakt. Vandaag ook eens getest bij mijn ouders met een standaard TN 200Mbit abbo en even uTorrent op de laptop, geen issues gemerkt (en die wonen in een mega grote appartementsblok).

@FredericV, staat "Safesurf" aan op je modem?
Je kan eventueel eens testen door dit uit te schakelen en opnieuw te testen.

Ah ja, Safespot+ kan ook de boosdoener zijn. Die software die op je Telenet-modem draait doet ook aan Deep Packet Inspection.

De traffic shaping gebeurt trouwens tijdelijk bij dreigende verzadiging van een node. Het verbruik of de belasting van je eigen abonnement heeft er niets mee te maken.

Als je al 20 jaar op een node zit tussen mémé's en pépé's in Zuienkerke die gewoon wat surfen zal je er nooit last van hebben.

DPI... ook in bridge mode?

Ik vraag me af, hoe doen ze die P2P detection, is dat het aantal burst packets, soort packets, of gewoon de TCP portnumber?
Kan je op je webserver eens diezelfde port openzetten en daar wat connecties naar doen en zien of het triggered?
Of een custom port instellen op de torrentclient en kijken of het dan beter is?

Als het allemaal niet helpt kan je je gewoon van de domme spelen en technieker laten komen, torrentje opzetten en die dan maar met zn eigen laptop rechtstreeks op een modem ethernet poort naar een website laten proberen surfen, zien ze het met eigen ogen en kijken hoe ze dat gaan oplossen (hopelijk niet jouw router uittrekken en zeggen dat het daar aan ligt

) ?

Hoe werkt Safespot+ dan? Hoe kan dat "beschermen" in HTTPS sessies (dat kan die modem toch nooit inzien/inspecteren) zonder decryption/resigning? Via fingerprinting (en er dan een soort van AI algoritme op los te laten om het verkeer toch beperkt te kunnen identificeren?) Of hoe moet ik dat zien?

Ik vraag met ook af hoe ze het detecteren. Want in Deluge is alle traffic encrypted.

Wellicht kijken ze gewoon naar het aantal connecties. Doorheen een VPN kunnen ze die niet tellen, want in geval van openvpn zien ze maar één TCP connectie, dus één lijntje in een netstat.

Ik heb in de docker een one liner lopen, die het aantal connecties telt. Deze loopt op van bvb 7 in idle naar enkel honderden, als we de torrents uit de pauze halen:

Code: Selecteer alles

Sat Oct 18 21:30:05 UTC 2025 7
Sat Oct 18 21:30:06 UTC 2025 7
Sat Oct 18 21:30:07 UTC 2025 7
Sat Oct 18 21:30:08 UTC 2025 7
Sat Oct 18 21:30:09 UTC 2025 8
Sat Oct 18 21:30:10 UTC 2025 8
Sat Oct 18 21:30:11 UTC 2025 8
Sat Oct 18 21:30:12 UTC 2025 8
Sat Oct 18 21:30:13 UTC 2025 8
Sat Oct 18 21:30:14 UTC 2025 8
Sat Oct 18 21:30:15 UTC 2025 8
Sat Oct 18 21:30:16 UTC 2025 8
Sat Oct 18 21:30:17 UTC 2025 8
Sat Oct 18 21:30:18 UTC 2025 8
Sat Oct 18 21:30:19 UTC 2025 8
Sat Oct 18 21:30:20 UTC 2025 8
Sat Oct 18 21:30:21 UTC 2025 70
Sat Oct 18 21:30:22 UTC 2025 167
Sat Oct 18 21:30:23 UTC 2025 166
Sat Oct 18 21:30:24 UTC 2025 166
Sat Oct 18 21:30:25 UTC 2025 164
Sat Oct 18 21:30:26 UTC 2025 168
Sat Oct 18 21:30:27 UTC 2025 202
Sat Oct 18 21:30:28 UTC 2025 202
Sat Oct 18 21:30:29 UTC 2025 201
Sat Oct 18 21:30:30 UTC 2025 201
Sat Oct 18 21:30:31 UTC 2025 201
Sat Oct 18 21:30:32 UTC 2025 228
Sat Oct 18 21:30:33 UTC 2025 226
Sat Oct 18 21:30:34 UTC 2025 239
Sat Oct 18 21:30:35 UTC 2025 236
Sat Oct 18 21:30:36 UTC 2025 236
Sat Oct 18 21:30:37 UTC 2025 163
Sat Oct 18 21:30:38 UTC 2025 171
Sat Oct 18 21:30:39 UTC 2025 186
Sat Oct 18 21:30:40 UTC 2025 196
Sat Oct 18 21:30:41 UTC 2025 211
Sat Oct 18 21:30:42 UTC 2025 202
Sat Oct 18 21:30:43 UTC 2025 209
Sat Oct 18 21:30:44 UTC 2025 219
Sat Oct 18 21:30:45 UTC 2025 232
Sat Oct 18 21:30:46 UTC 2025 234
Sat Oct 18 21:30:47 UTC 2025 219
Sat Oct 18 21:30:48 UTC 2025 226
Sat Oct 18 21:30:49 UTC 2025 229
Sat Oct 18 21:30:50 UTC 2025 234
Sat Oct 18 21:30:51 UTC 2025 300
Sat Oct 18 21:30:52 UTC 2025 294
Sat Oct 18 21:30:53 UTC 2025 302
Sat Oct 18 21:30:54 UTC 2025 339
Sat Oct 18 21:30:55 UTC 2025 338
Sat Oct 18 21:30:56 UTC 2025 319
Sat Oct 18 21:30:57 UTC 2025 317
Sat Oct 18 21:30:58 UTC 2025 324
Sat Oct 18 21:30:59 UTC 2025 314
Sat Oct 18 21:31:00 UTC 2025 304
Sat Oct 18 21:31:01 UTC 2025 303
Sat Oct 18 21:31:02 UTC 2025 296
Sat Oct 18 21:31:03 UTC 2025 301
Sat Oct 18 21:31:04 UTC 2025 311

En dit op een paar seconden. Zulk patroon is wel detecteerbaar door een shaper.
Gezien de docker in UTC staat, moet je 2u bij de timestamps doen.

Het kan zijn dat ze rate limiting op nieuwe connecties toepassen bij overschrijden van bepaalde drempels of bepaalde delta's, en daardoor nieuwe TCP connecties zoals mijn curl test, dan hard omvallen, of extreem vertragen. Echter dit groot aantal connecties veroorzaakt geen echte load op de lijn, gezien het om protocol verkeer gaat, en snelheden die doen denken aan ouderwetse inbelmodems en ISDN.

Toegevoegd na 18 minuten :

raf1 schreef: 6 dagen geleden Ah ja, Safespot+ kan ook de boosdoener zijn. Die software die op je Telenet-modem draait doet ook aan Deep Packet Inspection.

Blijkbaar staat firewall bescherming aan.

Wat betreft de traffic shaper, dat is een preventieve maatregel bij dreigende verzadiging van een node.
Stel een node heeft een maximumcapaciteit van 3000 Mbps downstream bandbreedte, er is de laatste 14 dagen dagelijks 2000 Mbps verzadigd gedurende 4 uren per dag ('s avonds als iedereen video streamt). Er blijft tijdens die 4 uren maar 1000 Mbps over waardoor de specificaties van één individuele gebruiker in gevaar komen. Als het verkeer nog zou toenemen, kan een 1 Gbps-abonnement onmogelijk nog de maximumsnelheid halen.

Misschien wordt dan de traffic shaper geactiveerd voor de volgende 14 dagen en volgt daarna een nieuwe evaluatie van het niveau van verzadiging van de node.
Je mag echt niet denken dat Telenet een geavanceerd realtime systeem heeft dat meerdere keren per dag inschakelt of uitschakelt per node en dat voor meer dan 7000 nodes op hun netwerk. Het is een systeem dat bedacht is om de nodes te beschermen voor alle klanten. Dus eigenlijk voor die 99% gebruikers die nooit zouden doorhebben dat traffic shaping überhaupt bestaat. Zolang speedtest.net maar prioriteit krijgt en niet geshapet wordt, is er voor die 99% niets aan de hand.

Als je klacht indient bij het BIPT, vergeet dan zeker niet na te vragen dat Telenet hierover 100% transparantie biedt en tot in het kleinste detail bekendmaakt hoe de traffic shaper precies werkt. De juridische basis om volledige transparantie te eisen lees je in artikel 4 op https://eur-lex.europa.eu/legal-content ... 0-20240515

Wat betreft bridge mode en Safespot+. Echte bridge mode bestaat niet bij Telenet (tenzij je een eigen DOCSIS-modem gebruikt), Telenet biedt MAC passthrough, daarbij blijft de routerfunctie actief en die ziet het IP-verkeer nog steeds en kan dus aan DPI blijven doen.

Als je de kleine lettertjes van Telenet niet leest, zou ik toch ten zeerste afraden om daar klant te worden.
Want je verklaart je eigenlijk akkoord dat Telenet je dataverkeer bespioneert:
https://www2.telenet.be/residential/nl/ ... espot.html
https://www2.telenet.be/residential/nl/ ... espot.html

De netwerkbeveiliging wordt verzorgd door de softwareagent die op uw Telenet-modem is geïnstalleerd om uw volledige thuisnetwerk te beschermen. Om precies te zijn, wordt deze geïnstalleerd op de router die deel uitmaakt van uw modem. Deze geavanceerde software scant het internetverkeer van en naar de apparaten die met uw modem zijn verbonden en toegang hebben tot internet (zoals computers, smartphones, smartwatches, slimme thermostaten en babyfoons).

De leverancier van Safespot+ is een Israëlisch softwarebedrijf: https://securingsam.com/sam-seamless-ne ... bscribers/

Die software doet natuurlijk veel meer dan "beveiliging": https://securingsam.com/intelligence/

Sinds gisteren, heb ik een nieuwe Roon node draaien?
Wel bizar Tidal knalt er niet uit terwijl P2P aan staat.

Ik zie de curl test soms eens vertragen naar 1s, en gisteren zelfs éénmalig tot 11s (dit was naar userbase), maar ik zie geen SSL resets meer! Meestal na 4s vloog de curl er al uit. Nu na ruim 10s nog niet.

Dus het vertraagt, maar reset niet meer.

Zal de 5u Tidal playlist in repeat zetten vandaag, en zien of we vandaag ergens een SSL reset in de logs tegenkomen.

FredericV schreef: 5 dagen geleden Blijkbaar staat firewall bescherming aan.

Die opties ivm SafeSurf of SafeSpot+ (bvb bij OneUp) kan je uitschakelen bij "mijn producten".
Vermoedelijk wordt bij een HTTPS request enkel het IP, TLS metadata en de domeinnaam gecontroleerd, andere zaken zijn niet leesbaar voor tussenliggende devices.

In dit verband: Is het dan niet beter om Safespot uit te zetten (als je je eigen router gebruikt) en/of andere DNS servers (dan die van Telenet) te gebruiken?

Safespot+ betekent extra belasting van de processor van de Telenet-modem en het inspecteren van packets voegt extra latency toe.

Als je honderden connecties naar het internet wil testen, zou die routerfunctionaliteit met Safespot+ DPI in de Telenet-modem ook wel eens de bottleneck kunnen zijn. Je kan de CPU-belasting van de Telenet-modem niet checken, je kan niet nagaan of er bugs in de firmware zitten die eventueel IP packets om zeep helpen.
De Telenet-routerfunctie blijft ook altijd actief als je begrijpt hoe MAC passthrough werkt. Mogelijks kan Safespot+ ook nog de packets analyseren die via de MAC passthrough doorkomen. Je hebt geen zicht hoe de firmware van Telenet-apparatuur en de software-agent van SAM Seamless Network in elkaar zitten.

Een eigen (transparante) DOCSIS-modem is eigenlijk een must als je betrouwbare conclusies wil trekken over schending netneutraliteit door middel van DPI-technieken op een DOCSIS-netwerk.

Dus toch Safespot+ uitzetten? En wat met de DNS servers (die van Telenet of liever andere)?
Huidige opstelling: Telenet CV8560E -> MAC passtrough -> eigen router -> heeft instelbare DNS.

Veranderen, naar bvb Quad9 - https://quad9.net/

Google DNS, Cloudflare of OpenDNS zou ik links laten liggen.

Aangepast...bedankt!

Emile51 schreef: 5 dagen geleden Dus toch Safespot+ uitzetten? En wat met de DNS servers (die van Telenet of liever andere)?
Huidige opstelling: Telenet CV8560E -> MAC passtrough -> eigen router -> heeft instelbare DNS.

Safesurf stond bij mij uit.

Maar firewall bescherming in mijn telenet voor IPv4 stond hier voordien aan!

Ik heb een sterk vermoeden dat de IPv4 firewall bescherming in mijn telenet, de boosdoener is. Draai nu sinds de nacht van zaterdag op zondag zonder, en heb een grote Tidal playlist kunnen spelen zonder SSL fouten in de logs van Roon. Ook mijn curl testje toont sporadisch nog een delay van 1s, maar geen resets meer.

Vandaag lag Tidal er uit door dat Amazon probleem, dus niet meer kunnen verder testen.

Maar het lijkt er dus op dat de aangesloten Mikrotik in bridging mode (die dus een public IPv4 krijgt) onderhevig is aan firewalling als die optie aan staat in mijn telenet, dus bridging mode op de modem is geen pure layer2.

De firewall in de Mikrotik is geen bottleneck, maar die in de modem .... : toen ik zonet de firewall functie in mijn telenet terug inschakelde, en modem reboot, waren de SSL fouten er terug icm idle P2P protocol verkeer (minder dan 64 kbps aan dit soort verkeer).

Het lijkt er dus op dat de Telenet modem het aantal connecties die deze wil tracken, niet aan kan bij P2P, zelfs bij idle P2P. Als je dit idle verkeer door een VPN jaagt, dan hoeft er maar 1 connectie getracked te worden, gezien alles door één TCP connectie getunneld wordt. Die één extra connectie gaat het verschil niet maken, als de modem ook nog eens filtering moet doen.

Eigenlijk pleit dit voor een eigen modem, waar je in de modem kan zien wat er gebeurt. Nu heb je een zeer beperkte view via mijn telenet, en het is een 100% black box, waar je niks kan zien, of er bvb ergens in de logs staat dat er iets volloopt (zoals een connection tracking table). Immers het aantal connecties die idle P2P opzet, loopt maar in de honderden, en als de TN modem hier al last van ondervindt, zegt dit genoeg over de hardware (of duidt een fout).

Als je naar de first line helpdesk belt, zijn ze clueless, en iemand die meer kennis heeft, kan je niet spreken.

FredericV schreef: 4 dagen geleden Eigenlijk pleit dit voor een eigen modem, waar je in de modem kan zien wat er gebeurt

Het alternetief zou een echte bridge kunnen zijn (i.p.v. een IPv4 MAC passtrough)?
Zoals bij Orange (Siligence modem).
Of een modem-only?

Ik had vroeger een echte modem-only met maar één LAN poort, en 2 PSTN telefonie poorten.

Maar bij de aanbieding om over te stappen naar een KLIK bundel en Speedboost 1G Business (free for life), haalde ik niet de volle download snelheid met de oude modem, en zo is er dan de CV8560E gekomen.

Userbase

Telenet traffic shaping in 2025 vs net neutrality

Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality

Re: Telenet traffic shaping in 2025 vs net neutrality