Userbase

Ik ben al een tijdje aan het zoeken op een Roon probleem, die random SSL connecties reset volgens de Roon log. Je knalt dan in het midden van een track uit Tidal, of de cover art laadt niet meer.

Aan mijn CV8560E hangt een Mikrotik RB1100AH (x2) in bridging, en deze heeft meerdere VLANS met elk hun eigen firewall rules.

De set met Roon zit in een VLAN wat mijn normaal thuisnetwerk is.

In een aparte VLAN zit een machine die graag veel connecties kort open gooit, zonder daarbij echt traffic te doen.

Het aantal connecties schommelt tussen de 500 en 2000+ en in de netfilter conntrack staan deze op TIME_WAIT, dus voornamelijk idle connecties die geen bandbreedte gebruiken.

Met een netstat zie je dat het aantal werkelijke connecties minder dan 10 is!

Helaas blijven de idle nog af te sluiten connecties ook zichtbaar in de Mikrotik:
Maar het totaal is dus een peulschil tov de max entries, en deze idle connecties veroorzaken amper upload.

In de Mikrotik GUI zie je het totaal soms heftig schommelen tussen minder dan duizend en enkele duizenden connecties in een paar seconden.

Dus ik vermoed dat we op een andere plaats tegen een of andere limiet aanlopen. De CV8560E staat in bridging.

Is de bridging een echte layer 2 bridging, of doet deze nog veel meer dan dat?

Toegevoegd na 2 uren 49 minuten 31 seconden:
Ik heb een sterk vermoeden dat Telenet ergens throttling toepast:

1. Roon hangt nu aan z'n eigen Mikrotik L009 series router, met niks anders buiten een phone met wifi om Roon te bedienen. Deze setup is met dubbele NAT helaas - maar alles werkt.

2. De rest van het netwerk hangt aan de RB1100AH, en de doos die veel connecties open gooit daarvan staat de docker applicatie die dit doet uit - alles werkt.

Het gaat dus om 2 gescheiden netwerken met elk een eigen WAN IP.

Van zodra we de docker applicatie aanleggen, die via de RB1100AH aan de modem in bridge hangt , knalt Roon's Tidal er vrijwel direct uit, die aan de L009 hangt.

De conntrack van deze routers horen op geen enkele invloed te hebben op mekaar. Er moet dus ergens door Telenet een cumulatieve policy zijn overheen het totaal van één modem, die beperkt hoeveel connecties een modem mag opbouwen, ongeacht wat aan de modem hangt in bridge staat, of NAT doorheen de modem. Of een andere technische beperking in de CV8560E.

Traffic metingen gedaan en er wordt maar een fractie van de modem snelheid benut, dus dat kan het ook niet zijn.

Ga nu verder testen met de docker volledig uit, en kijken of het Tidal probleem nog triggert. Het is wel al veel minder dan gebruikelijk.

Het is net 2011 ...

viewtopic.php?p=385734

Heb je de modem al eens herstart?

Modem restarted.

Ter info het piekje wat de docker applicatie even kort trekt, is in de orde van 6500 packets/s via de RB1100AH . En hup, enkele minuten nadien faalt Tidal op Roon weer op de andere router die samen de modem deelt, ondanks de reboot.
Morgen eens bellen met Telenet, dat we vermoeden dat er iets fout is met de modem. Dit soort load zou de connectie niet labiel mogen maken, en al zeker niet het resetten van HTTPS / SSL connecties.

A 50 Mbps upstream connection has a theoretical maximum of roughly 33,300 packets per second, assuming a 1200-byte (including Ethernet headers) packet size, but the actual maximum number will be lower due to variable packet sizes and network overhead. Network performance metrics, such as packets per second (pps), are more reliable for comparisons when using consistent packet sizes.

Het zit er immers ver ver onder ...

Toegevoegd na 10 uren 15 minuten 23 seconden:
Zonder de Docker applicatie actief, heeft Roon een hele nacht een Tidal playlist van 8 uur afgespeeld. Toen ik deze ochtend naar Roon keek, was Tidal nog steeds niet uitgelogd. Het is dus duidelijk dat de modem of iets bij Telenet niet omkan met de transient spikes in packets per second, die de Docker applicatie kortstondig genereert.

Welke docker app is dat of kan je zeggen hoe je dit simuleert dan kan ik dit bij Orange 1000/50 ook eens testen?
Ik heb namelijk ook steeds veel connecties (vooral UDP) lopen en de conntrack count op mijn linux router is momenteel 3807 zonder problemen.

Nieuwe modem gaan halen, montage was easy. Terug een witte CV8560E.

Docker app terug gestart, kort piekje van 5.7 mbit up en bijna 5000 pps piek, nu weer idle:

Benieuwd of Tidal er weer uit gaat knallen. En ja helaas - Tidal is er uitgeknald ondanks de modem swap.


Het lijkt er dus op dat Telenet netwerkbeheer hier voor iets tussen zit, of een bug die meerdere modems treft, of een hardware beperking.

We weten natuurlijk niet welke rate limiting / packet shaping of andere connection tracking beperking actief is in een modem die in bridge staat.

Ik heb met regelmaat zeer veel UDP connecties openstaan en heb dit nog nooit voorgehad met de cv8560e.
Kan je eens iets meer details verstrekken dan "docker app"?

T zou inderdaad handig zijn om te weten wie/wat er zoveel connecties maakt. Ik zou kunnen testen via een eigen modem.

Net de hele uitleg via een formulier naar TN doorgestuurd, en net telefoon dat er upstream problemen zijn in de wijk, ook gerapporteerd door andere gebruikers.
Het is al sinds 10 september ongoing, en ja al weken krijgen we de Tidal errors.

Ze komen vandaag nog langs.

Gisteren is er iets foutgelopen en niemand langsgekomen. Vandaag opnieuw gebeld.

Persoon aan de lijn werkt al 17j bij TN en kon direct zeggen dat de upload flappert. Ze zien op één of ander grafiekje dat de lijnkwaliteit flappert.

Er is blijkbaar een probleem met een filter om TV ontvangst te blocken of een vochtprobleem in de 'paddenstoel' die in de voortuin staat, die deze filter doet oxideren.

Dus hopelijk is het coax probleem weldra opgelost, nu ze meer concreet weten waar ze moeten gaan zoeken.

Benieuwd hoe de filter er uit ziet die in de paddenstoel zit. Vond hier 2 voorbeelden van zo'n "TOF":

viewtopic.php?p=641551#p641551
//uploads.tapatalk-cdn.com/201601 ... cd0a94.jpg

Dame aan de lijn vandaag was zeer vriendelijk, en wist veel meer dan de medewerkers met wie ik eerder belde. Bevestigt dat TOF wellicht kapot is.
Dus hopelijk is upload weldra stabiel.

Toegevoegd na 3 uren 58 minuten 27 seconden:
De TOF = TV filter is vervangen. Voordien stonden de lijnwaardes op rood, technieker heeft dit laten zien.

Slecht nieuws:

Van zodra de docker actief is, wordt een deel van nieuwe SSL connecties naar de roon API gereset.
Op de Roon machine draai ik

while sleep 1; do curl https://api.roonlabs.net > /dev/null; done

Als ik deze test opnieuw doe, met m'n eigen domein als test, dan blijft dit gewoon draaien.

Ik zie wel dat de latency soms oploopt tot 8 seconden:
Het kan uiteraard dat de Roon API geen geduld heeft, maar dan nog, een simpele Deluge docker die dan nog idle is, mag niet plots regulier HTTPS zo extreem vertragen.

Ondertussen heb ik in de Mikrotik als test de docker zijn upload beperkt tot slechts 64 kbit via simple queu's, en in de plot zie je dan de extreme beperking in de toegestane upload.

En hup, van zodra er P2P is, gaat Telenet at random sommige HTTPS connecties met 8 seconden vertragen.
Die 64 kbit stellt niks voor tov de 50 mbit die ik ook meestal haal in mijn 1000/50 profiel.

Was den truc niet alles achter VPN te steken? (indien mogelijk)

@TheCeet VPN schiet niet op.

Als je max 0,128 % van de upload gebruikt voor P2P, (64 kbit tov 50.000 kbit) mag de rest daar niet onder lijden. En dit is nu precies wat Telenet doet.

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,..."

Probeer anders eens die nieuwe F@ST modem? Die heeft ook bridge mode.

Op aanraden van een ub lid: ben nu de test opnieuw aan het doen met een setje Linux torrents.

https://distrowatch.com/dwres.php?resource=bittorrent


950 mbit down om 22:00 is meer dan OK.
Zie nu wel dat de https test nu veel meer cases met latency heeft, wat te verwachten was. De lijn zit in één richting vol.


Maar het gaat om de case waar https wordt vertraagd of gereset, terwijl de lijn idle is (een TX van 64 kbit is voor mij zo goed als idle, als je 50 mbit hebt).
Dat verwacht je niet.

Ivm de nieuwe modem hoor ik wel dat deze met wifi is. Kan de wifi 100% uitgeschakeld worden?

FredericV schreef: 2 maanden geleden Ivm de nieuwe modem hoor ik wel dat deze met wifi is. Kan de wifi 100% uitgeschakeld worden?

Yep, hier recent nieuwe gehaald wegens poging IPv6 werkend te krijgen (werkt nog niet), op de modem zelf wel, in bridge mode ook, maar valt na x aantal tijd uit, met de nieuwe modem voor mij nog geen 24h

Maar latency is redelijk omlaag gegaan, dus misschien helpt dat, is broadcom ipv intel puma chipset. (1 a 2ms minder met ICMP op een 24h avg)

@TheCeet dat is inderdaad de truuk, maar netjes is het niet.

Telenet is duidelijk in gebreke ivm net neutrality.

Van zodra we de traffic van de Deluge docker door onze eigen VPN trekken (geen grote fan van gezien verspilling van bandwidth, en extra rules moeten opzetten voor deze test, want onze VPN is voor beheer van onze toestellen in the field, en niet voor P2P), dan blijft de curl test die direct via Telenet loopt, gewoon instant antwoorden.

Dus ja, als je P2P traffic door een tunnel gooit, dan moeit Telenet zich niet met normale traffic zoals HTTPS.

Nog ter info: de gratis vpnbook openvpn profielen werken dus niet met P2P, dus dat was geen manier om dit correct vast te stellen.

Mensen met deze modem icm Modem Bridging:

Als je op een aangesloten router reeds firewalling hebt, zet dan zeker in mijn telenet bij IPv4-firewallinstellingen Firewallbescherming uit!
De ingebouwde firewall in de modem kan anders niet altijd volgen.

Dus telenet is duidelijk *niet* in gebreke ivm net neutrality?

Ik kan moeilijk geloven dat de CV8560E met de IPv4 firewall actief, al nieuwe connecties reset, met slechts een paar honderd entries in de connection tracking, waarbij de meeste dan nog in TIME WAIT staan volgens mijn docker.

Als ik bvb kijk op een oude Netgear N600 met dd-wrt, dan heeft deze al 4096 entries:

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
4096

Mijn RB1100AHx2 heeft er 1048576

Of deze beperking in de modem bewust is om applicaties die veel connecties maken in te perken, of een menselijk fout, of door beperkte hardware, laat ik verder in het midden.

Het probleem lijkt nu van de baan, en Telenet zou hun helpdeskers maar beter informeren, dat er beperkingen zijn als je die IPv4 firewall in de modem aan staan hebt, en een aangesloten router in bridging. Ik ben hier in doorlooptijd een week aan verloren.

Ik snap je frustratie en apprecieer het blijven zoeken.
Echter was er al eens aangehaald om eens een andere modem te proberen om het zeker uit te sluiten. Verder zijn telenet helpdeskers eerste lijns en is dit geen probleem waar men elke dag voor belt. Dat telenet dit verder had kunnen bekijken door Xde lijns en jou die feedback had moeten geven, akkoord.

Wat me wel wat stoort is dat je in verschillende threads meteen loopt te roepen dat telenet boeven zijn (ik ben geen fanboy, 't zijn ook boeven ) terwijl je imo nog niet alles had uitgesloten.

Met de modem firewall uit: rond 12u halen we 110 MByte/s met P2P. Dus als er iets goed is, schrijf ik het ook.
Tidal speelt ook al een hele morgen met P2P in idle mode. Dus alles is opgelost dankzij 1 toggle in mijn telenet!

@silentkiller ik roep nergens dat ze boeven zijn, dat is jouw interpretatie. Ik deel enkel de metingen.

Ik heb ruim tien jaar terug ook al aanvaringen gehad met TN ivm shaping.

Als hun firewall al connecties begint te knippen bij een paar honderd entries in de state table, dan kan je je vragen stellen, waarom dit zo artificieel laag ligt.
Telenet heeft ook geen moeite gedaan om mij te informeren dat dit voor deze beperking zou zorgen. De first line is clueless en verder geraken we niet. Ze hebben dit ook eerlijk in een telefoongesprek toegegeven, en dat ik maar via het klachtenformulier moest gaan.

Maar ondertussen dankzij nog wat suggesties op userbase, verder geraakt. Op netweters staat deze info ook niet.

Draai het eens om: als je weet hoeveel connecties P2P opent om het netwerk terug te vinden, dan kan je door het aantal uitgaande connecties in te perken, P2P inperken. Dat er dan in de rest ook geknipt wordt, spijtig - zoek het maar zelf uit want we hebben ook een optie om het weer uit te zetten.

Maar default staat het wel aan, zelfs icm de bridging, en dat dit de performance kan beperken daar wordt in alle talen over gezwegen in Mijn telenet.

Betere training van de first line, het toestaan van escaleren naar een second line ipv vul maar een nieuw formulier in, en betere interne communicatie en betere uitleg op Mijn Telenet, had al deze verloren tijd kunnen vermijden.

Niet volledig verloren, want ik heb weer nieuwe inzichten.