Monitoring Compal CH7465LG-ZG

  • 8 september 2020
  • 90 reacties
  • 2255 keer bekeken

Reputatie 6
Badge +7

In april en mei van dit jaar ben ik bezig geweest om een PHP-script te schrijven t.b.v. monitoring van de down- en upstreamkanalen van mijn Connect Box (Compal CH7465LG-ZG) in Nagios. Door gebrek aan (voor de eindgebruiker toegankelijke) SNMP is het niet mogelijk om op een gebruikelijke manier data op te halen uit het modem en is het nodig om via de ingebouwde webserver van het modem te werken. Ik wilde graag een script in PHP (niet in Python zoals alle andere scripts die ik tegenkwam op het web) omdat ik te weinig ervaring heb met Python en voor Nagios (zakelijk) eerder een klein aantal scripts in PHP geschreven heb.

Het door mij geschreven script heeft ca. 1 maand naar behoren gewerkt. Helaas werkte het daarna niet meer na een firmware-upgrade van het modem door aanpassingen in de vereisten voor authenticatie. Inmiddels is het mij na twee avonden hoofdpijn gelukt om het script aan te passen zodat het weer werkt met de nieuwe(re) firmware.

Het script is in staat om via Nagios notificaties te sturen naar bijvoorbeeld e-mail of SMS (zelf gebruik ik LINE) wanneer signaalniveau/modulatie van een of meerdere kanalen buiten normaal niveau raken.

Ik deel hierbij graag de nieuwe versie in de community en heb deze geüpload in de git repo die ik eerder had aangemaakt: https://gitlab.com/tobias.theebe/ch7465lg-nagios.

Wil je het script gebruiken in je eigen omgeving, dan help ik je graag hierbij.

Hieronder enkele screenshots van de uitvoer van het script in Nagios zelf en in nagiosgraph:

Oudere topics van mij waarin dit script ter sprake is gekomen met tevens andere interessante informatie:


90 Reacties

Reputatie 6
Badge +7

Ziggo heeft via de CMTS inzage in de signaal- en ruisniveaus van de daarmee verbonden CM’s. Alleen als een abonnee ernstige verstoring op het coaxnetwerk veroorzaakt, dan wordt deze hierop aangesproken. Dit is echter meer uitzondering dan regel voor zover ik weet. Je kunt een Ziggo-moderator vragen of er bijzonderheden zijn te zien in MER en CER voor de CMTS waar jouw wijk op aangesloten is.

Mijn huisinstallatie is ook volledig up-to-date. In de afgelopen jaren zijn de CAI-kabel, AOP en splitter vervangen. Op de AOP-splitter zijn slechts het modem en een decoder aangesloten. We hebben maar een TV in huis, in de woonkamer. Geen versterker aanwezig. Hier en daar ligt nog oude bekabeling in de kruipruimte (woning had vier WCD’s toen we er kwamen wonen), echter dit is nergens mee verbonden en de drie inactieve WCD’s (oude, roestige exemplaren zonder kap en onder de verf) heb ik verwijderd.

Als je wil, kan ik gerust nog even een blik werpen op jouw signaal. Indien de EV vlakbij de woning staat, kan het voorkomen dat het DS-signaal net te sterk de woning binnenkomt. In de meeste gevallen kan het modem dit echter compenseren. Het plaatsen van een verzwakker zorgt ervoor dat het modem een hoger US-signaal moet hanteren om de CMTS te bereiken en kan in bepaalde gevallen juist voor meer problemen zorgen.

Ik zal kijken of ik morgen een screenshot kan plaatsen van mijn waardes in mijn modem.

Ik ben maar een automonteur,dus kan even duren.

weet onderhand wel waar ik het moet vinden. :-)

Alvast bedankt voor je hulp.

Connect Box status voor monteursOnderdeelStatusStatusIngesteld Downstream kanaal (Hz)

242000000

Locked

Ingesteld Upstream kanaal (Hz)

44500000

Locked

Provisioning status

Verbonden

 

Gebundelde downstream-kanalen 

Kanaal Frequentie (Hz) Vermogen (dBmV) SNR (dB) Modulatie Kanaalnummer
1 242000000 8 37 256 qam 9
2 178000000 8.5 38 256 qam 1
3 186000000 9 37 256 qam 2
4 194000000 9 38 256 qam 3
5 202000000 8.9 38 256 qam 4
6 210000000 8.9 37 256 qam 5
7 218000000 8.9 38 256 qam 6
8 226000000 8.6 38 256 qam 7
9 234000000 8.4 37 256 qam 8
10 250000000 8 38 256 qam 10
11 258000000 8.6 37 256 qam 11
12 266000000 9.3 38 256 qam 12
13 274000000 9 38 256 qam 13
14 282000000 9.6 37 256 qam 14
15 290000000 10.5 38 256 qam 15
16 298000000 10.9 37 256 qam 16
17 306000000 10.6 38 256 qam 17
18 314000000 10.8 38 256 qam 18
19 322000000 10.9 37 256 qam 19
20 330000000 11.1 37 256 qam 20
21 338000000 11.1 37 256 qam 21
22 346000000 10.9 37 256 qam 22
23 354000000 10.6 38 256 qam 23
24 362000000 10.5 37 256 qam 24


 

Gebundelde downstream-kanalen 

Kanaal Locked Status RxMER (dB) Fouten voor RS Fouten na RS
1 Locked 37.3 753 11141
2 Locked 38.6 253 13816
3 Locked 37.6 246 13886
4 Locked 38.6 265 6676
5 Locked 38.9 262 6952
6 Locked 37.6 217 7438
7 Locked 38.6 314 14651
8 Locked 38.6 683 14170
9 Locked 37.6 463 11788
10 Locked 38.6 579 11531
11 Locked 37.6 854 11448
12 Locked 38.6 753 10832
13 Locked 38.6 599 11617
14 Locked 37.3 432 11240
15 Locked 38.9 542 11471
16 Locked 37.6 515 12375
17 Locked 38.6 430 12892
18 Locked 38.6 583 13236
19 Locked 37.6 631 13056
20 Locked 37.6 583 14104
21 Locked 37.6 444 13344
22 Locked 37.9 618 13482
23 Locked 38.6 633 13715
24 Locked 37.6 913 13908



 

Gebundelde upstream-kanalen 

Kanaal Frequentie (Hz) Vermogen (dBmV) Symbol Rate (ksps) Modulatie Kanaalnummer
1 44500000 4.4 5120 64 qam 6
2 58799907 4.45 5120 64 qam 8
3 35999844 4.4 5120 64 qam 7
4 52000000 4.45 5120 64 qam 5


 

Gebundelde upstream-kanalen 

Kanaal Kanaal soort T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts
1 ATDMA 0 0 0 0
2 ATDMA 0 0 0 0
3 ATDMA 0 0 0 0
4 ATDMA 0 0 0

0

 

Netwerk historie

Tijd Prioriteit Omschrijving
26/10/2020 17:15:55 notice LAN login Success;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
26/10/2020 17:13:25 Let op! Lost MDD Timeout;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
26/10/2020 17:13:22 critical SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
26/10/2020 17:13:21 Let op! RCS Partial Service;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
26/10/2020 17:13:21 critical SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
26/10/2020 17:13:21 Let op! RCS Partial Service;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 12:44:43 notice LAN login Success;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 12:29:9 Let op! RCS Partial Service;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 12:29:9 critical SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 12:29:9 Let op! RCS Partial Service;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 12:28:28 Let op! Lost MDD Timeout;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 12:28:24 critical SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 12:28:23 Let op! RCS Partial Service;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 12:28:23 critical SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 01:19:15 critical No Ranging Response received - T3 time-out;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 00:42:20 notice LAN login Success;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 00:32:24 critical Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 00:28:41 critical No Ranging Response received - T3 time-out;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 00:28:40 critical Unicast Maintenance Ranging attempted - No response - Retries exhausted;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;
25/10/2020 00:28:40 critical Ranging Request Retries exhausted;CM-MAC=48:d3:43:d0:28:5b;CMTS-MAC=00:01:5c:aa:5e:5e;CM-QOS=1.1;CM-VER=3.0;

Dit is alles wat ik kan vinden.

Ik heb op dit moment ook weer lichte verstoringen.

Ik hoop dat een ziggo moderator ook even wil kijken in de cmts. 
Ze hebben nog niet gereageerd op mijn eigen topic.

Reputatie 6
Badge +7

Een paar constateringen:

  • Het vermogen van de DS-kanalen is iets te hoog maar niet kritiek. Gebruik je op dit moment nog een verzwakker tussen AOP-splitter en modem?
  • Grote hoeveelheid post-FEC errors, misschien te groot. Wat is de huidige uptime van het modem? Dit kun je vinden onder Admin, Info.
  • Meldingen in log duiden op (periodiek) veel ruis (SYNC error/MDD timeout). Bij RCS partial service kunnen niet alle (24) DS-kanalen gekoppeld worden.
  • Wel in orde: DS MER (op dit moment), US vermogen.

Misschien kun je een foto plaatsen met de huidige status van de apparatuur en bekabeling?

 

Connect Box informatie

De onderstaande informatie geeft de Connect Box status weer.
 

Conform standaard specificaties :  DOCSIS 3.0 
Hardware versie :  10
Software versie :  9.1.1902.203
MAC-adres :  48:D3:43:D0:28:5B
Serienummer Connect Box :  AAAP81080435
Beschikbaarheid :  1 days 18h:6m:50s
Netwerk toegang :  Toegang tot internet

Internet informatie

Hieronder vind je jouw internet instellingen

MAC-adres :  48:D3:43:D0:28:5D
IPv6 adres :  2001:1C04:1300:0:5DC7:6484:E2DD:37C3
IPv6 standaard gateway :  FE80::201:5CFF:FEAA:5E46
IPv6 leasetijd :  0 days 5h:55m:28s
IPv6 lease verlopen :  26/10/2020 23:35:28.00
IPv6 DNS-servers :  2001:730:3E42:1000::53
IPv4 adres :  83.81.97.67
Standaard gateway :  83.81.96.1
IPv4-leasetijd :  5 days 5h:55m:21s
IPv4-lease verlopen :  31/10/2020 23:35:21.00
IPv4-DNS-servers :  84.116.46.22
IPv6 DS-Lite status :  Uitgeschakeld
DS-Lite-FQDN :  aftr01.upc.nl
DS-Lite-adres :  ::

Ik had er gisteren 2 splitters tussen op verzoek van iemand anders op dit forum om het signaal wat af te zwakken.

Ik heb hem nu weer aangesloten zoal het volgens ziggo de beste opstelling is.

splitter op aop en dan daar vandaan 1kabel naar modem en 1 naar versterker. 

Reputatie 6
Badge +7

Het modem moet op de AOP-splitter aangesloten worden, niet op de signaalversterker. Bij veel klanten levert dit problemen op. De versterker mag in principe alleen voor TV en radio gebruikt worden.

Verder is de uptime nog slechts 1¾ dag en dan is 7.000-14.000 post-FEC errors per kanaal flink teveel. Ik zit hier op 80-250 na 1 week.

Ja zo heb ik hem idd aangesloten.

Dus ik heb veel te veel errors.

waar kunnen die vandaan komen? 
 

Reputatie 6
Badge +7

Zag dat onze reacties elkaar gekruist hebben. Ik stel voor om in jouw topic te wachten op een moderator. Hij/zij kan in de CMTS de historie bekijken voor alle modems die hiermee zijn verbonden, dus ook de modems van jouw buren. Zo kunnen we kijken of zij ook last hebben van MER/CER-problemen zoals jouw modem die vertoont.

Ok ga ik daar op wachten. 

Bedank voor je hulp Tobias. 

Reputatie 6
Badge +7

Voor de liefhebbers: MER-geschiedenis van mijn modem over de afgelopen weken.

Script werkt nog steeds naar behoren.

 

Reputatie 6
Badge +7

Na veranderingen van de firmware krijg ik last van de volgende melding:

Failure inlog

Ik gebruik je php gemodificeerde script om in te loggen onder de vorige versie firmware had ik hier geen last van . De script wordt gebruikt 6 maal om in te loggen met een vertraging van 30 seconden per script (voorheen 7 seconden).

De failure report is tussen  de 0 seconden en 7 seconden. 

Reputatie 6
Badge +7

@jarielcapitain Dat is vervelend. Het kan zijn dat er nog ergens een bug in het script zit. Ik weet niet 100% zeker of de logout-functie goed werkt. Ik heb bovenstaande error langs zien komen wanneer ik het modem niet genoeg tijd gaf.

Ik controleer downstream en upstream elke 5 minuten en heb deze in Nagios zo afgestemd dat er +/- 2,5 minuut tussen elke aanroep zit.

Ik heb nog niet gecontroleerd of ik de nieuwe firmware al heb op mijn modem.

Reputatie 6
Badge +7

Het was eigenlijk een mededeling(kleine waarschuwing) wat je mag verwachten. 

De logout werkt nu beter in ieder geval, voorheen moest ik een 1 uur wachten om via de web browser in te loggen, dat is nu niet het geval.

Je kan natuurlijk zien aan het aantal t3 meldingen en/of Pre/PostRs errors of je de nieuwe firmware hebt.

 

Apart van dat heeft je script prima gewerkt zeker voor een aantal maanden, terwijl ik met de python script om de week de modem moest resetten dat hij foutmelding gaf.

Ik gebruik nu InfluxDb voor de data en grafana voor het grafische gedeelte.

 

Reputatie 6
Badge +7

Ik had eergisteren, 24 november, om 3:14 een hele korte onderbreking (ca. 1 minuut) in de internetverbinding. Daarna stonden inderdaad de T3 en post-FEC RS errors op 0. T3 staat nog steeds op 0, trouwens, dat gaat beter dan voorheen.

Ik zou best even willen inloggen op het modem in de browser om te kijken of ik ook de nieuwe firmware heb, alleen moet ik dan tijdelijk het script pauzeren om geen authenticatieproblemen te krijgen (melding andere gebruiker reeds ingelogd). Ik doe dat dus liever wanneer ik alleen thuis ben, zodat ik het modem opnieuw kan opstarten indien nodig.

Ik doe de monitoring nog steeds op de ‘ouderwetse’ manier: Nagios en RRDtool.

Reputatie 6
Badge +7

@jarielcapitain Om nog even terug te komen op de foutmelding die jij in de log ziet (GUI token verify failed), ik zie deze ook terug bij mij. Ik gebruik vrijwel zeker nog de oude firmware, password box was niet afgeschermd en uptime staat op ca. 40 dagen. Interface was erg traag, openen van de downstream/upstream/etc. tabs duurde minuten.

Vrijwel zeker ligt de foutmelding aan de doLogout-functie, deze gebruikt momenteel alleen de session ID en niet de session token. Ik moet in getChannels de session token ophalen, opslaan in st en deze vervolgens gebruiken in doLogout. Ik ga eens kijken of het lukt om dit vandaag te implementeren.

Reputatie 6
Badge +7

Ik zal geduldig wachten, bedankt in ieder geval voor de moeite.

Reputatie 6
Badge +7

Ik ben er wat verder mee gekomen maar ben er volgens mij nog niet. Heb alvast wel een paar nieuwe commits in de git repo gezet.

De webserver reageert nogal vreemd wanneer ik probeer de headers op te vragen in getChannels, er wordt dan geen data meer doorgegeven. Deze headers zijn wel nodig omdat daar de session token in staat.

Zojuist ook nog even vanaf een werkende versie van het script (nog wel de token error in de log uiteraard) alleen de ‘boosdoener’-regel toegevoegd, meteen hetzelfde probleem (object uit cURL request is leeg).

UPDATE: volgens mij weet ik nu waarom dit fout gaat. Als ik in getChannels zowel body als header opvraag, dan is simplexml_load_string waarschijnlijk niet meer in staat om de XML te converteren naar een PHP object, omdat de headers erboven staan...

Reputatie 6
Badge +7

Ik moet dus nog een manier vinden om uit de cURL output van getChannels (waar de headers in staan, dan een witregel en vervolgens de XML) alleen de laatste regel met XML over te houden om die vervolgens door te kunnen geven aan simplexml_load_string.

UPDATE: gevonden, kijken of dit gaat lukken.

UPDATE 2: volgens mij is het gelukt om de error in de log weg te krijgen! Uiteindelijk is bovenstaande gelukt met een preg_match.

Er staan nu een hoop nieuwe commits in git (was volop aan het testen en debuggen), maar de voornaamste wijzigingen staan in regels 71 (token meegeven bij logout), 94 (ook headers opvragen bij channels) en 108 (headers en body (laatste regel van channels output) uitsplitsen).

Reputatie 6
Badge +7

Ik ga er morgen mee aan de slag en laat je het weten.

Reputatie 6
Badge +7

Top, ben benieuwd. Ik had het script als test direct op de server uitgevoerd (buiten Nagios) om te testen. Wel gewoon volledig laten lopen inclusief logout. Daarna gekeken in het modem log en geen nieuwe token error.

Reputatie 6
Badge +7

@jarielcapitain Neem jij nog 16-QAM op US-kanalen waar? Hier komt het nog steeds sporadisch (ongeveer eens per maand) voor. Het duurt altijd ~20 minuten en gaat ook gepaard met fluctuatie van power level op het betreffende kanaal:

 

Reageer