Hei! Kartoitetaas tilannetta hieman, niin päästään tutkimaan johtuisiko katkeilu mahdollisesti huoltotöistä. Missä päin modeemi sijaitsee tai on sijainnut katkoksien aikaan, ja minä päivinä katkoksia on ollut?
Jos katkoksia esiintyy toistuvasti edelleen, on sinun hyvä kirjata päivämäärät sekä kellonajat ylös, ja kokeilla yhteyden toimivuutta muilla laitteilla, kytkemällä esimerkiksi tietokone ei-sillattuun LAN-porttiin.
@VeraEk kirjoitti:
Hei! Kartoitetaas tilannetta hieman, niin päästään tutkimaan johtuisiko katkeilu mahdollisesti huoltotöistä. Missä päin modeemi sijaitsee tai on sijainnut katkoksien aikaan, ja minä päivinä katkoksia on ollut? Jos katkoksia esiintyy toistuvasti edelleen, on sinun hyvä kirjata päivämäärät sekä kellonajat ylös, ja kokeilla yhteyden toimivuutta muilla laitteilla, kytkemällä esimerkiksi tietokone ei-sillattuun LAN-porttiin.
Katkokset suoraan Unifin alerteista, tällä viikolla eka 8.8.2022 klo 10:06 ja nyt 11.8.2022 klo 11:13 - sitä ennen monta viikkoa ilman ainutakaan häiriötä. Yhteys ei tavitse olla kauaa poikki kun IPsec katkeaa ja silloin alkaa tulla hälyjä mulle tänne lokeihin. Modeemi sijaitsee postinumeroalueella 78850. Modeemissa kaikki portit sillattuna ja veikkaisin että mikä tahansa laite kyllä toimii koska myös ER-X löytää yhteyden heti kun piuhaa käyttää hetkisen irti. Mysteerio on vaan tuo että miksi se lakkaa alun perin välittämästä liikennettä.
Näkiköhön CGA2121:sta lokeja mistä löytyisi jos kaapeliyhteys olisi pätkäissyt eli vika olisi nyt siinä että yhteys ei osaa palautua ulkoisen reitittimen kanssa takaisin tämän tapahduttua. Tosin joudun käymään paikan päällä katsomassa sitä koska siihen en pääse IPsecin kautta käsiksi.
@SINAD kirjoitti:
Katkokset suoraan Unifin alerteista, tällä viikolla eka 8.8.2022 klo 10:06 ja nyt 11.8.2022 klo 11:13 - sitä ennen monta viikkoa ilman ainutakaan häiriötä. Yhteys ei tavitse olla kauaa poikki kun IPsec katkeaa ja silloin alkaa tulla hälyjä mulle tänne lokeihin. Modeemi sijaitsee postinumeroalueella 78850.
Kyseisellä alueella ei ole ollut huoltokatkoja tai muitakaan alueellisia kaapeliverkon häiriöitä, joten niistä tuskin on tässä ollut kyse.
@SINAD kirjoitti:
Näkiköhön CGA2121:sta lokeja mistä löytyisi jos kaapeliyhteys olisi pätkäissyt eli vika olisi nyt siinä että yhteys ei osaa palautua ulkoisen reitittimen kanssa takaisin tämän tapahduttua. Tosin joudun käymään paikan päällä katsomassa sitä koska siihen en pääse IPsecin kautta käsiksi.
CGA2121 asetuksissa on ainakin DOCSIS Event Log, joka näyttää katsomishetkestä taaksepäin, mutta pidemmän aikavälin logeja ei taida pystyä katsomaan tai tallentamaan. Jos kaapeliyhteydessä on kohinaa, joka yhteysongelmaa aiheuttaa, voi modeemin uudelleenkäynnistys olla tarpeen. Jos ongelma toistuu vain reitittimen kanssa modeemin sillatusta portista, mutta samaan aikaan toimii muista porteista suoraan esim. tietokoneelle, niin modeemissa silloin ongelma tuskin on. Jos ongelma toistuu todistetusti usealla laitteella eri porteista, niin sitten voisin välittää tästä viestiä laitevastaaville ja voisimme yrittää toistaa ongelmaa.
Uutta tietoa eilisen katkoksen perusteella:
1. Aiempi lausuntoni ettei DHCP renew palauta yhteyttä on väärä, ER-X reitittimen WebUI:sta paljastui bugi eli renew ajettuna sieltä ei todellisuudessa tee yhtään mitään, mutta renew dhcp interface eth0 ajettuna komentopromptissa palautti yhteyden. Ennen palautusta katsoin kuitenkin leasen tiedot ER-x:ltä ja lease OLI voimassa, eli kyse ei näyttäisi olevan siitä että ER-X ryssisi DHCP:n kanssa nyt jotenkin, se oli siis saanut asianmukaisen leasen aiemmin, eikä se ollut vielä kulunut umpeen.
2. Siltaavaksi asetetun CGA2121:n DOCSIS Event Log on täynnä vaikka minkälaista herjaa, mm. lukuisia DHCP FAILED ilmoituksia - mihis nämä muuten liittyy kun modeemi on laitettu siltaavaksi? Mutta siis joka tapauksessa myös modeemi itsessää herjaa DCHP:stä ja ER-X:n yhteyden katoaminen liittyy jotenkin leasen umpeutumiseen ennen aikojaan. Varsinaisia yhteyden katkeamisia ei lokissa mielestäni ole. Pääsettekö katsomaan noita CGA2121:n lokeja etänä vai pitäisikö minun toimittaa niitä?
Tässä muutama herja mitä lokissa esiintyi:
'No Ranging Response received -T3 time-out'
'MDD message timeout'
'SYNC Triming Syncronization failure - Failed to receive MAC SYNC frame within time-out period'
'Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out'
'DHCP failed - Critical field invalid in response' (näitä on todella paljon)
'DHCP failed - Discover sent; no offer received' (näitäkin todella paljon)
'TLV-11 - unrecognized OID'
'DHCP RENEW WARNING - Field invalid in response v4 option'
'Unicast Ranging Received Abort Response - Re-initializing MAC'
Unifin lokeihin viimeisin yhteyden katkeaminen on kirjautunut eilen 17.8. klo 16:35 mutta tässä on jonkin verran viivettä ennen kuin Unifi laukoo tuon alertin, esim. laitteet voi lähiomaisen päässä bootata ilman että tuota herjaa ehtii tulla. Mutta siis joka tapauksessa joskus klo 16 jälkeen mennyt jumiin. Tällä kohtaa ei DOCIS lokeissa ole mitään muuta erityistä kuin toistuvia DHCP herjoja klo 13 jälkeen.
@SINAD kirjoitti:
2. Siltaavaksi asetetun CGA2121:n DOCSIS Event Log on täynnä vaikka minkälaista herjaa, mm. lukuisia DHCP FAILED ilmoituksia - mihis nämä muuten liittyy kun modeemi on laitettu siltaavaksi? Mutta siis joka tapauksessa myös modeemi itsessää herjaa DCHP:stä ja ER-X:n yhteyden katoaminen liittyy jotenkin leasen umpeutumiseen ennen aikojaan. Varsinaisia yhteyden katkeamisia ei lokissa mielestäni ole. Pääsettekö katsomaan noita CGA2121:n lokeja etänä vai pitäisikö minun toimittaa niitä?
Tarkkaa tietoa DHCP FAILED -ilmoituksien triggeristä en tiedä. Olisiko siksi, että modeemi ei itse liikennettä käsittele? Yhteyden katoamisen syystä on vaikea sanoa näin yhteisön kautta ja sitä olisi tärkeää rajata vielä esim. CGA2121 toisesta LAN-portista, katkeaako yhteys myös silloin muilla laitteilla, jotka ei olekkaan ER-X:n takana? Eli onko yhteysongelmat vain ER-X:n ja siltaavan modeemin välisiä?
Etänä ainakaan täältä Yhteisöstä emme logeja näe, mutta verkkosiantuntijoillamme on kyllä tarvittavat työkalut kaapelimodeemien yhteysongelmien tutkimiseen. Ongelmien jatkuessa myös muista LAN-porteista, on tärkeää ilmoittaa häiriöstä meille. Vain liittymän omistajan tai käyttäjän tekemän häiriöilmoituksen jälkeen voimme tarvittaessa tutkia verkkoliikennetta siltä osin kuin palvelukuvauksen mukaisen toiminnan varmistamiseksi on tarpeen. Eli omien verkkolaitteiden virheilmoituksien/logi -merkintöjen tarkkaa syytä tai niiden liikenteen logimerkintöjä ei tutkita häiriöilmoituksella. Toki niistä voi olla apua yhteysongelman selvittämiseen, eli niistä on tärkeää mainita.
@HenriLie kirjoitti:
Tarkkaa tietoa DHCP FAILED -ilmoituksien triggeristä en tiedä. Olisiko siksi, että modeemi ei itse liikennettä käsittele? Yhteyden katoamisen syystä on vaikea sanoa näin yhteisön kautta ja sitä olisi tärkeää rajata vielä esim. CGA2121 toisesta LAN-portista, katkeaako yhteys myös silloin muilla laitteilla, jotka ei olekkaan ER-X:n takana? Eli onko yhteysongelmat vain ER-X:n ja siltaavan modeemin välisiä?
CGA2121:n lokeissa näkyvät DHCP herjat ajoittuvat samoille päiville jolloin ER-X on menettänyt yhteyden! Eli esimerkiksi tämän kuun 11. päivä ja ja nyt jälleen 17. päivä. Valtaosan ajasta noita herjoja ei siis docis lokeissa ole. Eli kyllähän siellä verkossa nyt jotain pielesäs on koska sekä CGA2121 että ER-X näkevät saman ongelman. CGA2121 lokeissa nuo herjat tulee vähän aiemmalla timestampilla (liekö ne sitten UTC ajassa) mutta joka tapauksessa pian tämän jälkeen on IPsec menee alas ja Unifissa alertti. Nähtävästi yhteys myös palautuisi itsekseen kun odottelisi leasen loppua mutta kaapelissa kun on oikeanlainen pitkä lease niin se ei tapahdu heti. Modeemin perässä ei ole mitään muita laitteita kuin ER-X joten tuota pyytämääsi testiä ei voida mitenkään tehdä.
Mulla on nyt viimeinen kesälomaviikko menossa eli jatkossa ei ole enempää aikaa alkaa selvitellä tätä. Jotain vikaa selkeästi on olemassa mutta jos se ei lähde tällä etenemään niin ei mahda mitään. Täten päätyin tekemään tähän automaattisen yhteyden palauttamisen eli ER-X pingaa 5 minuutin välein Telian gatewayta ja jos se ei vastaa, ajetaan DHCP renew. Eli ei korjata varsinaista vikaa vaan kierretään se. Pääasia että toimii / palautuu takaisin itsekseen ja mun ei tarvitse keskittyä enää selvittelemään näitä.
Ja jos jollakin muulla sattuu olemaan sama ongelma niin tässäpä conffia ER-X:lle, ekana perustetaan scriptifilet:
cd /config/user-data
sudo mkdir scripts
sudo chown root scripts
cd scripts
sudo touch linetest.sh
sudo touch dhcprenew.sh
sudo chmod 0755 linetest.sh
sudo chmod 0755 dhcprenew.sh
Sitten editoidaan linetest.sh sisällöksi:
ping -c 1 -w 1 80.220.240.1 || /config/user-data/scripts/dhcprenew.sh
Ja dhcprenew.sh sisällöksi:
renew dhcp interface eth0
echo >>/home/ubnt/stall.log $(date)
Lopuksi tehdään systeemitason ajastin:
configure
set system task-scheduler task LineTest
set system task-scheduler task LineTest crontab-spec '*/5 * * * *'
set system task-scheduler task LineTest executable path /config/user-data/scripts/linetest.sh
commit
save
exit
Tämä viritys pitäisi kestää myös firmispäivitykset koska kaikki tulee systeemitason conffeihin. Mahdollisista katkoksista kirjataan ylös aikaleima ubnt käyttäjän kotihakemistoon stall.log nimiseen lokitiedostoon. Jos olet tehnyt muun käyttäjän kuin ubnt niin muuta se tuonne scriptiin echo-komennon perään. Conffitiedostojen editoinnissa tarvitaan jotakin editoria, vi lienee oletuksena mutta jos sen käyttö on liian vaikeaa niin nanonkin voi aina asentaa koska EdgeRouterit ajaa suhteellisen täydellistä Linuxia. Vaatii vaan ekana debianin repositoryn määrittelyn, ohjeet saa Googlella.
Havaittiin ettei tuo automaattikorjaus toiminutkaan tositilanteessa ja vika on on tuossa dhcprenew.sh scriptissä. Yritin korjata tuota yllä olevaa postaustani mutta Yhteisö ei näköjään sen muokkaamista enää. Niinpä vähän hölmösti tässä korjaus nyt ihan erikseen
Elikkäs yllä olevassa postauksessani on dhcprenew.sh sisältö väärin:
renew dhcp interface eth0
echo >>/home/ubnt/stall.log $(date)
Selvisi, että TÄMÄ EI TOIMI, koska EdgeOS ei salli tuon renew-komennon ajoa scriptistä käsin tuolla tavoin, vaikka se suoraan komentoriville kirjoitettuna toimiikin. Scripti tuotti ainoastaan virheilmoitusta. Ratkaisuna on ajaa vaadittava komento vyatta-op-cmd-wrapperin kautta, jolloin se toimii (testattu nyt ihan tcpdumpin kanssa että dhcp renew todella tapahtui).
Eli dhcprenew.sh tulee olla:
#!/bin/vbash
/opt/vyatta/bin/vyatta-op-cmd-wrapper renew dhcp interface eth0
echo >>/home/ubnt/stall.log $(date)
Echo-komennon voi myös jättää kokonaan pois jos ei halua tapahtuneita yhteyden palauttamisia lokiin. Jos katkoja on usein tai katkos on pitkä eli tuota palautusta ehditään yrittää lukuisia kertoja niin tuon lokin kirjoittelu kuluttaa laitteen flashia koska merkintä toistuu 5 min. välein. Hyvä idea on pitää se ehkä aluksi mukana ja sitten myöhemmin kun kaikki toimii, ottaa se pois.
--
Muokkaus TeroRe: Muokkasin komentoa käyttäjän pyynnöstä
