Ik heb een CV8560E in bridging, met een Mikrotik RB1100AH (x2). Omwille van upstream problemen is vorige week de modem alsook een TV filter (TOF) in de paddenstoel vervangen. De oude TOF was verouderd en de technieker toonde lijnwaarden die in het rood gingen. Nadien leek alles OK. Helaas heeft dit het probleem niet verholpen. Ik heb een Deluge docker draaien met daarin een aantal officiële Linux torrents. De lijn trekt 990 mbit via fast.com en haalt quasi de volle 50 mbit upstream, dus het 1000/50 profiel wordt hier vlotjes gehaald. En gisteren bij het downloaden van een berg Linux torrents rond 22u, deed de lijn 950 mbit. Netjes! De problemen stellen zich echter niet bij belastig van de verbinding, maar bij normaal gebruik en idle P2P. Van zodra Telenet idle P2P verkeer detecteert (dus geen enkele torrent is aan het up- of downloaden, maar er is wel idle protocol verkeer die in de orde ligt van jaren 90 inbelmodems), dan worden op eender welke host in mijn thuisnetwerk HTTPS connecties ofwel vertraagt, of zelfs gereset. Het maakt niet uit of die hosts dan achter de Mikrotik hangen, of achter de modem, zelfs traffic wat met een ander IPv4 naar buiten gaat wordt beïnvloed. Sommige applicaties kunnen hier niet mee overweg. Zo verliest een applicatie als Roon zijn connectie met Tidal door deze resets, en stopt een flac stream die in meerdere delen wordt ingeladen. Roon's coverart hapert ook. Ook curl testen naar userbase.be tonen deze resets. Helaas krijg ik van Telenet hierover geen degelijk antwoord, buiten dan een snelle opvolging van het modemprobleem. Op userbase loopt hier ook een topic over: https://userbase.be/forum/viewtopic.php?t=67585 Het meest bizarre dan nog, is het feit dat het niet uitmaakt waar de Deluge doos achter de modem hangt: als we deze achter de Mikrotik hangen die een public IPv4 krijgt, gaat P2P verkeer naar buiten met een ander IPv4 als hosts die direct aan de modem hangen (die gaan naar buiten met het WAN ip van de modem): HTTPS wordt vertraagd van zodra er idle P2P verkeer door de modem gaat. Ook het omgekeerde geldt: Deluge direct achter modem, en curl test via de Mikrotik -> HTTPS vertraagt of wordt gereset. Ik heb een verleden in networking en traffic shaping, en wat hier gebeurt lijkt mij geen normaal netwerkbeheer. Immers de lijn wordt niet gesatureerd, en zelfs als P2P hard wordt afgeknipt in de Mikrotik (bvb 64 kbit upstream via een simple queu, dus een fractie van de 50 mbps upload) dan nog steeds wordt HTTPS vertraagd of gereset. Deze ochtend draaide ik een test met enkel P2P protocol verkeer, en de invloed op HTTPS: Een gelijkaardige curl naar userbase.be of de Roon api url, zorgt zelfs voor resets: $ while sleep 1; do curl https://userbase.be/api >/dev/null; done
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 274 0 274 0 0 1053 0 --:--:-- --:--:-- --:--:-- 1053
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to userbase.be:443
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 274 0 274 0 0 2283 0 --:--:-- --:--:-- --:--:-- 2283
... Meer weergeven
