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.

[Eddie the Eagle]

Zou je aub een korte instructie (voor niet techneuten 😉) kunnen geven wat we moeten doen voor deze update ?

[Pasi]

Ik lees dit altijd met veel interesse, maar qua script gaat dit boven m'n pet. Ik programmeer dan wel, maar dat is vooral meer als hobby en in een gehaal andere taal.

De resultaten vind ik altijd erg interessant, vooral omdat de meting niet door Ziggo wordt uitgevoerd en de meting bij een klant thuis worden gedaan. Eigenlijk is dit een vinger aan de pols van Ziggo, waarbij Ziggo ( hopelijk ) geen invloed heeft op de uitkomsten.

Het kost misschien wel veel tijd, maar misschien zou hiervan een artikel in de kennisbank gemaakt kunnen worden. Zodat iedereen die dit zelf wil proberen, aan de hand van dat artikel kan zien hoe dit gedaan moet worden.


Ergo: Ziggo kan ons van alles beloven en vertellen, maar ik ( een klant ) geloof niet meer in sprookjes en weet ondertussen, dat Ziggo er niet voor mij is, maar ik voor Ziggo. Daarom is iedere onafhankelijk controle op Ziggo's diensten/services/..., altijd welkom !

[MR_CHIP]

zo'n kennisbank artikel zou wel mooi zijn idd 

[tobiastheebe]

@Eddie the Eagle Je hoeft alleen check_ubc1318.php te vervangen.

@Pasi @MR_CHIP Ik ben bij het beschikbaar stellen van het script uitgegaan van een werkende Nagios- of andere (monitoring-)omgeving. Voor Nagios heb ik deze instructies geschreven. Als andere optie is debug_ubc1318.php beschikbaar voor integratie met een andere omgeving naar wens, zolang PHP, cURL en JSON maar ondersteund worden. Omdat iedereen eigen voorkeuren heeft, heb ik (tot nog toe) geen complete handleiding geschreven voor het opzetten van een monitoring-omgeving, temeer omdat hiervoor reeds diverse handleidingen en tutorials beschikbaar zijn, ook via bijvoorbeeld YouTube.

Omdat SNMP niet luistert op de interne management interface (192.168.100.1 en 192.168.178.1) was helaas geen standaardoplossing mogelijk, maar moest er maatwerk aan te pas komen. Ook ondersteuning voor remote syslog zou zeer waardevol zijn, zodat events naar een externe server verstuurd kunnen worden en de beperking van maximaal 32 events in de log niet aanwezig is.

[tobiastheebe]

Sinds vandaag ervaar ik spontaan problemen met het ophalen van de event log d.m.v. mijn externe script. Ik heb het script zo aangepast dat ik de rechtstreekse HTML te zien krijg, wat blijkt: het modem toont geen normale event log maar alleen vreemde test events. Nog nooit eerder gezien. Mijn andere scripts werken nog prima en ook het ophalen van de DS/US data in Nagios werkt naar behoren. Ik wacht maar weer een volgende reset of nieuwe verbindingsopbouw af, hopelijk is het daarna hersteld.

var cm_info_event_log_json = '{  \
                "cm_syslog_array":[    \
                        {       "severity":"crit",    \
                                "datetime":"Dec 19 18:30:21",    \
                                "facility":"ssd",    \
                                "message":"Test syslog message."    \
                        },    \
                        {       "severity":"alert",    \
                                "datetime":"Dec 20 12:33:29",    \
                                "facility":"ssk",    \
                                "message":"Test syslog message."    \
                        },    \
                        {       "severity":"emerg",    \
                                "datetime":"Dec 21 03:15:33",    \
                                "facility":"sshd",    \
                                "message":"Test syslog message."    \
                        }    \
                ]    \
        }';

[Eddie the Eagle]

mmm, nergens last van hier, alle logs zijn normaal. Ik heb wel nooit de update naar de laatste Nagios versie gedaan omdat ik me kan herinneren dat je daar issues mee had. Die staat nog altijd op mij programma om een keer te doen.

[tobiastheebe]

Gisternacht was er een tuner reset vanwege 'unicast ranging received abort response', geen idee wat hiervan de oorzaak was, mogelijk het OFDMA-kanaal. Nadat het modem weer online was meteen even de event log opgehaald en zag daar deze event vóór de reset. Vandaag werkt dan de event log spontaan niet meer. Morgen nog eens opnieuw proberen. Blijft jammer dat er geen SNMP aan LAN-zijde of remote syslog aanwezig is op de UBC1318ZG.

Nagios Core 4.4.7 heeft inderdaad last van crashes (bij opstarten direct sigfault) door de update check, in 4.4.8 is dit opgelost, inmiddels is 4.4.9 ook uit. Er zijn vooralsnog alleen kleine wijzigingen geweest, dus je mist nog niets: Nagios Core 4.x Version History.

[Eddie the Eagle]

Ik zit hier idd nog op 4.4.6 en als ik je goed begrijp nog weinig reden voor een update dus.

[tobiastheebe]

Ik zou wel de update naar 4.4.9 uitvoeren, duurt maar ~5 minuten. Ik maak van tevoren wel altijd een backup van /usr/local/nagios/.

cd ~/
wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.4.9.tar.gz
tar xzf nagios-4.4.9.tar.gz
cd nagios-4.4.9/
./configure --with-command-group=nagcmd
make all
sudo make install
sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
sudo service nagios restart

[tobiastheebe]

De event log is spontaan weer normaal gaan functioneren zonder reset van het modem, voor mij een hele opluchting.

[Eddie the Eagle]

Wel heel apart en heeft er ook lange uitgelegen dan toch ?

Ik moet de update nog uitvoeren naar 4.4.9 🙄. Wel blijft alles rustig doorpruttelen hier op de VM.

[tobiastheebe]

Ik heb het niet elke week opnieuw geprobeerd.

[Eddie the Eagle]

Update maar eens gedaan; hij draait nu op 4.4.9

[tobiastheebe]

Modem is zojuist spontaan weer in die vreemde status terechtgekomen. Deze keer toont ook de connection page sample data i.p.v. de werkelijke data. Via browser kan ik niet inloggen, via mijn scripts wel. Ik heb de modem checks in Nagios voor nu gepauzeerd en ga morgenochtend een poging doen om deze te hervatten. Als het probleem er dan nog steeds is, dan is een reset de volgende stap.

[tobiastheebe]

Vanmiddag maar een reset van het modem uitgevoerd om monitoring weer werkend te krijgen.

Zojuist een zeer interessante ontdekking gedaan met Nmap, SNMP blijkt toch beschikbaar te zijn aan LAN-zijde. Ik ga dus proberen of het mogelijk is om via deze weg data op te vragen.

Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-17 23:28 W. Europe Standard Time
Nmap scan report for 192.168.100.1
Host is up (0.0035s latency).
PORT    STATE SERVICE
161/udp open  snmp
| snmp-info: 
|   enterprise: Ambit Microsystems Corporation
|   engineIDFormat: octets
|   engineIDData: 00000000000033 (i.p.v. 0 werd de CM MAC vermeld)
|   snmpEngineBoots: 370
|_  snmpEngineTime: 9h48m18s
Nmap done: 1 IP address (1 host up) scanned in 1.09 seconds

[efok]

Bijzonder, ik heb dat niet. Bij mij zijn de poorten 80,443, 9001,9002 open. 161 niet. Ubee 1318 toch? Welke firmware heb je?

[Eddie the Eagle]

Dat probleem met GUI van het modem (niet bereikbaar) heb ik sinds ik Nagios gebruik. Na een restart werkt het een tijdje, dan is het gedaan.

nmap:

[tobiastheebe]

Betreft inderdaad de UBC1318ZG, met 12.5.8011.S15.ZIGGO firmware. Ik heb onderstaande commando gebruikt.

nmap -sU -p 161 --script snmp-info 192.168.100.1

[efok]

@tobiastheebeWat grappig, ik had hem op 178.1 gescand en dan zit hij dicht:

Nmap scan report for 192.168.100.1
Host is up (0.0023s latency).

PORT STATE SERVICE
161/udp open snmp
| snmp-info:
| enterprise: Ambit Microsystems Corporation
| engineIDFormat: octets
| engineIDData: 0cb9374a5dd033
| snmpEngineBoots: 377
|_ snmpEngineTime: 1d15h01m47s

Nmap done: 1 IP address (1 host up) scanned in 0.51 seconds

:~$ sudo nmap -sU -p 161 --script snmp-info 192.168.178.1

Nmap scan report for 192.168.178.1
Host is up (0.0018s latency).

PORT STATE SERVICE
161/udp open|filtered snmp

De vraag is nu of je toegang krijgt.....

[tobiastheebe]

Het is mij nog niet gelukt om andere data op te halen. Ik heb met Wireshark gekeken naar de scan van Nmap, waarin SNMPv3 wordt gebruikt met blijkbaar geen enkele vorm van authenticatie. Ik heb echter geen idee hoe ik dit buiten Nmap moet nabootsen.