Connect Box - Upstreamkanalen vallen willekeurig terug naar 16-QAM

[tobiastheebe]

Het viel mij eergisteren voor het eerst op dat bepaalde (willekeurige) upstreamkanalen op willekeurige momenten terugvallen van 64- naar 16-QAM op mijn Compal Connect Box. Meestal is het kanaal 2 op 44.5 MHz. Is dit normaal? Ik ben overigens van plan om het modem vandaag sowieso een power cycle te geven.

Op dit moment werkt alles naar behoren:

[efok]

Heb je ook error logs uit het modem?

[tobiastheebe]

Jazeker, hierbij. Zelf ook al naar gekeken, maar zie hier niets bijzonders in staan.

[jarielcapitain]

Welke compal versie heb je nu. Er wordt een nieuwere versie uitgerold en met deze versie is het niet mogelijk om zonder pasword gegevens via curl te krijgen als je dit gebruikt. Ik kan morgen wel een script in mekaar rijgen om de modulatie te monitoren met 5 minuten interval

[tobiastheebe]

Oei, dan moet ik de authenticatiefunctie van mijn script opnieuw schrijven. Mijn Connect Box heeft nu software CH7465LG-NCIP-6.12.18.25-2p5-NOSH en ik gebruik inderdaad cURL in mijn script. Elke keer dat ik het script draai vraag ik nu een nieuwe token op dus wenselijk is dat niet. Het beste zou zijn om een cookie jar te gebruiken.

Toen ik eenmaal doorhad dat een van de upstream channels op 16-QAM stond, heb ik meteen mijn script zó aangepast dat deze een afsluit met een warning als een of meerdere van de downstream en upstream channels niet respectievelijk 256-QAM en 64-QAM zijn.

[jarielcapitain]

@tobiastheebe 

Waarschijnlijke oorzaak is een slechte SNR bij de CMTS.

De CMTS beheerd het modem CM en verstuurd opdrachten naar het modem, bv het verhogen/verlagen van het vermogen dat het modem mag zenden. Dit wordt ook niet gelogd.

In jouw geval wordt de modulatie gewijzigd wat ik vreemd vindt dit zou m.i. ook kunnen met het verhogen van het zendvermogen om een betere snr te krijgen, er is ruimtegenoeg. Kan je ook controleren of de symbolrate ook aangepast wordt.

In fUPC wanneer  er wordt gebruikt gemaakt van  6 US kanalen, de 2 kanalen met de laagste frequentie, gebruiken dan een lagere symbolrate i.v.m. ruis.

Dit is mijn activiteit met zendvermogen over de laatste 72 uur

[tobiastheebe]

Ik zat inderdaad ook te denken aan een tijdelijk verhoogde hoeveelheid ruis op het betreffende kanaal. Helaas kunnen wij als eindgebruikers niet zien wat de SNR bij de CMTS is en of een verlaagde SNR een bepaalde aansluiting of een geheel coax-segment betrof.

Zelf vind ik het ook vreemd dat het modem terugvalt naar een lagere modulatie terwijl de signaalniveaus in orde zijn en constant blijven. Ik heb gisteren om 19:30 de laatste alert gehad, opnieuw over 44.5 MHz en opnieuw 16-QAM voor ~20 minuten, dit zal ik in de gaten blijven houden. Verder moet ik het modem nog een reboot geven, mogelijk komt dit de stabiliteit ten goede.

De symbol rate is interessant en zal ik vandaag toevoegen aan mijn script. Een maand geleden was deze 5120 ksym/s op alle US-kanalen, nu nog steeds.

[jarielcapitain]

@tobiastheebe  @efok 

Surprise surprise 

Ik heb er ook last van vanaf 19:30 -19:50 en 21:50 22:10. en ook op hetzelfde kanaal

Voor de aardigheid het mac-adres van de CMTS-MAC=00:01:5c:b1:76:46;CM-QOS=1.1;CM-VER=3.0; Het is nu weer normaal Voor zover ik weet  is het een Arris/Cadant modem.

Geen verandering in de symbol rate. or T3 errors

[tobiastheebe]

Interessant, ik heb op dit moment (sinds 22:11) ook weer een alert. Ook weer 44.5 MHz. Inderdaad geen verandering in signaalniveau, T3 en symbol rate. Jij en ik zitten niet toevallig in dezelfde regio (Noord-Holland Noord)? We zitten niet achter dezelfde CMTS zo te zien, al zit ik ook achter een Arris/Cadent CMTS.

[jarielcapitain]

Dacht ik misschien ook vandaar het cmts mac adres regio (roosendaal bergen op zoom tilburg ?).

Misschien wordt het ook beïnvloed door de mediabox xl Het laatste tijdslot heb ik de MBXL uitgezet Ik ga daar in ieder geval op letten.

[KBX458]

De mediabox xl opgenomen in het huisnetwerk en met een utp kabel verbonden met de connectbox levert vele problemen op. 

[jarielcapitain]

Mbxl Is niet opgenomen in het netwerk 

[tobiastheebe]

Hier ook (al jaren) niet.

[tobiastheebe]

Eergisteren de laatste alert gehad, deze keer voor 36 MHz:

[jarielcapitain]

Dit is mijn resultaat over een periode  van 72 uur tijdinterval periode is 5 minuten en ook van verschillende kanalen.

Mon May 11 2020 19:25:47 GMT+0200 (Central European Summer Time) ,ch3, 16
Mon May 11 2020 19:45:47 GMT+0200 (Central European Summer Time) ,ch3, 64
Mon May 11 2020 20:15:48 GMT+0200 (Central European Summer Time) ,ch1, 16
Mon May 11 2020 20:25:47 GMT+0200 (Central European Summer Time) ,ch4, 16
Mon May 11 2020 20:35:52 GMT+0200 (Central European Summer Time) ,ch1, 64
Mon May 11 2020 20:45:51 GMT+0200 (Central European Summer Time) ,ch4, 64
Mon May 11 2020 21:30:50 GMT+0200 (Central European Summer Time) ,ch4, 16
Mon May 11 2020 21:45:49 GMT+0200 (Central European Summer Time) ,ch1, 16
Mon May 11 2020 21:50:54 GMT+0200 (Central European Summer Time) ,ch4, 64
Mon May 11 2020 22:05:47 GMT+0200 (Central European Summer Time) ,ch1, 64
Mon May 11 2020 22:15:52 GMT+0200 (Central European Summer Time) ,ch4, 16
Mon May 11 2020 22:35:48 GMT+0200 (Central European Summer Time) ,ch4, 64
Mon May 11 2020 23:15:48 GMT+0200 (Central European Summer Time) ,ch1, 16
Mon May 11 2020 23:35:48 GMT+0200 (Central European Summer Time) ,ch1, 64

Dit is wat Archie.DVB schreef in dit artikel

Totale capaciteit upstream kanalen in coaxsegment

Upstream kanalen worden gebruikt om DOCSIS data packets van de modems naar de CMTS te verzenden. Modulatie van die upstream kanalen vindt plaats aan de modem kant van de HFC infrastructuur. Er zijn daarom meerdere zenders en de CMTS is de enige ontvanger. Omdat het niet erg zinvol is om alle modems tegelijk te laten zenden via de beperkte set upstream kanalen heeft een groot deel van de DOCSIS specificatie betrekking op de benodigde mechanismes om modems om de beurt te laten zenden waarbij de CMTS bepaalt wie er mag zenden en voor welk doel er gezonden mag worden. Op hoofdlijnen vallen die doelen uiteen in DOCSIS management verkeer en data verkeer van de kabel internet gebruiker. 

Dit maakt het bepalen van de capaciteit van een upstream en daarmee de totale upstream capaciteit van een coaxsegment nogal lastig. Ook werken de diverse modulatie technieken en verschillende bandbreedtes niet mee. Een upstream kanaal met de maximale bandbreedte van 6.4 MHz en 64-QAM modulatie heeft in theorie een capaciteit van maximaal 28 Mbps, maar is dus niet continu in gebruik met deze instellingen. Wanneer hetzelfde upstream kanaal tijdelijk met QPSK modulatie gebruikt wordt voor DOCSIS management verkeer dan valt de capaciteit terug naar maximaal 9 Mbps. Kanalen met 3.2 MHz bandbreedte hebben de helft van de capaciteit van een kanaal met 6.4 MHz bandbreedte met dezelfde modulatie instellingen. De bandbreedte van een upstream kanaal kan via de modem upstream status pagina afgeleid worden aan de hand van de symboolsnelheid. Een symboolsnelheid van 5210 ksps komt overeen met een bandbreedte van 6.4 MHz en een symboolsnelheid van 2560 ksps met 3.2 MHz.

Mischien is bovenstaande de oorzaak QPSK of QAM16 ???

[tobiastheebe]

Zojuist het modem een reboot gegeven, eerder vandaag op bepaalde momenten willekeurige US-kanalen tegelijk op 16-QAM. Kijken of het nu beter gaat.

De software is van CH7465LG-NCIP-6.12.18.25-2p5-NOSH naar CH7465LG-NCIP-6.12.18.26-3p6-GA-NOSH gegaan en mijn script lijkt niet meer te werken, dus ga daar nu weer mee aan de slag.

Deze commands werken dus niet meer, althans: het modem geeft geen data meer terug voor fun 10 en de eerder verkregen token:

:~/git/ch7465lg-nagios $ curl -I -s http://192.168.100.1/common_page/login.html
HTTP/1.1 200 Ok
Server: NET-DK/1.0
Date: Wed, 13 May 2020 13:04:37 GMT
Last-Modified: Fri, 31 Jan 2020 05:09:57 GMT
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/html
Content-Length: 40656
Connection: close
Set-Cookie: sessionToken=4082746112; path=/;

:~/git/ch7465lg-nagios $ curl -s http://192.168.100.1/xml/getter.xml --data "token=4082746112&fun=10"
:~/git/ch7465lg-nagios $

[Rikst]

Ik ben benieuwd naar de stand van zaken, @tobiastheebe Heb je je script kunnen aanpassen? En hoe gaat het nu?

[tobiastheebe]

Helaas ben ik hier nog niet veel verder mee gekomen. Om het script weer te laten werken moet ik nieuwe cURL commands samenstellen omdat de oorspronkelijke twee niet meer werken, zoals jarielcapitain aangaf in zijn eerste bericht in dit topic vereist het modem nu authenticatie met het wachtwoord, alleen de token opgeven voldoet niet meer.

Ik heb geprobeerd om te volgen welke data het modem teruggeeft in de headers wanneer ik op de normale manier, via de browser, inlog en de DS/US-data bekijk. Via de developer tools in de browser kan ik zien dat het modem steeds een nieuwe token geeft die mijn browser in het volgende request gebruikt. Dit was ook het geval met mijn script. Echter, ik zie naast de token ook een SID (sessie-ID) gebruikt worden die steeds hetzelfde is en ik kan er niet achter komen hoe ik deze verkrijg van het modem. Mijn browser gebruikt deze nadat ik inlog met mijn wachtwoord. Samengevat, het is nog niet gelukt om het script aan te passen zodat het werkt voor de nieuwe modemsoftware.

Omdat ik het script nu niet gebruik, kan ik ook niet zien of het terugvallen van US-kanalen naar 16-QAM nog is voorgekomen de afgelopen twee dagen.