Technicolor CGA4236 -modeemin uusin ohjelmistoversio ei aina toimi

Eikö tuon ensimmäisen viestin aikaleimojen perusteella ne eri versiot tule tarjolle pari kertaa minuutissa? Ei siinä odotella, että kaikki sen malliset ovat päivittyneet vaan spammitaan pari kertaa minuutisssa uudelle mallille päivitystä, että kaikki käynnissä olevat ovat varmasti päivittyneet nopeasti. Kaikki eivät vaan ole aina päällä, joten niitä päivityksiä on tarjottava jatkuvasti vaihdellen. 

Näiden mukaan ohjelmistojakelut tehdään ensin portaittain nopeusluokan mukaan, joka näkynee lokeissakin konffitiedoston nimestä (esim. <kaupunki>-m500.cm), jonka jälkeen jakelua laajennetaan seuraavalle mallille. 

Porrastettu ohjelmistojakelun aloitus on itsestäänselvä ja oikea toimintamalli, ja nopeusluokan mukaan tehty porrastus on yksi looginen tapa tehdä se. Sen sijaan se ei, että myös eri laitemallien päivitykset tulevat porrastetusti, vasta kun edellinen malli (tai edelliset) on kaikissa, tai lähes kaikissa, nopeusluokissa lisätty jakeluun.

https://yhteiso.telia.fi/kiinteae-netti-8/technicolor-cga4233-uusin-ohjelmistoversio-36368

Nyt saimme väliaikatietoja aikatauluista. CGA4233 modeemit on tarkoitus päivittää toukokuun loppupuolella. Tällä hetkellä CGA2121 modeemeista m50 nopeusluokalle on tarjolla uusi softa. Uusia nopeusluokkia lisätään vaiheittain ja pyritään saamaan uusi softa tarjolle kaikille nopeusluokille kesäkuun loppuun mennessä. CGA4236 asetetaan automaattipäivitykseen CGA2121 päivitysten jälkeen.

Myös tässä ketjussa:

CGA2121 modeemit ovat edelleen automaattipäivityksessä. Verkossa on edelleen runsaasti CGA2121 modeemeja vanhalla ohjelmistoversiolla. Kun nämä modeemit ovat päivittyneet, aloitetaan CGA4236 modeemien päivitykset vaiheittain. Tämän hetken aikataulumme on, että CGA4236 modeemit toimisivat uudella ohjelmistolla syksyn aikana.

Helpoimmalla varmaan pääsee, kun ostaa vaan sen Ciscon laitteen omaankin päähän kaapelia. Meni tosiaan tuo nopeusluokan mukaan jako ohi. Ei nyt oikein omaan tajuntaan uppoa, että samalle laitteelle tulee täysin eri päivitys netin nopeuden mukaan ollenkaan, mutta onneksi ei tarvitsekaan. Ilmeisesti kaapelissa laite itse hidastaa netin maksetulle nopeudelle päivityksen mukaan eikä sitä tehdä Telian päässä? 

Samalle laitemallille ei tule eri ohjelmistoversioita nopeusluokan perusteella – versio on kaikille sama. Porrastus tehdään nopeusluokan mukaan, jotta verkon kuormitus pysyy hallittuna ja jotta mahdollisesti buginen versio ei jumita kaikkia laitteita kerralla. Jakelu voitaisiin yhtä hyvin porrastaa myös esimerkiksi IP-osoitteiden perusteella, mikä on yritysverkoissa yleinen tapa ajaa ohjelmistopäivityksiä pienemmissä erissä. Päivityksiä ei siis jaeta kaikille laitteille yhtä aikaa heti alusta alkaen.

Tuo on kyllä totta, että helpoimmalla pääsisi toisella laitteella, mutta katsotaan nyt tämä loppuun asti Telian laitteen kanssa — mitä keksivät. 😃 Vasta runsaan kuukauden ollut kaapelinetti käytössä, johon vaihtui VDSL:stä. 

Eli voisit teorissa ottaa aspaan yhteyden, hidastaa nettisi nopeuden siihen luokkaan jolle päivitys on jo tarjolla, päivittää laitteen ja sitten ottaa taas yhteyttä, että et halunnutkaan hidastaa. Unicastinahan tuo tosiaan tuntuu menevän eikä multicastina, kuten myös kuvittelin. Sillä verkko rasittuisi paljon vähemmän ja kaikki sillä hetkellä päällä olevat halutun ryhmän laitteet saisivat päivityksen samanaikaisesti. Multicastina olisi tosiaan ollutkin järkevää vaihtaa mitä tarjotaan useammin kunhan joku toteaa laitteiden jatkavan toimintaansa ongelmitta ja merkkaa sen mallin ja nopeuden toimivaksi jatkoa varten. Oikeassa olit, ei ole mitään järkeä. Vähän kuin suoraa TV-lähetystä katsottaisiin kuin suoratoistoa ja jokainen katsoja lataisi oman lähetyksensä erikseen kaistaa kuluttaen.

Nämä olivat erittäin hyviä pointteja. Laitoin nyt uudelleen viestiä kaapeliverkosta enemmän tietäville, joten palaamme näihin kysymyksiin heti kun saamme vastausta.

Telialla on mahdollisuus päivittää kaikki kriittisten haavoittuvuuksien piiriin kuuluvat kaapelilaitteet kerralla, vaikka laitteet olisivat eri mallisarjaa keskenään. Jatkuvat päivitysajot tehdään kuitenkin mallisarjakohtaisesti pienemmissä erissä, koska pakottavaa aikataulua näiden ajamiseen harvemmin on ja päivityserät pysyvät kohtuullisen kokoisina.
 

Tämä kyseinen virheilmoitus nousee esiin kaikille modeemeille, joihin ohjelmistoversiota ei voida yhteensopimattomuudesta johtuen asentaa. Päivitykset ovat kuitenkin luonteeltaan sellaisia, että laitteet eivät käynnisty uudelleen päivittyäkseen, vaan laite tutkii päivitysjonon uudelleenkäynnistyksensä yhteydessä. Tämä taas johtaa siihen, että nuo virheet lokitiedostoihin nousevat, mutta syy, miksi päivitysjonoon on menty ovea koputtelemaan johtuu jostain muusta kuin tarjolla olevasta päivityksestä. Laitteelle siis tarjotaan päivitystä uudelleenkäynnistyksen yhteydessä ja asentaa sen, mikäli sopiva oli tarjolla. 
 

Nyt varmaankin jo tiedetään, mikä on se varsinainen muu juurisyy?

1. Koko prosessi alkaa noin puoli tuntia ennen epäonnistuneen ohjelmistopäivityksen aikaleimaa DOCSIS-lokeissa DHCP-/CMTS-virheillä. Tällöin siltaavan Technicolorin yhteys katkeaa Googlen (tai mikä tahansa ulkoinen "always on" IP jota pingaa) ja Telian DNS-palvelimiin sekä Telian gatewayhin, eli internet-yhteys on poikki. Minulla on jatkuva yhteyden monitorointi päällä ja se data on verrattavissa suoraan DOCSIS-lokeihin. Technicolor käynnistyy itsestään, ja sen käynnistysvaiheessa laitteelle tarjotaan ohjelmistopäivitystä.

2. Epäonnistunut ohjelmistopäivitys on viimeinen tapahtuma, joka jää DOCSIS-lokiin DHCP-/CMTS-virheiden jälkeen. Tämän jälkeen Technicolor jää tilaan, jossa se ei enää lähetä tai vastaanota mitään liikennettä. Modeemi ei saa DHCP-palvelimelta IP-osoitetta ilman manuaalista uudelleenkäynnistystä. Jotkut ovat kiertäneet ongelman renew-skriptillä, joka uusii DHCP-leasen.

Omalla kohdallani, koska haluan selvittää (=Telian selvittävän) ongelman juurisyyn ennen purkkaratkaisuja, yhteys palautuu vasta manuaalisen buutin jälkeen, jolloin IP-osoite haetaan jälleen DHCP-palvelimelta. Normaalisti se uusiutuisi T1-renewal-ajassa (50 % eli 6 h 12 tunnin leasesta). Kerran leasen uusiminen oli onnistunut ilman buuttiakin T2-rebindin kohdalla (87,5 % 12 tunnin leasesta), mutta yhteys katkesi pian uudelleen ja toimi vakaasti vasta manuaalisen buutin jälkeen. Tämän voisi edelleen testata niin, ettei päivitystä tarjottaisi, jäisikö Technicolor yhteydettömään tilaan vai ei.

Oletko saanut lisätietoa tai väliaikatietoa jättämääsi häiriöilmoitukseen liittyen? Oletko saanut tiketin kirjaamisen jälkeen tietoosi vikailmoituksesi yksilöivää tunnusta? 

Uskon, että sinun modeemin ja meidän verkkolaitteiden lokien perusteella on hyvinkin mahdollista selvittää mikä on aiheuttanut yhteyden alkuperäisen katkeamisen, sekä sen miksi yhteys ei palaudu toimintaan ilman modeemin uudelleenkäynnistystä. 

Tottakai se on palveluntarjoajan velvollisuus varmistaa mikä on ongelman taustalla, sekä tarvittaessa korjata ilmoitettu ongelma mikäli se johtuu palveluntarjoajan osuudesta.

Näetkö lokeista kyseleekö modeemi/reititin verkko-osoitetta palvelimelta normaalisti sen jälkeen, kun yhteys on noussut uudelleen ylös? 

Minua vaivaa (epäsäännöllisesti) täsmälleen tämä sama ongelma, ja olen niitä, jotka palauttavat yhteyden renew-scriptillä. Tosin olen nyt huomannut, ettei pelkkä renew yhteyttä palauta. Reitittimeni näyttää yrittävän sitä muutaman kerran ja lähettää lopulta DHCP discover -komennon. Johtunee siitä, ettei se tuossa tilassa löydä edes DHCP-palvelinta uudistaakseen IP-osoitteen.

Modeemini (Technicolor CGA4236) on siltaavana, mutta tällöin DOCSIS-lokeja ei pysty näkemään lainkaan, ne näkyvät vain reitittävässä tilassa. Onnistutko sinä jotenkin saamaan ne esiin siltaavalla modeemilla? En ole tämän puutteen vuoksi kyennyt yhdistämään firmiksen päivitysyrityksiä yhteyden katkeamisiin.

Sain normaalisti 6.10. tekstiviestin jossa ilmoitettiin, että häiriöilmoitukseni oli siirtynyt asiantuntijan käsittelyyn ja viestissä oli myös häiriön yksilöivä tunnus. Oletin, että asiantuntija vertaisi lähettämiäni lokitietoja verkon lokeihin tai ottaisi yhteyttä viestissä mainitusta numerosta lisätietoja varten.

Asian etenemisestä ei kuitenkaan kuulunut mitään. Kun yritin lähettää tekstiviestillä lisätietoja, sain automaattivastauksen: “Virheellinen palvelupyyntö”. Aiemmissa viesteissä on mainittu, että vastausmahdollisuus on voimassa 2 viikon ajan, mutta tässä sitä ei ollut. Ehkä ilmoitus on mennyt suoraan ö-mappiin ja tiketti on suljettu kaikessa hiljaisuudessa ilman erillistä ilmoitusta.
 

Yhteys palautuu normaaliksi vain manuaalisen buutin jälkeen. Koska yhteys tällöin aina toimii, IP-osoitekin saadaan luonnollisesti normaalisti. DOCSIS-lokien tarkasteleminen tässä vaiheessa vaatisi kuitenkin laitteen vaihtamista ja pitämistä reitittävässä tilassa, jotta DOCSIS-loki olisi näkyvissä — siltaavassa tilassa ne on piilotettu. Tätä ei jokaisen katkoksen kohdalla jaksaisi erikseen tehdä, kun sen on jo aiemmin tehnyt ja lokit lähettänyt. Eli katkoksen jälkeen reitittävä tila päälle, DOCSIS-lokitiedot talteen, ja laite takaisin siltaavaan tilaan. Sen jälkeistä DOCSIS-lokia ei oikeastaan enää tarvita, kun yhteys kerran palautuu.

Toisella laitteella tuossa välissä mm. tcpdumpilla ja tsharkilla DHCP-liikenne näkyy kuitenkin tässäkin tilanteessa, ja nämä jäävät minulla talteen.

Olen tehnyt niin, että kun katkos tulee, vaihdan hetkeksi reitittävään tilaan, otan lokit talteen ja palautan sitten siltaavan tilan. Kun yhteyttä monitoroi erillisellä laitteella, niin DOCSIS-lokeja voi sitten verrata sen tuottamien lokien aikaleimoihin.

Ahaa, kiitos! Minulla on ollut virheellinen käsitys, että kun vaihdan siltaavasta reitittäväksi ja modeemi käynnistyy uudelleen, myös vanhat lokit katoavat siinä kohden. Ilmeisesti siis eivät, joten täytyypä kokeilla tuota seuraavalla kerralla, kun huomaan katkoksen tapahtuneen. Reitittimen ja modeemin lokeja on sitten helppo vertailla aikaleimojen suhteen.

Laittaisitko tuon yksilöivän tikettinumeron yksityisviestillä ​@Yhteisötiimi käyttäjälle? Saamme siten varmistettua miten tiketin käsittely on edennyt. Tyypillisesti vikailmoituksen käsittelyn yhteydessä asiakkaalle lähetetään vähintään kaksi teksitiviestiä. Yksi vikailmoituksen käsittelyn aloituksen ja toinen käsittelyn päättymisen yhteydessä. Siinä välillä voi sitten olla muita viestejä, jotka sisältävät ohjeita tai lisätietoja tms. Käsitykseni mukaan yhteysnumeroon lähtee pakosta jonkinlainen kuittaus, kun vikailmoitus suljetaan järjestelmässä.

Olisi hyvin poikkeuksellista, että vikailmoitus olisi kuitattu kiinni ilman minkäänlaista viestiä tai ohjeistusta, sillä vastaava toimintamalli on ehdottoman kiellettyä juurikin sen aiheuttaman heikon asiakaskokemuksen vuoksi. 

Ennen tikettinumeron kautta tarkistamista voisin arvata, että tiketin käsittelijällä on selvitykset edelleen menossa, mutta hän ei ole hoksannut tai muistanut ilmoittaa sinulle käsittelyn viivästymisestä. Muistelen, että asiakas voi saada virheilmoituksen, kun hän antaa viesteitse lisätietoa joka ylittää tietyn merkkimäärän. Tämä asiakkaan lähettämä viesti menee kuitenkin onnistuneesti asiantuntijalla auki olevalle tiketille virheilmoituksesta huolimatta. Varmistetaan kuitenkin tikettinumeron avulla tarkemmin mitä on tapahtunut. 

Me voidaan verrata omia lokeja sinun havaintohin ja varmistaa miten liittymään kytketty/kytketyt laitteet kyselevät verkko-osoitteita yhteyden katkon jälkeen. Tähän tarvitaan joissain tilanteissa esimerkkejä tarkemmista aikatauluista, mitkä varmasti asiantuntija saa sinulta kysymällä. Voit laittaa samaan yksityisviestiin myös näitä esimerkkejä ja lokeja, niin saamme ne sitä kautta välitettyä vikailmoitusta käsittelevälle asiantuntijalle. 

Yksityisviesteihin ei voi liittää tiedostoja, ja myös muotoilut, kuten taulukot, katoavat. Laitoin kuitenkin tämän kuukauden downtime-tiedot.

Toivoisi, että Telian asiantuntijat pystyvät hoitamaan omat työtehtävänsä alusta loppuun saakka itsenäisesti ilman “holhoamista” (tikettinumero laitettu). 😉 Selvitystyö saattaa tosiaan olla vielä kesken, sain oheisen viestin sähköpostiini eilen.

Olisihan sitä muutakin elämää kuin tutkia nettiyhteyden pätkimisiä. 😄
 

Sain varmistettua tikettinumeron avulla miten vikailmoitustasi on käsitelty. Se on saapunut meille 6.10 ja se on vastoin ohjeistusta suljettu 7.10 ilman kuittausta tai viestiä siitä, että vikailmoituksen käsittely on lopetettu/päättynyt. Vein palautteen eteenpäin aiheesta, sillä tämä ei todellakaan ole, eikä saa olla tapa millä vikailmoituksia käsitellään. Asiakasviestintä on avainasemassa vianhoidon aikana, sillä on meidän vastuullamme tiedottaa asiakasta selvityksen edistymisestä, kun hän on ensin meille raportoinut palvelussa esiintyvästä virheestä. 

Sain käsityksen, että ilmoittamaasi ongelman tutkintaa jatketaan nyt toisella vikailmoituksella ja tulet saamaan sen sulkemisen yhteyssä viestin tutkinnan tuloksesta. 

Sain tästä viestinkin tänään. Eli kun tämän yhdistää kertomaasi, niin "seurantajakso" on ollut todellisuudessa yhden vuorokauden mittainen!
 

Hei, vikailmoituksesi on käsitelty. Ohjelmistopäivityksien jaossa ei olla havaittu mitään poikkeavaa. Seurantajaksomme mukaan kaapelimodeeminne on toiminnassa ja pysynyt linjalla hyvillä linja-arvoilla.Käynnistäthän tarvittaessa laitteet uudelleen ja varmistat liittymäsi toimivuuden. Ongelman jatkuessa lähetä tekstiviesti: "Kaapelihäiriö <uusi tikettinumero> + lisätiedot" numeroon 18100 niin jatkamme vian käsittelyä. Vastausmahdollisuus on voimassa 2 viikon ajan. T. Telia

Alan vakuuttua siitä, että todellisuudessa tämä laaja ongelma Telian kaapeliverkossa (ainakin Technicolorin laitteilla) on erittäin hyvin teillä tiedossa, jonka takia sitä ei ole enää tarpeenkaan tutkia. Mutta ei sitä haluta asiakkaillekaan kertoa, ettei ongelmaan ole olemassa ratkaisua, koska asiaan perehtymättömät ostavat edelleen 80 euron hintaista laitetta, jolla netti ei tule koskaan olemaan vakaa. Reklamaation kautta sitten vain hyvityksiä katkosten keston perusteella...

Tämän 6.10 jätetyn vikailmoituksen käsittely oli tosiaan kestänyt sen noin yhden vuorokauden ajan. Vikailmoituksen sulkeminen ilman asiakkaalle viestimistä on poikkeuksellista ja typerää toimintaa. Pahoittelen tätä omasta puolestani. 

Siitä on vuosia aikaa, kun itselläni oli meidän kaapeliverkon laajakaista käytössä. Tuolloin modeemina toimi CGA2121 -modeemi. En tuon yhteyden kanssa havainnut aikana pätkimistä. Ainakaan sellaista katkomista minkä taustalla olisi ollut jotain muuta kuin kaapeliverkon perinteistä kohinaa. 

Tottakai voit hankkia toisen valmistajan eurodocsis 3.0 kaapelimodeemin liittymällesi, jos koet sen parantavan yhteyden vakautta. Mikäli ongelma todella johtuisi ohjelmistopäivitysten virheellisestä jakelusta, niin katkoksien tulisi päättyä kun liittymässä on käytössä jokin muu kaapelimodeemi kuin CGA2121, CGA4233 tai CGA4236. Itse asiassa tuon CGA4236 -modeemin myyntihinta on tällä hetkellä normaalisti noin 160€. Laitetta myydään rajatusti taloyhtiökohteisiin alennettuun 80€ hintaan. 

Se mikä minua kuitenkin tässä edelleen jäi vaivaamaan on se, että mikä on havaittujen katkojen todellinen juurisyy, jos ongelma ei kaapeliverkon asiantuntijan mukaan liity ohjelmistopäivityksen virheelliseen jakeluun. Koska jokin syyhän täytyy olla joko laitteessa, liittymässä tai alueen verkossa yhteyden pätkäisylle. 

Onneksi en itse ole maksanut laitteesta. Technicolorista 160€ on jo niin hulppea hinta, että mikä tahansa muu laite on parempi valinta. Se vasta harmittaisikin. 😅

Vahvin veikkaus on laite ja/tai edelleen ne CMTS-virheet. Technicolor ei palaudu normaaliin toimintaan, kun yhteys jostain syystä katkeaa ja laite buuttaa tai “kaatuu”. Ei ole mitenkään todistettu (ei vakuuta ilman selkeää näyttöä), etteikö buutin aikana tarjottu päivitys mahdollisesti estäisi yhteyden normaalia palautumista.

Signaalitasot ovat olleet kunnossa – ainakin ennen katkosta ja heti sen jälkeen. Katkoksen hetkeltä jatkuva reaaliaikainen seuranta asiakkaan päästä on käytännössä mahdotonta ilman erikoisjärjestelyjä. En ole varma, näkyykö tilanne teilläkään, jos sitä ei seurata jatkuvasti ja tarkasti myös juuri katkoksen tapahtuessa.

Olen lähettänyt tiedot neljästä eri katkoksesta ja niiden kestosta 5 minuutin tarkkuudella, mitattuna yhteyden puuttumisena gatewayhin sekä DNS-palvelimiin (Telia x2 ja Google). Aiempien katkosten monitoroinnissa DHCP-palvelimen pingaus ei vielä ollut mukana, mutta nyt myös se on tallentunut – sekä erikseen että osana tsharkilla otettua packet capturea. Näin näkee, vastaako verkossa mikään katkoksen jälkeen, ja onko IP-osoitteen saaminen ylipäätään mahdollista.

Seuraavaksi testaan automatisoitua modeemin power cyclea älypistorasialla, kun packet loss on ollut 100% 10 minuutin ajan. 😃

Se on kieltämättä kova hinta modeemista, mutta valitettavasti nuo kaapelimodeemit ovat aina olleet aika arvokkaita laitteita. Varsinkin muihin kiinteän laajakaistan liittymätyyppeihin verratttuna. Tuotakin arvokkaampia ovat tietenkin 5G-verkon laadukkaat reitittimet.

Jos oikein muistelen niin meiltä sai joskus aikoinaan kaapelimodeemin samaan hintaan kuin ADSL/VDSL2 -modeemin tai Ethernet -reitittimen. Tuolloin normaalihinta taisi olla 60€ paikkeilla ja rajoitetustí taloyhtiökohteisiin kaikkia laitteita myytiin 30€ hintaan. Kovasti ovat hinnat noista ajoista muuttuneet. Usein tarjous edellytti määräaikaista sopimusta liittymästä. 

Hyvin vaikea varmuudella sanoa, kun ei näe mitä katkon aikana tapahtuu. Kaapeliverkon viankorjauksen yhteydessä tietämykseni mukaan voidaan jälkikäteen katsoa myös muiden samalla verkkolaitteella toimineiden liittymien toimintaa ja verrata vikailmoituksen käsittelyn kohteena olevan liittymän toimintaa näihin muihin liittymiin. Verkosta johtuvien häiriöiden tulisi näkyä lähtökohtaisesti myös näissä muissa liittymissä. 

Tuolla automaattisella buutilla varmasti down aikaa saadaan kohtuullistettua. Se ei kuitenkaan ole ratkaisu, vaan lähinnä lääkettä vaivoihin. 

Nimenomaan. Kunhan tuota saan testattua, niin aikaa voi säätää vaikka kuinka lyhyeksi, mutta eihän se katkoksia poista, ainoastaan lyhentää downtimen kestoa. Toimiessaan on lisäksi automatisoitu ratkaisu. Ei tällaista pitäisi joutua tekemään, mutta tuo nyt on halpa testi verrattuna esim. Fritz!Boxin hankintaan.

On täällä muuten samasta rasiasta toiminut DNA Welho -kaapelinetti vuoteen 2016 asti ongelmitta, kunnes siirtyi Telialle ja VDSL2-tekniikkaan. Nyt on palattu Teliankin kanssa kaapeliin, mutta ei kovin hyvin tuloksin. 😉  

Jos kalliit muovipurkit halpamerkeiltä alkaa potuttaan tarpeeksi niin aina on vaihtoehtona eBaysta esim käytetty Cisco EPC3208 39€ + 16€ rahdit Saksasta. Ikivanha 3.0 max 450Mbit laite, mutta bonuksena on 2x lankapuhelimelle paikat, että saa soiteltua sekä VoIP-puheluita että kaapelipuheluita, mitä sitten ikinä lienevätkään. Noissa on kuulemma toimintavarmuus ihan eri luokkaa, mutta toki varmaan kannattaa vähän uudempiakin katsella. 

Jep. Itse katselen kyllä sitten jotain uudempaa, mutta tuokin olisi parempi vaihtoehto pelkän toimintavarmuuden kannalta. 

Hei ​@Yaria muutama viikko on vierähtänyt eteenpäin. Oletko edelleen havainnut yhteydessä pätkimistä? Vai onko automaattinen / säännöllinen buuttailu pitänyt jumit ja virheilmoitukset loitolla? 

Marraskuussa ei ole yhteys pätkinyt kertaakaan. Tuo aiemmin kertomani systeemi on ollut nyt “toimintavalmiudessa”. Kun kaksi erillistä kertaa ping packet loss gatewayhin on 100%, Grafana alert lähettää pyynnön Python webhook-serverille, joka suorittaa Linux-skriptin. Skripti lähettää älypistorasian API:in ensin relay off -käskyn ja 10 sekunnin kuluttua taas relay on -käskyn, eli tekee modeemille power cyclen. Käytännössä tällaista tilannetta ei ole vielä tullut, mutta simuloituna se toimii kuten oheisessa kuvakaappauksessa.

 

Modeemin DOCSIS-lokeja en ole edes tarkistanut, mutta aiemmin niissä havaitut CMTS- ja DHCP-virheet todennäköisesti heijastuvat myös säännöllisenä, jatkuvana ja “ennustettavana” ping packet lossina, kuten alla olevassa kuvakaappauksessa. Ei ole täysin tervettä, jos packet lossia esiintyy vain DHCP-palvelimiin, mutta ei mihinkään muihin kohteisiin, kuten gatewayihin (samassa verkossa kolme eri gatewayta), Telian DNS-palvelimiin (x2) tai ulkoisiin kohteisiin, kuten Google DNS (8.8.8.8).