Monitoring Ubee UBC1318ZG

[tobiastheebe]

Dit is de voortzetting van een vorig door mij gestart topic over monitoring van de Compal CH7465LG-ZG.

Ik heb vandaag een Ubee UBC1318ZG in gebruik genomen. Dit modem staat net zoals de Compal CB in bridge mode en is aangesloten via een POA-01-B op de btv 1 IEC-NL. In tegenstelling tot de Compal CB heb ik voor de Ubee een attenuator (3 dB) geplaatst omdat de downstream altijd aan de sterke kant was. Ook voor de Ubee ben ik van plan om een monitoring script te schrijven en over de ontwikkeling daarvan wil ik updates gaan plaatsen in dit topic.

Eerst echter het volgende: sinds omstreeks maart/april had de Compal CB veel last van lage MER-waarden en hoge correctable + uncorrectable codewords op de hogere kanalen. Na het aansluiten van de Ubee leken deze problemen even totaal verdwenen, op alle kanalen 42~43 dB MER en op enkele kanalen 1 correctable error na ~30 minuten uptime. Nu na ~3 uur is de ruis helaas weer volop terug, het gaat duidelijk om instraling van 4G/5G:

Nu mijn vraag: zou een Ziggo-moderator (bijvoorbeeld @Alex) nogmaals naar de DS CER in de wijk willen kijken? Mijn vermoeden is dat een of meerdere van onze buren hun binnenhuisinstallatie niet op orde hebben. Ik denk dat het langzamerhand tijd wordt dat een netwerkmonteur komt meten op de EV.

[efok]

@tobiastheebe Heb je hier wat aan?:
https://svn.nmap.org/nmap/scripts/snmp-info.nse

[tobiastheebe]

Die source code had ik inderdaad gezien en doorgenomen, maar kwam hier niet veel verder mee. Ik heb bijvoorbeeld geen idee hoe ik de waarde van local SNMPv3GetRequest zou moeten decoderen.

[efok]

Wellicht ondersteunt het modem ook gewoon snmpv2. Ik heb geprobeerd hem toe te voegen aan mijn librenms, maar dat wil niet zonder de juiste community string.  V3 zonder credentials lukt ook niet. In het verleden was het voor Ambit gewoon "public" maar daar zullen ze wel van hebben geleerd.........

[tobiastheebe]

Ik heb zowel versie 1 en 2c geprobeerd, met zowel public als cable-docsis als community string, voor dezelfde OID als die Nmap opvroeg, maar geen succes (timeout bij alle verzoeken). Zowel snmpget op Debian als iReasoning MIB Browser op Windows geprobeerd.

[Eddie the Eagle]

Nagios 4.4.10 is onlangs ook uitgekomen zie ik.

[tobiastheebe]

Dank je, ik zie dat de versie op 17-1 is uitgebracht. Ondanks dat automatisch controleren op updates is ingeschakeld (check_for_updates=1 in nagios.cfg) heb ik geen bericht gezien in Nagios, vreemd.

[tobiastheebe]

Ik kom er net achter dat diverse pagina's (waaronder cm_info_connection.php) zonder authenticatie aangeroepen kunnen worden. Ik heb het dus een stuk moeilijker gemaakt dan nodig was bij de eerste development van de monitoring scripts. Op zich een aangename verrassing, al is het wat minder uit veiligheidsoogpunt. Zojuist heb ik een nieuwe commit gedaan op mijn git repo.

[Eddie the Eagle]

Moeten we iets doen ?

[Eddie the Eagle]

Ik zit hier trouwens nog altijd op 4.4.9. Ik zie dat 4.5.0 uit is; is het verstandig om eens te updaten ?

[tobiastheebe]

De scripts roepen nu slechts één URL aan i.p.v. vier, dus ik zou zeker adviseren om check_ubc1318.php te vervangen. Hierbij voor de zekerheid nog even de git repo.

De updates van Nagios Core zijn klein dus je hoeft deze niet per se bij te werken, al is 4.4.9 inmiddels bijna 1,5 jaar oud.

[tobiastheebe]

Kleine update: gescheiden berekeningen van avg/min/max en warn/crit thresholds voor US ATDMA + OFDMA, dit i.v.m. de gebruikelijke ~6 dBmV delta in Tx power tussen beide kanaaltypen. Hier (nog) geen tweede OFDMA-kanaal, maar alvast wel voorbereid op de komst hiervan. Bij actuele waarden ook duidelijker onderscheid gemaakt tussen zowel SC-QAM/OFDM als ATDMA/OFDMA.

---

Oude situatie:

 

Nieuwe situatie:

 

[tobiastheebe]

Work in progress: een van mijn 'debug' scripts gebruikt om de event log automatisch over te zetten naar MySQL op thuisserver, t.b.v. overzichtelijke inzage via LogAnalyzer, min of meer als alternatief voor ontbreken van remote syslog in de webinterface. Cron job is aangemaakt om het script dagelijks uit te voeren.

Ik ben nog aan het nadenken over een manier om bij elke uitvoering van het script alleen de nieuwe events op te nemen. Kijken naar de datum is een optie, maar er kunnen ook events voorkomen met een datum van 1-1-1970 en die moeten ook opgenomen worden. Er wordt helaas geen uniek ID aan elk event toegekend, dan zou het eenvoudig zijn.

[MR_CHIP]

Mooi zeg

[tobiastheebe]

Voor nu toch maar gekozen om dagelijks alleen de nieuwe events met geldige datum op te halen. Ik kan snel genoeg en op meerdere manieren afleiden dat events met datum 1-1-1970 zijn voorgekomen en de log dan alsnog even handmatig ophalen. Ik heb verder een array_reverse() function toegevoegd zodat events van nieuw naar oud getoond worden.