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.
Jij bent de IT-hulplijn in je straat, de verlichting werkt thuis op commando en je groet de pakketbezorger met de slimme deurbel. Herkenbaar? Dan zijn de Community events echt iets voor jou! Doe mee en sluit je aan.
De uncorrectable errors lopen nu al in de tienduizenden... MER staat nog steeds op 42~43 dB, perfect dus. Denk dat dit wel bewijst dat de ruis ergens van buitenshuis afkomstig is.
Onze wijk (en het kabelnet) dateert overigens uit begin jaren '80, de CAI-kabels vanuit de EV zijn Siemens-kabels van '79. Onze kabel is in februari '20 in het geheel vervangen.
hmm dat ziet er niet goed uit
denk dat je wijk een nodige opfris beurt kan gebruiken
al is je wijk denk ik ook nog niet geupgrade naar docsis 3.1 want je hebt geen OFDM downstream kanaal
Nog geen 1000/50 hier inderdaad. Ik hoop dat de upgrade naar DOCSIS 3.1 positief gevolg gaat hebben voor de ruis maar het zou helemaal mooi zijn als de oorzaak hiervan eerder achterhaald kan worden. Ik heb geen idee wanneer de upgrade gaat plaatsvinden, nog geen bericht van Ziggo ontvangen.
Ik voorzie overigens dat het schrijven van een monitoring script een grotere uitdaging gaat vormen dan bij de Compal CB. In tegenstelling tot de Compal CB, werkt de webserver van de UBC1318 namelijk met PHP en is op de achtergrond niet te zien welke requests gedaan worden om de data op te halen. Het enige wat ik tot nu toe heb kunnen vinden, is dat de downstream en upstream data in JS arrays gezet worden en met een JS function in de tabellen gezet wordt, maar dus geen idee waar de data vandaan komt. Eigenlijk zou ik de PHP source moeten hebben, maar zie daar maar eens aan te komen...
Inmiddels heb ik wel deze git repo gevonden, waarin de UBC1303 ter sprake komt. Dit type komt aardig in de buurt van de UBC1318 qua interface en mogelijkheden. Ik ga eens kijken of ik hier iets mee kan.
Voortgang, ik heb bovenstaande repo tot nu toe niet nodig en ben zelf de cURL requests gaan opzoeken via de browser. Dit was makkelijker dan verwacht, i.t.t. de Compal CB wordt alleen met een statische session ID gewerkt i.p.v. zowel een session ID als een token (die laatste verandert bij elke request). Verder moest ik bij de Compal CB een user agent opgeven in de requests, ook dat lijkt hier geen vereiste.
De requests zijn als volgt, ik vraag alleen bij request 3 de response body op:
De response van request 3 is de hele pagina in HTML. Dat is helaas niet anders gezien het gebruik van PHP. Ook duurt het steevast circa 15 seconden om deze pagina op te vragen. Iets om mee rekening te houden in de monitoring (het modem voldoende tijd geven om de requests te verwerken).
In de response is eigenlijk slechts een regel JS van belang, hierin wordt een variabele gedefinieerd die een JSON string bevat, hierin staat alle downstream en upstream data. De regel begint met: var cm_conn_json. Met een regex moet het tenslotte mogelijk zijn om deze JS variabele met JSON string als value verder te gebruiken in een monitoring script.
Klein gedeelte pretty-printed JSON:
PHP regex 1: preg_match('/PHPSESSID=(.*?);/', $login, $sid);
PHP regex 2: preg_match('/cm_conn_json = \'(.*)\'/', $cm_info_connection, $cm_conn_json);
@privateer Volgens mij was (ben?) jij hier ook naar op zoek.
Ik ga hier later deze week verder mee aan de slag, misschien dat ik over een week al een concept klaar heb voor een monitoring script.
Hey @tobiastheebe , als je even contact met mij opneemt via het e-mailadres in mijn profiel wil ik best even voor je in de wijk kijken wat daar gaande is. Het kan zijn dat je mij eerst als vriend moet toevoegen voordat je mijn e-mailadres kan zien.
Gr. Joey 🙂
@Joey.K Dank voor het aanbod, maar ik laat dit aan een moderator over. Zij hebben inzage in de CMTS en moeten bepalen of het noodzakelijk is om een netwerkmonteur te sturen.
Geen probleem! Mag ook!
Kunnen wij als monteur ook hoor, wij krijgen alleen geen speciale tag op de community, maar dat betekent niet dat wij hier niet kunnen helpen met de technische vragen 😉
Iets eerder dan verwacht heb ik een werkende conceptversie klaargezet voor een monitoring script, hierbij de git repo.
Probeer het gerust zelf uit, houd er wel rekening mee om het script ~20 seconden de tijd te geven. Mijn modem heeft (zoals ik mijn vorige bericht aangaf) 15 seconden nodig om de DS/US-pagina te tonen, echter: your mileage may vary. Let ook op de typfouten die de developers bij Ubee gemaakt hebben: cm_conn_ds_gourpObj en cm_conn_us_gourpObj.
Eerste conceptversie voor Nagios is klaar:
En we hebben weer monitoring + grafieken!
Misschien is de vraag aan de moderators in mijn eerste bericht in dit topic wat ondergesneeuwd door bovenstaande berichten, maar deze vraag staat nog open. Nog steeds veel last van ruis (correctable + uncorrectable errors). Het modem heeft vanmorgen omstreeks 6:25 een reset gekregen van de CMTS (docsDevResetNow), sindsdien is de ruis voornamelijk van 4G afkomstig.
heb nu de gigabit snelheid geen idee of hij de overige downstream kanalen nog gebruikt of dat die backup zijn zie ze wel nog staan
Hi,
Zelf beschik ik nu ook een tijd over een Ubee UBC1318ZG. Modem is in bridgemodus.
Alles lijkt oké op het oog hier qua verbinding, gezien ik sinds kort een monteur over de vloer heb gehad en buitenaf dingen zijn uitgevoerd na een lange tijd contact gehad te hebben met Alex, maar nu heb ik de laatste tijd wanneer ik een herstart maak met het modem (1 min van stroom) krijg ik gelijk op een aantal kanalen oplopende errors op zowel correctables als uncorrectables (zie foto).
De foto is genomen nadat ik het modem 1 min van het stroom heb gehaald en ook de router is 30 minuten van het stroom geweest (dus geen in of uit lopende verkeer, maar het modem is wel online).
Is dit een soort gelijke incident als die van jouw @tobiastheebe ? met name ruis van 4G of iets dergelijke?
@MR_CHIP Bij een actief OFDM-kanaal t.b.v. DOCSIS 3.1, worden de SC-QAM-kanalen nog wel gekoppeld maar niet meer actief gebruikt. Ze kunnen volgens mij nog wel aangesproken worden als failover.
@Ni3k Bij jou lijkt er ook sprake te zijn van instraling (in mindere mate dan bij mij) van 4G uplink (toestel naar mast). Onze modems delen trouwens exact dezelfde kanalenset.
De ruis houdt zich hier sinds ~12:45 weer even 'rustig', uptime is ~9,5 uur:
al denk ik dat hij ze toch gebruikt ik zie wat correctables op de overige downstream kanalen
Er komt nog steeds data op binnen maar die data wordt niet actief gebruikt.
Ik heb even een kijkje genomen, @tobiastheebe Ik zie een klein beetje ruis in het netwerk, maar niet zodanig dat het problemen zou moeten geven op het werken van de diensten. Laten we de aansluiting even samen bekijken, wil je hier een foto van de hoofdaansluiting delen?
Vul de belangrijkste trefwoorden in en vind het topic die past bij je vraag. Onze community zit boordevol kennis.
Start je eigen topic en krijg hulp van anderen. Op de community helpen ervaren klanten je graag op weg.