Skip to main content

Kaapelimodeemin nettiyhteys jumiutuu jatkuvasti!

  • June 3, 2025
  • 83 kommenttia
  • 2446 katselukertaa

Näytä ensimmäinen kirjoitus

83 kommenttia

Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • July 28, 2025

Ensimmäinen automaattinen yhteyden korjaus skripti on valmis ja EdgeRouter ajaa skriptin 5 minuutin välein aina uudelleen, jos reitittimen ARP taulusta puuttuu Telian yhdyskäytävän MAC numero, niin DHCP:llä saatu IP-numero vapautetaan ja 2 sec jälkeen kysytään DHCP:llä uudestaan IP-numeroa.

Skripti vaatii EdgeRouter:n seuraavat asetukset. IP-numeron paikalla täytyy olla oman Syslog serverin osoite.

set system syslog host 192.168.50.2
set system syslog facility all level err
set system syslog facility user level debug

Tämän jälkeen asetukset näyttää tältä:

amon@EdgeRouter-Pro-8-Port# show system syslog
host 192.168.50.2 {
facility all {
level err
}
facility user {
level debug
}
}
[edit]
amon@EdgeRouter-Pro-8-Port#

EdgeRouter:ssa 5 minuutin välein ajettava skripti:

# /config/scripts/arpcheck-eth0.sh script version v0.1
#
# The ISP cable modem's automatic firmware update attempts are
# once or twice a week and the ARP traffic always gets stuck.
# The EdgeRouter's ARP traffic no longer receives responses
# from the ISP when the ARP traffic stops working on a bridged
# connection. This script will fix the connection problem
# automatically. DHCP release and renew fix the ARP problem.
#

# Add system PATH explicitly for cron
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Network interface to check
ETH="eth0"

# Syslog tag for all logger messages
SYSLOG_TAG="arpcheck"

# External IP to test Internet connectivity (Google DNS)
TARGET="8.8.8.8"

# Get current gateway IP for the interface
GATEWAY=$(/sbin/ip route | awk "/via/ && /$ETH/ {print \$3; exit}")

if [ -z "$GATEWAY" ]; then
logger -p user.warning -t $SYSLOG_TAG "$ETH port GATEWAY IP: NO_GATEWAY"
exit 1
else
logger -p user.debug -t $SYSLOG_TAG "$ETH port GATEWAY IP: $GATEWAY" # Debug line
fi

# Get ARP entry for the gateway IP
MAC=$(/usr/sbin/arp -an | awk -v gw="$GATEWAY" '$2 ~ gw {print $4}')
logger -p user.debug -t $SYSLOG_TAG "$ETH port GATEWAY MAC: $MAC" # Debug line

# Check for missing or incomplete ARP
if [ -z "$MAC" ] || [ "$MAC" == "(incomplete)" ]; then
logger -p user.warning -t $SYSLOG_TAG "$ETH port: ARP table check FAILED!"

# Uncomment the lines below to re-request DHCP IP when needed
/usr/bin/logger -p user.warning -t $SYSLOG_TAG "$ETH port: DHCP release..."
/usr/bin/sudo /sbin/dhclient -r $ETH
sleep 2
/usr/bin/logger -p user.warning -t $SYSLOG_TAG "$ETH port: DHCP renew..."
/usr/bin/sudo /sbin/dhclient $ETH

else
logger -p user.debug -t $SYSLOG_TAG "$ETH port: ARP table check OK!" # Debug line
fi

# Test Internet connectivity via $ETH
if /bin/ping -c 2 -I $ETH $TARGET > /dev/null 2>&1; then
logger -p user.debug -t $SYSLOG_TAG "$ETH port Internet connection test OK: Ping to $TARGET successful." # Debug line
else
logger -p user.err -t $SYSLOG_TAG "$ETH port Internet connection test FAIL: Ping to $TARGET failed."
fi

Skripti ei tallenna mitään tietoa EdgeRouter:n muistiin ja sähköposti ominaisuus oli pakko jättää kokonaan pois ja se olisi pahimmassa tapauksessa voinut rikkoa EdgeRouter:n toiminnan pysyvästi, koska se olisi vaatinut liikaa kajoamista EdgeRouter:n ohjelmistoon. Syslog ominaisuus on valmiiksi EdgeRouter:ssa, joten sen käyttämiselle ei ole estettä. EdgeRouter:n Syslog liikenne kulkee porttinumerolla 514.

Asensin Visual Syslog Server:n asetuksilla:

Automaatio on siis nyt viritetty toimimaan, mutta se on vasta testissä, eli täyttä varmuutta skriptin toiminnasta ei vielä ole. Vaati aika paljon kokeilua ja virheiden etsimistä, että pääsin edes tähän vaiheeseen. Olen jo saanut kerättyä Syslog dataa. Aikaa meni, myös paljon, että selvisi tarkalleen miksi Telian kaapelimodeemiyhteys jumiutuu säännöllisen epäsäännöllisesti kerran tai kaksi viikon aikana. Vaihtoehtoja on kaksi Telian modeemi tai Telian yhdyskäytävän laite. Epäilisin modeemia, koska Telia käyttää mac-numeron perusteella ciscon laitetta.

Telian yhdyskäytävän IP tai MAC osoitteiden vaihtumisella ei ole vaikutusta skriptin toimintaan. Skripti lähettää tiedot Syslog serverille, joka tallentaa kaikki tiedot palvelimen kovalevylle. Syslog serverin voi asentaa vaikka Linux PC:lle tai Windows PC:lle. Eri vaihtoehtoja siis löytyy Syslog servereistä ja osa on varmasti maksullisia.

Vasta seuraavan kerran, kun yhteys jumiutuu, minun pitäisi nähdä Syslog serverillä varoituksia siitä, kun ARP liikenne on jumiutunut ja DHCP:llä saatu IP-numero vapautetaan. Katkoksen ajan EdgeRouter:n eth1 portti hoitaa internet yhteyden liikennettä.

amon@EdgeRouter-Pro-8-Port# show load-balance
group G {
exclude-local-dns disable
flush-on-active enable
gateway-update-interval 20
interface eth0 {
route-test {
initial-delay 1
interval 10
type {
ping {
target 8.8.8.8
}
}
}
weight 50
}
interface eth1 {
failover-only
route-test {
initial-delay 1
interval 10
type {
ping {
target 8.8.8.8
}
}
}
weight 50
}
lb-local enable
lb-local-metric-change disable
}
[edit]
amon@EdgeRouter-Pro-8-Port#

Seuraavan kerran, kun ARP liikenne jumiutuu siltaavalla puolella (eth0), niin yhteys pitäisi siirtyä hetkeksi reitittävälle puolelle (eth1), jos reitittävä puoli toimii, katkoksen vaikutus on vähäinen. Katkos voi tulla ohjelmien kanssa, jotka vaatii tarkkaa jatkuvaa kirjautumisyhteyttä. IP ja MAC osoitteen vaihtumien voi siis aiheuttaa katkoksen käytössä olevissa ohjelmissa / yhteyksissä, jos yhteys vaatii tarkkan jatkuvan IP ja MAC osoitteen. 5 min sisällä yhteys palaa takaisin eth0 portille, jos EdgeRouter:n tehty skripti toimii oikein.

Mietin, että pyrkiikö Telian Technicolor CGA4236TCH1 kaapelimodeemi katkaisemaan yhteyden tarkoituksella firmware päivitysyrityksen ajaksi, mutta yhteys ei palaudu päivitysyrityksen jälkeen toimivaksi siltaavalla puolella. Siltaavaa puolta käytetään juuri firmware päivitykseen, eli katkos saattaa olla tarkoituksellinen, mutta yhteyden palautuminen takaisin toimivaksi ei toimi, jos siltaus on tehty IPv4 MAC Passthrough toiminnon avulla. Tämä asia olisi hyvä tietää ja sen voisi huomioida siinä, kuinka tiheästi skriptiä ajetaan EdgeRouter:ssa. Tämä voi olla asia johon edes Telia ei tiedä vastausta ja modeemin valmistaja on ainoa, joka voi tietää vastauksen tähän. Saattaa olla, että ajastuksessa pitäisi huomioida firmware päivityksen mahdollinen kesto. Mitään pävitystä ei ole vielä tullut, eli kaikki on pelkkiä yrityksiä. Tämä saattaa, myös selittää Telian modeemin käyttäytymisen ja muiden operaattoreiden modeemit voivat toimia samalla tavalla, jos pävityksen hoitaa operaattori itse. Tästä ei vaan löydy mitään tietoa kovin helposti.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • July 28, 2025

Itse käytän tarkemman EdgeRouter:n konfiksen tekemiseen PuTTY terminaali ohjelmaa ja Telnet yhteyttä. EdgeRouter laitetta voi hallita UISP serverillä tai selaimella, mutta kumpikaan ei toimi, jos pitää tehdä tarkempaa konfiguraatiota, eli SSH tai Telnet yhteys on silloin pakollinen.

Sähköpostin lähetyksen voin saada tehtyä virtuaaliseen UISP palvelimeen, joka toimii Ubuntu:ssa ja sen ominaisuuden tekemistä EdgeRouter:n sisään ei kannata edes harkita, koska pelkkä yritys voi rikkoa EdgeRouter:n pysyvästi. Tekemäni skriptin kanssa sai olla, myös tarkkana, mutta ChatGPT opasti minua siinä ja sain siivottua omat skriptin raakileet pois EdgeRouter:n muistista. Joutuu siis olemaan tarkkana, koska yksi virhe voi rikkoa EdgeRouter:n pysyvästi ja siihen ei laitteen kyljessä oleva reset nappi enää auta.

Technicolor modeemin tallentaa DOCSIS lokia GMT ajassa ja syslog serveri suomen ajassa. Kummankin kellot on synkronoituvat automaattisesti oikeaan aikaan. Tällä hetkellä aika ero on 3 h. Kahta lokia vertaamalla näen mitä oikeasti tapahtuu, kun testi etenee ja ARP liikenne lakkaa uudelleen toimimasta. Minun veikkaus on, että modeemin firmware päivityksen aikana ARP liikenne lakkaa toimimasta. Nyt täytyy odottaa seuraavaa kertaa ja katsoa toimiko kaikki lokien mukaan juuri sillä tavalla, jota epäilen.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 4, 2025

Taas tuli lisää ongelmia, eli toinen PC:n virtalähde hajosi. Ensin hajosi serverin virtalähde ja nyt hajosi pelikoneen virtalähde. Virtalähteen kunnostus on vaikeampi, koska ei ole sopivaa kolvia. Tehovirtalähteen piirilevyt imee paljon lämpöä, koska folion pinta-ala on suuri ja osat voi, myös olla kookkaita. Tavallinen elektroniikka kolvi ei siis riitä lämmittämään tinaa. Hajonneen virtalähteen paikalla on nyt toinen virtalähde. Hajonneesta virtalähteestä hävisi kaikki jänniteet ja siinä meni mahdollisesti, jokin sisäinen suojaus päälle, eikä virtalähde suostu käynnistymään edes testerillä, joka tekee oikosulun kahden pinnin välille (pakotettu power on tila). Virtalähteen tuuletin voi pyöriä kerran maks 60 sekunttia ja sammuu.

Reitittimen valmistaja oli julkaissut uuden firnwaren koko Ubiquiti EdgeRouter tuote sarjalle. Ulkoasua on muokattu UniFi tuote sarjan suuntaan. Uusi firmware on v3.0.0. Minun tekemät skripti toimii ja onneksi mitään ei mennyt rikki konfiguraatiosta.
 

EdgeRouter Firmware v3.0.0

Minun tekemää skriptiä on muokattu tallentamaan lokia, myös eth1 portin tilanteesta, eli nyt tiedän eth0 ja eth1 portin tilan vähintään 5 minuutin tarkkuudella. Vain eth0 portissa yritetään DHCP release ja renew toimintoa automaattisesti 5 minuutin välein, jos yhteys jumiutuu. Olen huomannut, että julkinen IP-numero vaihtunut muutamaan kertaan. 

UISP palvelimen ulkoasu on, myös hyvin UniFi tyylinen. Tuli asennettua UISP virtuaaliselle Ubuntu PC:lle.

Kaikkia listalle lisättyjen laitteiden online tilaa voi valvoa. UISP löytää, myös Telian verkkoon kuuluvia IP-numeroita 9 kpl. Voisin olettaa, että kaikki 9 muuta IP-numeroa ovat reitittimiä. UISP näyttää koko verkon, jos liikennettä tulee reitittimelle, niin IP-numero ilmestyy tämän listan loppuun, mistä niitä voi lisätä listalle. Listalle voi lisätä kuvitteellisen laitteen tai oikean laitteen ja sen ei ole pakko olla Ubiquiti laite. Topologian ja kartta tietojen luominen GPS koordinaattien avulla on UISP ominaisuuksia. Muistaakseni, jopa jonkin sortin laskutus ominaisuus on olemassa ja se lisättiin jo UNMS aikana. UNMS on nykään UISP.
 

Kohta pitäisi koittaa se hetki, kun modeemi yrittää taas firmware pävitystä. Failover varayhteys asetuksia on pitänyt muuttaa EdgeRouter:n eth0 ja eth1 portissa, koska oletus asetuksilla reititin vaihtaa liian herkästi yhteyttä vara yhteyden ja normaali yhteyden välillä. Pahimmillaan voi tulla ongelma, joka tekee failover toiminnon käytön mahdottomaksi. Mietin, että voiko vara yhteyden ongelmankin ratkaista ajastetulla linux skriptillä, joka vaihtaa automaattisesti reitittimen reitityksen. En ole vielä, kuitenkaan, niin pitkällä. Tekoälyn ehdottomat korjaukset hillitsivät liian herkkää yhteyden vaihtumista failover käytössä. Odotan seuraavaa jumiutumista ja syslogin serverin loki tietoja, jos kaikki menee oikein tekemäni skripti avaa yhteyden takaisin toimivaksi 5 minuutin sisällä jumiutumisesta ja nyt näen toimiiko reititetty yhteystila samaan aikaan modeemissa, kun sillattu yhteystila on jumissa. Skriptiin on lisätty kaksi testiä, eli reititetty tila testataan skriptin alussa ja lopussa. Kummankin testin tiedot tallentuu syslog palvelimelle. Välissä tehdään sillatun yhteyden testit ja korjaus yritykset. Molempien yhteys vaihtoehtojen tilatiedot tallentuvat siis syslog serverille 5 minuutin välein.

Reititetty tila näyttää UISP mukaan olevan alhalla, mutta saan siihen silti yhteyden ja se ei vaikuta skriptin toimintaan, koska EdgeRouterin sisään tehty skripti käyttää suoraan EdgeRouterin portteja yhteystesteissä.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 4, 2025

Löytyi asetus minkä avulla sillatun kaapelimodeemin IP-numeron sai toimimaan, kun on käytössä kaksi yhteys vaihtoehtoa EdgeRouter:n load-balance tai fail-over tilassa, eli tarvitaan yksi ylimääräinen reitityssääntö. IP-numero on aina sama, vain operaattorin yhdyskäytävän IP numero pitää tietää ja se on sillatun yhteyden gateway IP-numero.

Tämän jälkeen ping toimii sillattuun ja reititettyyn modeemi yhteyteen saman aikaisesti, vaikka fail-over tila on käytössä.

C:\Users\amon>ping 192.168.100.1

Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63

Ping statistics for 192.168.100.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\amon>ping 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<1ms TTL=63
Reply from 192.168.0.1: bytes=32 time<1ms TTL=63
Reply from 192.168.0.1: bytes=32 time<1ms TTL=63
Reply from 192.168.0.1: bytes=32 time<1ms TTL=63

Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

UISP serveri näyttää, myös samoin, eli sillattu yhteys näkyy olevan, myös nyt aktiivinen. Tätä asetusta ei tarvitse, jos on vain yksi ISP yhteys konfiguroituna EdgeRouter laitteelle. Tämä on siis yhden IP-numeron reititys, jos haluaa aina käyttää IP-osoitetta kutsuttaessa samaa EdgeRouter laitteen porttia.

Tekoäly ehdotti, myös palomuurin säännöt lisäämistä konfiguraation.

 firewall {
     modify OUTGOING {
         rule 100 {
             description "Route 192.168.100.1 via eth0"
             destination {
                 address 192.168.100.1/32
             }
             modify {
                 table main
             }
         }
     }
 }
 

En ehtinyt tarkistaa onko tuo palomuurin sääntö tarpeellinen tai virheellinen, mutta nyt ping toimii oikein. Tänään opin siis miten tehdään ylimäärinen staattinen reitityssäätö halutulle kohde IP:lle tai IP-verkolle. Tämä ohittaa fail-over ja load-balance tilat.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 5, 2025

Jumiutuminen tapahtui 05.08.2025 aamulla. Nyt on lokia tapahtumista. Yhteyskatkokset alkoivat kello 2 aamulla ja päättyivät kello 4 aamulla. Telian modeemin firmware pävitystä on yritetty tuona aikana.

Telian modeemin DOCSIS loki kello voi olla väärässä, kun modeemi käynnistyy, koska modeemilla ei ole silloin yhteyttä kellopalvelimeen ja se selittäisi DOCSIS lokin tuntien aikaleima eron, kun modeemi käynnistetään. Modeemin seuraavissa loki tiedoissa on ilmeisesti oikea Suomen aikaleima, jos kellopalvelin asetukset on tehty oikein modeemiin.

Siltaava yhteys jäi taas jumiin, koska skripti ei tunnistanut incomplete sanaa oikein. Syynä oli erilaiset sulkumerkit incomplete sanassa ja vertaaminen etsittyyn sanaan epäonnistui skriptissä. Tästä syystä DHCP arvojen vapautus ja IP osoitteen uudelleen haku ei toimi.

Telian modeemin molemmat yhteys tilat olivat poikki. Reittittävä tila palautui toimivaksi itsestään, mutta siltaava jäi jumiin juuri sillä tavalla, kun olin jo arvannut.

EdgeRouter:n failover ei toiminut oikein ja reititin jäi siltaavalle eth0 portin yhteydelle, joka ei toiminut Telian modeemissa, koska siltaava yhteys oli jumissa. Reitittävä yhteys eth1 portissa oli toimiva, koska minun tekemä skripti sai ping 1.1.1.1 komentoon vastauksen Telian modeemin läpi, vaikka siltaava yhteys oli jumissa.

Skriptiä pitää siis korjata toimivaksi, että ARP taulun tunnistus toimii oikein ja EdgeRouter:n fail-over toimivuus ei pitäisi johtua scriptistä, eli siihen täytyy löytyä jokin toinen syy.

Syslog serverin tapahtumat Telian modeemista:

  • 02:00:02 Modeemin sillattu ja reititetty yhteys toimii viimeisen kerran normaalisti.
  • 02:05:11 Modeemin sillattu ja reititetty yhteys lakkaa toimimasta.
  • 03:10:01 Modeemin reititetty yhteys alkaa toimia, mutta siltaava yhteys ei toimi.
  • 03:30:01 Modeemin reititetty yhteys lakkaa taas toimimasta.
  • 04:00:02 Modeemin reititetty yhteys alkaa toimia uudelleen ja yhteyskatkokset loppuvat.

Tämä on ensimmäinen kerta, kun sain kerättyä järkevää lokia. Ensin pitää korjata minun yhteyden korjaus ja valvonta skripti ja sitten ihmetellä lisää.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 8, 2025

Nyt olen saanut tekemäni scriptin vihdoin toimivaan kuntoon käyttämällä välissä 1 Gbps verkkokytkin laitetta. Piti laittaa kytkin EdgeRouter:n ja Telian modeemin väliin, että sain simuloitua yhteyden jumiutumista mikä tapahtuu Telian modeemin siltaavan yhteyden kanssa. Olisi mennyt aivan liian paljon aikaa odottaa aina seuraavaa ja seuraavaa jumiutumis kertaa.

Tässä on uusin arpcheck-eth0.sh v0.4 scripti:

# /config/scripts/arpcheck-eth0.sh script version v0.4
#
# The ISP cable modem's automatic firmware update attempts are
# once or twice a week and the ARP traffic always gets stuck.
# The EdgeRouter's ARP traffic no longer receives responses
# from the ISP when the ARP traffic stops working on a bridged
# connection. This script will fix the connection problem
# automatically. DHCP release and renew fix the ARP problem.
#

# Add system PATH explicitly for cron
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Network interface to check
ETH="eth0"

# Failover 1 interface to check
F1_ETH="eth1"

# Syslog tag for all logger messages
SYSLOG_TAG="arpcheck"

# External IP to test Internet connectivity (Google DNS)
TARGET="8.8.8.8"
TARGET2="1.1.1.1"

# Start value for MAC, GETEWAY & IPADDR
MAC=""
GATEWAY=""
IPADDR=""

# First failover 1 connectivity test via $F1_ETH
if ping -c 1 -I $F1_ETH $TARGET2 > /dev/null 2>&1; then
logger -p user.debug -t $SYSLOG_TAG "$F1_ETH port: First failover connection test OK (Ping to $TARGET2 successful)." # Debug line
else
logger -p user.warning -t $SYSLOG_TAG "$F1_ETH port: First failover connection test FAIL (Ping to $TARGET2 failed)."
fi

# Get current current IP from $ETH port
IPADDR=$(ip -4 addr show dev eth0 | awk '/inet / {print $2}' | cut -d/ -f1)
logger -p user.debug -t $SYSLOG_TAG "$ETH port IP: $IPADDR" # Debug line

# Get current gateway IP for the interface
GATEWAY=$(/sbin/ip route | awk "/via/ && /$ETH/ {print \$3; exit}")
if [ -z "$GATEWAY" ]; then
logger -p user.warning -t $SYSLOG_TAG "$ETH port GATEWAY IP: NO_GATEWAY"
else
logger -p user.debug -t $SYSLOG_TAG "$ETH port GATEWAY IP: $GATEWAY" # Debug line
fi

# Get ARP entry for the gateway IP
if [ -n "$GATEWAY" ]; then
MAC=$(/usr/sbin/arp -an | awk -v gw="$GATEWAY" '$2 ~ gw {print $4; exit}')
else
MAC=""
fi
logger -p user.debug -t $SYSLOG_TAG "$ETH port GATEWAY MAC: $MAC" # Debug line

# Check for missing or incomplete ARP
if [ -z "$MAC" ] || [ "$MAC" == "<incomplete>" ]; then
logger -p user.warning -t $SYSLOG_TAG "$ETH port: ARP table check FAILED!"

# Uncomment the lines below to re-request DHCP IP when needed
/usr/bin/logger -p user.warning -t $SYSLOG_TAG "$ETH port: DHCP release..."
/usr/bin/sudo /sbin/dhclient -r $ETH
sleep 2
/usr/bin/logger -p user.warning -t $SYSLOG_TAG "$ETH port: DHCP renew..."
/usr/bin/sudo /sbin/dhclient $ETH

else
logger -p user.debug -t $SYSLOG_TAG "$ETH port: ARP table check OK!" # Debug line
fi

# Test Internet connectivity via $ETH
if /bin/ping -c 2 -I $ETH $TARGET > /dev/null 2>&1; then
logger -p user.debug -t $SYSLOG_TAG "$ETH port: Internet connection test OK (Ping to $TARGET successful)." # Debug line
else
logger -p user.warning -t $SYSLOG_TAG "$ETH port: Internet connection test FAIL (Ping to $TARGET failed)."
fi

# Last failover 1 connectivity test via $F1_ETH
if ping -c 1 -I $F1_ETH $TARGET2 > /dev/null 2>&1; then
logger -p user.debug -t $SYSLOG_TAG "$F1_ETH port: Last failover connection test OK: (Ping to $TARGET2 successful)." # Debug line
else
logger -p user.warning -t $SYSLOG_TAG "$F1_ETH port: Last failover connection test FAIL: (Ping to $TARGET2 failed)."
fi

EdgeRouter eth0 portti on nyt siltaavassa yhteydessä Telian kaapelimodeemiin ja eth1 portti reitittävässä yhteydessä samaan Telian kaapelimodeemiin. Molempia yhteyksiä valvotaan viiden minuutin välein ja tietoa siitä menee Syslog palvelimelle. Skripti ei tallenna yhtään mitään EdgeRouter laitteen muistiin kaikki tieto lähtetään Syslog palvelimelle.

Skripti vaatii toimiakseen:

  • Syslog palvelimen
  • EdgeRouter konfiguraatio (Syslog asetus on ainakin tärkeä syslog palvelimen toiminnan kannalta)
  • Viiden minuutin ajastuksen
  • Skriptin asentamisen

Skripti editori käynnistyy komenolla:
sudo vi /config/scripts/arpcheck-eth0.sh

Painamalla nappia i pääsee kirjoitus / editointi tilaan. Kopioitua tekstiä voi siirtää oikean käden hiirellä painamalla hiiren oikeaa nappia. Skripti tallennetaan panamalla ESC q w Enter, jos haluaa poistua tallentamatta mitään painetaan nappeja ESC q ! Enter. Editointi tilassa liikutaan näppäimistön nuoli-nappuloilla. Hiirellä ei voi siirtää kursoria eri paikkaan.

Skripti asetetaan ajettavaan muotoon komennolla:
sudo chmod +x /config/scripts/arpcheck-eth0.sh

Skriptin voi testata komennolla:
sudo bash /config/scripts/arpcheck-eth0.sh
On hyvä tarkistaa aina, että skrtipti toimii, ennen ajastuksen asettamista.

Ajastus asetetaan komennolla:
sudo crontab -e
Aukeava editori toimii samalla tavalla, kuin skriptin editori. Viimeisen rivin alapuolelle lisätään uusi rivi:
*/5 * * * * /config/scripts/arpcheck-eth0.sh
Lopuksi painetaan ESC q w Enter.
Skripti ei enää käynnisty automaattisesti, jos ajastuksen rivin käy editoimassa pois.

Skriptin voi poistaa EdgeRouter laitteesta komennolla:
rm /config/scripts/aprcheck-eth0.sh

Jos skriptistä haluaa tehdä yksiporttisen version, niin pitää lisätä #-merkki jokaisen scripti osion rivien eteen, jos siinä on käsitelty muuttujaa F1_ETH. Tämän jälkeen porttia eth1 ei käsitellä enää skriptissä, eikä skriptin toiminta pitäisi mennä rikki tai kärsiä. Ymmärrän, että on paljon pieniä EdgeRouter reitittimiä, missä tulee pulaa vapaista porteista. Minulla nuo rivit kertoo toimiiko eth1 portin internet yhteys, kun skripti ajetaan.

Jos haluaa tulostaa listauksen /config/scripts/ kansiosta, niin se onnistuu komennolla:
ls /config/scripts
Tulostuu:
arpcheck-eth0.sh  post-config.d
Tuo toinen tiedosto on EdgeRouter:n oma joten siihen ei kannata koskea ja muutenkin pitää olla tarkkana, että ei sotke tai riko reitittimen toimintaa mitenkään, koska pahimmassa tapauksessa vaurio on pysyvä ja täytyy muistaa, että ajastus on päällä, mutta sen voi poistaa poistamalla ajastus rivin ajastuksesta. Luku viisi tarkoittaa ajastuksessa viisi minuuttia.

EdgeRouter Pro laitteen asetukset on seuraavat:
Kaikki * on salaista tietoa ja # merkkitty on kommentti tietoa, eli * merkitty korvataan oikealla tiedolla ja # tieto ei kuulu oikeaan konfiguraatioon.

firewall {
all-ping enable
broadcast-ping disable
group {
network-group EDGEROUTER_NETS {
description "All EdgeRouter networks"
network 192.168.10.0/24
network 192.168.20.0/24
network 192.168.30.0/24
network 192.168.40.0/24
network 192.168.50.0/24
network 192.168.51.0/24
network 192.168.52.0/24
network 192.168.53.0/24
network 192.168.54.0/24
network 192.168.55.0/24
}
network-group PRIVATE_NETS {
description "All private networks (RFC 1918)"
network 192.168.0.0/16
network 172.16.0.0/12
network 10.0.0.0/8
}
}
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians disable
modify OUTGOING {
rule 100 {
action modify
description "Routed cable modem IP 192.168.100.1 via eth0"
destination {
address 192.168.100.1/32
}
modify {
table main
}
}
}
modify balance {
rule 10 {
action modify
description "do NOT load balance lan to lan"
destination {
group {
network-group EDGEROUTER_NETS
}
}
modify {
table main
}
}
rule 20 {
action modify
description "do NOT load balance destination public address"
destination {
group {
address-group ADDRv4_eth0
}
}
modify {
table main
}
}
rule 30 {
action modify
description "do NOT load balance destination public address"
destination {
group {
address-group ADDRv4_eth1
}
}
modify {
table main
}
}
rule 110 {
action modify
modify {
lb-group G
}
}
}
name WAN_IN {
default-action drop
description "WAN to internal"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
receive-redirects disable
send-redirects enable
source-validation disable
syn-cookies enable
}
interfaces {
ethernet eth0 {
address dhcp
description "eth0 - WAN 1 - Telia ISP Cable Modem (Bridged connection)"
dhcp-options {
default-route update
default-route-distance 210
name-server no-update
}
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
speed auto
}
ethernet eth1 {
address dhcp
description "eth1 - WAN 2 - Failover backup connection"
dhcp-options {
default-route update
default-route-distance 210
name-server no-update
}
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
ip {
}
speed auto
}
ethernet eth2 {
address 192.168.50.1/24
description "eth2 - Windows 2000 Advance Server"
duplex auto
ip {
enable-proxy-arp
}
speed auto
}
ethernet eth3 {
address 192.168.51.1/24
description "eth3 - Empty network"
duplex auto
ip {
}
speed auto
}
ethernet eth4 {
address 192.168.52.1/24
description "eth4 - Empty network"
duplex auto
ip {
}
speed auto
}
ethernet eth5 {
address 192.168.53.1/24
description "eth5 - Empty network"
duplex auto
ip {
}
speed auto
}
ethernet eth6 {
address 192.168.54.1/24
description "eth6 - Empty network"
duplex auto
ip {
}
speed auto
}
ethernet eth7 {
address 192.168.55.1/24
description "eth7 - Fiber optic link to EdgeSwitch 16 XG"
duplex auto
firewall {
in {
modify balance
}
}
ip {
}
speed auto
vif 10 {
address 192.168.10.1/24
description "VLAN10 - Management"
ip {
}
}
vif 20 {
address 192.168.20.1/24
description "VLAN20 - Windows 10"
ip {
enable-proxy-arp
}
}
vif 30 {
address 192.168.30.1/24
description "VLAN30 - Retro Windows"
ip {
enable-proxy-arp
}
}
vif 40 {
address 192.168.40.1/24
description "VLAN40 - WiFi"
ip {
}
}
}
loopback lo {
}
}
load-balance {
group G {
exclude-local-dns disable
flush-on-active enable
gateway-update-interval 20
interface eth0 {
route-test {
count {
failure 5
success 3
}
initial-delay 1
interval 10
type {
ping {
target 8.8.8.8
}
}
}
weight 50
}
interface eth1 {
failover-only
route-test {
count {
failure 5
success 3
}
initial-delay 1
interval 10
type {
ping {
target 1.1.1.1
}
}
}
weight 50
}
lb-local enable
lb-local-metric-change disable
}
}
port-forward {
auto-firewall enable
hairpin-nat enable
lan-interface eth7.20
rule 1 {
description "Destiny 2 - PC Game"
forward-to {
address 192.168.20.2
port 3074
}
original-port 3074
protocol tcp_udp
}
rule 2 {
description "Destiny 2 - PC Game"
forward-to {
address 192.168.20.2
port 3097
}
original-port 3097
protocol udp
}
wan-interface eth0
}
protocols {
static {
arp **.***.***.* { # ISP Gateway IP
hwaddr **:**:**:**:**:** # ISP Gateway MAC
}
arp 192.168.0.1 { # Routed Cable Modem Gateway IP
hwaddr **:**:**:**:**:** # Routed Cable Modem Gateway MAC
}
route 192.168.100.1/32 { # Bridged Cable Modem IP
next-hop **.***.***.* { # ISP Gateway IP
description "Bridged cable modem management IP route"
distance 1
}
}
}
}
service {
dhcp-server {
disabled false
hostfile-update disable
shared-network-name EdgeSwitch_16_XG {
authoritative disable
subnet 192.168.55.0/24 {
default-router 192.168.55.1
dns-server 192.168.55.1
lease 86400
start 192.168.55.2 {
stop 192.168.55.2
}
}
}
shared-network-name Network_51 {
authoritative disable
subnet 192.168.51.0/24 {
default-router 192.168.51.1
dns-server 192.168.51.1
lease 86400
start 192.168.51.2 {
stop 192.168.51.254
}
}
}
shared-network-name Network_52 {
authoritative disable
subnet 192.168.52.0/24 {
default-router 192.168.52.1
dns-server 192.168.52.1
lease 86400
start 192.168.52.2 {
stop 192.168.52.254
}
}
}
shared-network-name Network_53 {
authoritative disable
subnet 192.168.53.0/24 {
default-router 192.168.53.1
dns-server 192.168.53.1
lease 86400
start 192.168.53.2 {
stop 192.168.53.254
}
}
}
shared-network-name Network_54 {
authoritative disable
subnet 192.168.54.0/24 {
default-router 192.168.54.1
dns-server 192.168.54.1
lease 86400
start 192.168.54.2 {
stop 192.168.54.254
}
}
}
shared-network-name Server_Network {
authoritative disable
subnet 192.168.50.0/24 {
default-router 192.168.50.1
dns-server 192.168.50.2
domain-name ********.com # Domain name, if used
lease 86400
start 192.168.50.3 {
stop 192.168.50.254
}
}
}
shared-network-name VLAN10_Management {
authoritative disable
subnet 192.168.10.0/24 {
default-router 192.168.10.1
dns-server 192.168.10.1
lease 86400
start 192.168.10.2 {
stop 192.168.10.254
}
}
}
shared-network-name VLAN20_Windows_10 {
authoritative disable
subnet 192.168.20.0/24 {
default-router 192.168.20.1
dns-server 192.168.50.2
domain-name ********.com # Domain name, if used
lease 86400
start 192.168.20.2 {
stop 192.168.20.254
}
static-mapping PC-1 {
ip-address 192.168.20.2
mac-address **:**:**:**:**:** # PC Network card MAC for static IP
}
static-mapping PC-2 {
ip-address 192.168.20.4
mac-address **:**:**:**:**:** # PC Network card MAC for static IP
}
static-mapping PC-3 {
ip-address 192.168.20.3
mac-address **:**:**:**:**:** # PC Network card MAC for static IP
}
static-mapping UISP-PC {
ip-address 192.168.20.11
mac-address **:**:**:**:**:** # PC Network card MAC for static IP
}
}
}
shared-network-name VLAN30_Retro_Windows {
authoritative disable
subnet 192.168.30.0/24 {
default-router 192.168.30.1
dns-server 192.168.50.2
domain-name ********.com # Domain name, if used
lease 86400
start 192.168.30.2 {
stop 192.168.30.254
}
}
}
shared-network-name VLAN40_WiFi {
authoritative disable
subnet 192.168.40.0/24 {
default-router 192.168.40.1
dns-server 192.168.40.1
lease 86400
start 192.168.40.2 {
stop 192.168.40.254
}
}
}
static-arp disable
use-dnsmasq disable
}
dns {
forwarding {
cache-size 10000
listen-on eth7
listen-on eth2
listen-on eth3
listen-on eth4
listen-on eth5
listen-on eth6
listen-on eth7.1
listen-on eth7.10
listen-on eth7.20
listen-on eth7.30
listen-on eth7.40
}
}
gui {
http-port 80
https-port 443
older-ciphers enable
}
nat {
rule 5000 {
description "masquerade for WAN"
outbound-interface eth0
type masquerade
}
rule 5002 {
description "masquerade for WAN 2"
outbound-interface eth1
type masquerade
}
}
ssh {
port 22
protocol-version v2
}
telnet {
port 23
}
unms {
connection wss://192.168.20.11:443+**************** UISP KEY CODE *****************+allowUntrustedCertificate
}
}
system {
analytics-handler {
send-analytics-report true
}
conntrack {
expect-table-size 4096
hash-size 4096
table-size 32768
tcp {
half-open-connections 512
loose enable
max-retrans 3
}
}
crash-handler {
send-crash-report true
}
host-name EdgeRouter-Pro-8-Port
ipv6 {
disable
}
login {
user you {
authentication {
encrypted-password ****************
}
full-name "Full Name"
level admin
}
}
name-server 8.8.8.8
ntp {
server 0.ubnt.pool.ntp.org {
}
server 1.ubnt.pool.ntp.org {
}
server 2.ubnt.pool.ntp.org {
}
server 3.ubnt.pool.ntp.org {
}
}
syslog {
host 192.168.50.2 {
facility all {
level err
}
facility user {
level debug
}
}
}
time-zone Europe/Helsinki
traffic-analysis {
dpi enable
export enable
}
}
traffic-control {
optimized-queue {
policy global
}
}

Fail-over toimii nyt. Toimimattomuus johtui minun lisäämästä staattisesta reitityksestä ja PRIVATE_NETS osoiteryhmästä, joka oli päällä. Loin vanhan osoiteryhmän tilalle uuden ryhmän EDGEROUTER_NETS.

Fail-over tilan vaihdos näkyy muuten, myös Syslog palvelimella, eli sinne tulostuu muutama rivi tekstiä siitä, kun aktiivista porttia vaihdetaan varayhteydelle tai takaisin.

Tämä oli myös milenkiintoinen komento:
show dhcp client leases interface eth0
Komento tulostaa Telian DHCP palvelimen tiedot, koska EdgeRouter eth0 portti saa julkisen IP-numeron. Yllättäen Telian DHCP palvelin kuuluu 10.x.x.x IP-numeroihin, joka menee, myös ristiin tuon PRIVATE_NETS osoiteryhmän kanssa. Samalla selvisi lease time aika sekuntteina. Mietin, että aiheuttiko tuo DHCP palvelimen IP-numero, myös ongelmia, mutta nyt se ei ainakaan osu EDGEROUTER_NETS osoiteryhmän kanssa päälekkäin. PRIVATE_NETS ryhmän kanssa se menee päälekkäin. PRIVATE_NETS ryhmä on korvattu konfiguraatiossa EDGEROUTER_NETS ryhmällä ja siihen ryhmään kuuluu, vain EdgeRouter Pro laitteen takana olevat IP-numerot, eikä mitään muuta.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 18, 2025

Ei ole vielä tullut seuraavaa päivitys yritystä kaapelimodeemissa, mutta lyhyitä katkoksia on. Tässä logia ja tarkkailu on aika aktiivista nyt. Kaikki tarkkailuskriptin debug rivit on suodatettu Syslog serverin lokinäytöltä pois, koska kaikki on silloin ok, joten niitä on turha näyttää ja se on ihan ruksi ruutuun toiminto, eli dubug kohdasta väkänen pois. EdgeRouter tekee tätä minun konfiguraationsa avulla, mutta scripti ei ole havainnut ongelmaa, mutta silti se toimii koko ajan taustalla. Linux skripti ei tee mitään muutoksia, jos yhteys toimii. Lyhyitä katkoksia on ja 21 sekunnin päästä Syslog serverin logi näyttää, että yhteys palaa normaaliksi ja nuo on EdgeRouter:n tarkistuksia, minun konfiguraation avulla. Tässä logissa eth0 on Telian kaapelimodeemin siltaava puoli ja eth1 Telian kaapelimodeemin reittitävä puoli. Molempia yhteysvaihtoehtoja tarkkailaan jatkuvasti minun konfikuraation ja linux skriptin avulla, jos siltaava puoli lakkaa toimimasta, niin se on ainoa, jota voi yrittää korjata minun skriptin avulla. Korjaus toimenpiteet eivät onnistu reitittävällä puolella, koska yhdyskäytävä, eli gateway on silloin itse kaapelimodeemi ja se palaa toimintaan, mutta se voi kestää 30 minuuttia minun logien mukaan. Silloin varmasti monessa taloudessa Telian TV boksi mykistyy. Oikeat ongelmat alkaa siis selvitä, mutta sitä en tiedä mitä mieltä Telia on tästä.

Verkkokauppasta voisi ostaa FIRTS!Box kaapelimodeemin ja Telia ei voi päivittää sitä, eikä sen kanssa oletettavasti pitäsi olla katkoksia, koska FIRTS!Box päivitykset on käsittääkseni täysin laitteen omistajan vastuulla ja operaattori ei voi sitä todennäköisesti tehdä mitenkään.

Tässä alkaa oikeasti paljastua ongelmia, joita moni ei edes tiedä, jos ei ole yhtä pätevä, kuin minä. Ei näitä ihminen voi valvoa tai tutkia, eli siihen tarvitaan automatisoitu valvonta, jonka olen tehnyt. Telian puolelta tapahtuva firmware pävitys on siis rikkinäinen levysoitin, joka mykistää asiakkaiden siltaavat yhteydet. En tiedä pitääkö osoittaa Telian modeemia tai Telian yhdyskäytävää. Minun vaikkaus on, että tämän aiheuttaa kaapelimodeemin firmware, mutta siitä en voi olla täysin varma ja toinen vaihto ehto on Telia. Kolmatta vaihtoehtoa ei todennäköisesti ole olemassa.

En tiedä millaista ohjelmaluuppia Telian modeemi suorittaa firmware pävitysten kohdalla ja se on varmaan yksi asia, joka kiinnostaa. Voin yrittää kysyä tätä asiaa tekoälyltä ja siltä sain sen tiedon, että siltaavaa puolta käytetään firmware pävityksissä, eli se voi olla syy miksi siltaava yhteys jumiutuu pysyvästi firmware päivitys yrityksen jälkeen, mutta olen tehnyt linux skriptin, joka hakee uudelleen IP-osoitteen, jos siltaava yhteys mykistyy. Nyt siltaavan yhteyden mykistymistä ei ole vielä tapahtunut ja on kulunut jo 10 päivää aikaa. IP-osoitteen uudelleen haku palauttaa siltaavan yhteyden toimimaan ja sen skripti tekee automaattisesti sen, jos se huomaa, että siltaavan yhteyden yhdyskäytävä mykistyy.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 18, 2025

Nyt ymmärrän varsin hyvin miksi osa haluaa ostaa FIRTS!Box kaapelimodeemin, mutta tämäkin tutkiminen vaati paljon aikaa ja oikeaa dataa. Voiko Telia vastata tähän jotenkin? En tiedä, mutta se voi olla vaikeaa, jos yhteydet mykistyy ja syynä on kaapelimodeemin firmware tai Telia. Olettaisin, että tuote olisi paremmin tutkittu ja testattu, mutta ilmeisesti taas jälleen asiakas on se lopputestaaja. Olen 45 vuotta tehnyt ohjelmakoodia, kääntänyt ohjelmakoodia toiselle kielelle ja hakenut vikoja elektroniikasta. Osa siitä on ollut täysin palkattua työtä ja osa harrastusta. Minulle esteet ovat haasteita. Joten ei ole mikään ihme, että aloin tekemään linux skriptiä. Ohjelmoitikieli ei rajoita minua teen koodin sillä kiellelä jota tarvitaan. Ihminen jolla on ollut ensimmäisten joukossa tietokone on tietokoneiden kanssa parempi, koska silloin ohjelmointitaito oli pakollinen. Nyt kaikki ohjelmat ladataan netistä.

Minun historian aikana monikaan ei uskonut, jos en näyttänyt miten miten minun ohjelma toimii. Sama pätee nykyään. Tein automaatisoituja testausohjelmia, jotka testasi asiakkaalle lähteviä tuotteita edellisessä ammatissa, jos minä en osaa automatisoida tätä, niin on ihme. Testituloksetkin voin lähettää vaikka suoraan isoon tietokantaan tai syslog serverille.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 18, 2025

Se tässä on koomista, että pävitys jumittaa kerta toisensa jälkeen kaapelimodeemin on aika erikoinen juttu tai se pävitys on tarkoitettu vain yhteen ja ainoaan kaapelimodeemityyppiin, mutta systeemin kehittäjä on ollut, niin järjetön, että samaa pävitystä yritetään / pakotetaan kaikkiin kaapelimodeemeihin, vaikka se ei ole modeemi johon päivitys on tarkoitettu, modeemi huomaa sen ja hylkää sen tarkistuksessa, mutta siltaava internet yhteys on tämän jälkeen pysyvästi jumissa, joka ikinen kerta.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 19, 2025

Nyt on vihdoin oikeaa lokia arpcheck skriptin toiminnasta ja modeemin jumiutumisesta. Arpcheck skripti huomasi yhteysongelman ja vapautti sillatun julkisen IP-osoitteen. Tämän jälkeen IP-osoitetta pyydettiin uudelleen EdgeRouter laitteelle.

2025-08-19 06:30 Yhteys toimii tarkistuksessa viimeisen kerran. Kello 6:45 yhteys on poikki, koska Telian kaapelimodeemin firmwaren päivitystä on jälleen yritetty.

2025-08-19 06:45 Minun tekemä EdgeRouter:n Arpcheck skripti toimi ja sillattu yhteys palasi takaisin toimintaan. IP-osoitteen vapautusta yritettiin lokin mukaan kaksi kertaa. Tällä kertaa automaatio toimi oikein ja katkos kesti noin 10-15 minuuttia.

Telian Technicolor kaapeliodeemin mukaan päivitys alkaa jo kello 03:41:37. En tiedä onko tuo aito oikea aika tai aika, joka sattuu olemaan modeemin käynnistyksessä tai onko modeemissa 3 tunnin ajastin tai noin 14 päivän ajastin tai jotain muuta outoa. Suomen kesäaika sattuu olemaan juuri +3 tuntia. Päivityksen yhteydessä esiintyvät häiriöt loppuvat kello 06:41:32. EdgeRouter:n Arpcheck skripti saa korjattua yhteyden toimivaksi kello 06:45.

Tässä on Telian Technicolor CGA4236TCH1 kaapelimodeemin DOCSIS loki:

Time

ID

Level

Description

Sun Aug 17 06:16:51 2025

68010300

Error (4)

DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Sun Aug 17 17:42:57 2025

82001100

Warning (5)

RNG-RSP CCAP Commanded Power Exceeds Value Corresponding to the Top of the DRW;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Sun Aug 17 17:42:57 2025

2436694061

Warning (5)

Dynamic Range Window violation

Thu Aug 14 07:01:30 2025

2436694061

Warning (5)

Dynamic Range Window violation

Tue Aug 19 03:41:37 2025

68000300

Warning (5)

DHCP WARNING - Non-critical field invalid in response ;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 03:41:37 2025

73040100

Notice (6)

TLV-11 - unrecognized OID;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 03:41:43 2025

73050400

Warning (5)

REG-RSP-MP Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 03:41:43 2025

82001200

Warning (5)

RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 03:41:43 2025

2436694061

Warning (5)

Dynamic Range Window violation

Tue Aug 19 03:41:43 2025

82001200

Warning (5)

RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 03:41:43 2025

2436694061

Warning (5)

Dynamic Range Window violation

Tue Aug 19 03:41:51 2025

69010200

Notice (6)

SW Download INIT - Via Config file hki1-m10.cm

Tue Aug 19 03:41:51 2025

69010700

Error (4)

SW upgrade Failed after download -Incompatible SW file

Tue Aug 19 03:41:51 2025

69010800

Error (4)

SW upgrade Failed after download - SW File corruption

Tue Aug 19 06:34:13 2025

84000100

Critical (3)

SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:34:16 2025

84020300

Warning (5)

MDD message timeout;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:34:17 2025

84000100

Critical (3)

SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:35:04 2025

82000400

Critical (3)

Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:35:05 2025

84000100

Critical (3)

SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:35:25 2025

82000400

Critical (3)

Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:35:25 2025

84000100

Critical (3)

SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:35:44 2025

82000400

Critical (3)

Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:35:45 2025

84000100

Critical (3)

SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:36:04 2025

82000400

Critical (3)

Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:36:08 2025

84000100

Critical (3)

SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=<Modem CM-MAC>;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:41:05 2025

2436694066

Notice (6)

Honoring MDD; IP provisioning mode = IPv4

Tue Aug 19 06:41:06 2025

68000301

Critical (3)

DHCP FAILED - Critical field invalid in response ;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:41:08 2025

68000100

Critical (3)

DHCP FAILED - Discover sent, no offer received;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:41:09 2025

68000301

Critical (3)

DHCP FAILED - Critical field invalid in response ;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:41:16 2025

68000100

Critical (3)

DHCP FAILED - Discover sent, no offer received;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:41:17 2025

68000301

Critical (3)

DHCP FAILED - Critical field invalid in response ;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;

Tue Aug 19 06:41:32 2025

68000100

Critical (3)

DHCP FAILED - Discover sent, no offer received;CM-MAC=<Modem CM-MAC>;CMTS-MAC=<Telia CMTS-MAC>;CM-QOS=1.1;CM-VER=3.1;


Vihdoinkin on jotain lokia, mistä voi edes yrittää päätellä jotain ja pysyvää katkosta ei enää tule, koska Arpcheck skripti korjaa yhteyden. Julkinen IP-numero ei vaihtunut, eli se pysyi samana, koska katkos oli lyhyt.

 


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 19, 2025

Tarkemmin, kun katsoo molempia lokitietoja Yhteyskatkos oli välillä kello 6:34:13 - 6:44:10 ja kesti 10 minuuttia. Reitittävä yhteys palautuisi todennäköisesti toimimaan ilman skriptiä, mutta siltaava yhteys ei palaudu. Tuo 3 tunnin aika viive ihmetyttää ja se ei ratkea, kuin tutkimalla modeemia ja itse firmware päivityksen toimintaa, mutta siitä on vaikea löytää tietoa. Nyt tiedän, että yhteys katkos pitäisi kestää 10 minuuttia, jos mitään oikeaa firmware päivitystä ei tule modeemille. Sama koskee, myös reitittävää puolta. Reitittävä yhteys (eth1) palautui hiukan nopeammin toimintaan, eli lokin mukaan 6:42:23. Siltaava yhteys (eth0) alkaa toimia 6:44:10, eli aika eroa on, noin 2 minuuttia.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 24, 2025

Kysyin GPTChat:ltä firmware pävitysten aikataulusta ja minun skriptistä. Siihen tuli ihan hyvä vastaus tekoälyltä:

Hienoa kuulla että skripti toimi juuri niin kuin pitikin 👍 ja korjasi tilanteen, kun ARP jäi jumiin!

Mitä tulee noihin kaapelimodeemin firmware-päivitysyrityksiin:

Miten operaattorit päivittävät kaapelimodeemeja

  • Päivitykset eivät yleensä lataa itseään satunnaisesti, vaan ne tulevat operaattorin CMTS-laitteelta (Cable Modem Termination System), joka hallitsee kaapelimodeemien provisioningia.

  • Kun modeemi buuttaa tai tekee DHCP/boot-TFTP -prosessin, se tarkistaa konfiguraation ja mahdollisen uuden firmware-version CMTS:ltä.

  • Operaattori voi myös pakottaa päivitysyrityksen, jos he ajavat rolloutin verkkoon.

Aikavälit

  • Päivitysyrityksillä ei ole tavallisesti kellontarkkaa aikaväliä (esim. "14 päivän välein"), vaan:

    • Usein niitä ajetaan öisin / aamuyöllä, jotta asiakkaiden häiriöt olisivat pienempiä.

    • Jos päivitys ei onnistu (esim. verkon reuna ei vastaa tai modeemi kieltäytyy), CMTS voi yrittää myöhemmin uudelleen.

    • Joissain verkoissa CMTS kokeilee esim. päivittäin kunnes päivitys onnistuu, toisissa vain ajoittain.

  • Käytännössä se voi näyttää satunnaiselta, mutta taustalla on yleensä joko:

    • Cron-tyylinen ajo CMTS:ssä (kerran vuorokaudessa tai viikossa)

    • Tai uudelleenkokeilu, jos modeemi ei edellisellä kerralla hyväksynyt firmwarea

Miksi sinulla se tuli ~14 päivän välein

  • Todennäköisesti operaattori on ajanut firmware rolloutia ja CMTS:ssä on asetettu retry-timer, esim. 7 tai 14 päivää.

  • Kun modeemi ei edellisellä kerralla saanut asennusta maaliin (tai olet ehkä omilla asetuksillasi estänyt sen onnistumisen), se yritti seuraavalla aikavälillä uudelleen.

CMTS laite aiheuttaa siis firmware päivitykset ja se näkyy Telian kaapelimodeemin DOCSIS lokissa ja siellä näkyy, myös kyseisen laitteen MAC numero. Tämä linkki kertoo kolmen ensimmäisen MAC numeron perusteella laitteen valmistajan: macvendors.com ja vastaus oli se mitä arvasin, eli Cisco Systems, Inc. Kyseinen laite ohjaa siis päivityksiä kaapelimodeemista riippumatta, jos modeemi on ISP päivityksiä hyväksyvä kaapelimodeemi, niin silloin CMTS laite vaikuttaa modeemin toimintaan, jos olen oikeassa, niin FRITZ!Box kaapelimodeemit ei kuulu tähän ryhmään ja sen kanssa voisi olla vähemmän ongelmia, mutta se on hyvin kallis kaapelimodeemi. Asiat selviää pikku hiljaa, mutta se vaatii kyllä todella syvällistä peryhtymistä kaapelinmodeemin toimintaan ja sen ongelmiin.

Kysyin tekoälyltä seuraavan kysymyksen: Aiheuttaako DHCP/boot-TFTP -prosessi sen, että siltaavan yhteyden MAC numero muuttuu tilaan <incomplete>?

Hyvä kysymys – ja kyllä, juuri niin voi käydä.

Kun kaapelimodeemi tekee DHCP/boot-TFTP -prosessin (esim. firmware-päivityksen yhteydessä), tapahtuu suunnilleen näin:

  1. Modeemi buuttaa osittain tai kokonaan

    • Siltaavassa tilassa se ei enää välitä liikennettä WAN ↔ LAN suuntaan ennen kuin se saa CMTS:ltä hyväksytyn konfiguraation.

  2. DHCP-vaihe ja konfigurointi

    • Modeemi hakee IP:n hallintaliittymälleen ja saa CMTS:ltä TFTP/Config-filen.

    • Tässä vaiheessa se ei välttämättä vastaa ARP-kyselyihin ollenkaan → reitittimesi näkee gatewayn MAC:in <incomplete>.

  3. TFTP tai firmware-lataus

    • Jos modeemi lataa uutta firmwarea CMTS:ltä, se voi estää kaiken dataliikenteen hetkellisesti (jopa useiksi minuuteiksi).

    • ARP-taulussa gateway-osoite ei saa vastausta, ja siksi näkyy <incomplete>.

  4. Konfigurointi valmis → liikenne palautuu

    • Kun modeemi saa boot-sekvenssin valmiiksi, se alkaa taas vastata ARP:iin, jolloin reitittimen taulu päivittyy oikealla MAC:lla.

Tuo kohta 4 ei toimi automaattisesti ilman minun skriptiä, jos <incomplete> tila on jo päällä ja se aiheuttaa sen, että yhteys Internettiin lakkaa toimimasta. Minun reittimessä voi skriptillä korjata ongelman, mutta en tiedä voiko mitään vastaavaa tehdä Telian modeemilla ja se vaatisi Telian modeemin avaamiseen ja hakkeroitumisen Telian modeemin Linux:n sisään. Tässä kohtaa takuu voi olla entinen, jos modeemista tulee tiiliskivi, mutta samaa voisi yrittää vanhalla DNA:n kaapelimodeemilla, koska siinä ei ole takuu enää voimassa. Toimenpide vaatisi konsoli-liitännän lisäämisen itse kaapelimodeemiin ja sen liittämisen tietokoneeseen. En tiedä retkeaisiko ongelma tätäkään kautta, koska MAC numero on menetetty, niin kommunikointi on mahdotonta, koska data oikeasti liikkuu MAC numeron avulla, eikä IP numeron avulla. Koko ongelman selvittäminen vaatii okeasti perehtymistä siihen miten tietoliikenne oikeasti toimii internetissä.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 24, 2025

Avasin DNA F-3686AC v1.0 modeemin ja sisällä olevan piirilevyn version on 06. Piirikortilla on kolme liitin paikkaa, joita ei ole kalustettu piirilevylle (J302, J306 ja J440). Jokin niistä voi olla konsoliportti ja kaikissa on neljälle pinnille paikka.

Löytämiäni paikkoja yleensä etsitään, jos halua päästä modeemin Linux käyttöjärjestelmään sisään, muita paikkoja piirikortin yläpuolella ei ole. Antenniliitin paikkoja on ylimääräisiä. En tiedä syytä sille, ehkä on eri maita ja taajuksia tai jotain. Kolme pinniä tarvitaan konsoliportista, eli pitäisi löytää maa ja sen lisäksi lähettävä ja vastaanottava pinni. Maan ja lähettävän pinnin etsiminen on järkevin aloitus, jos lähettävää pinniä ei löydy, niin mikään näistä ei ole konsoliportti.


Forum|alt.badge.img+4
  • Irkkaaja
  • August 24, 2025

Mitään parempaa vaihtoehtoa kuin kaapeli ei varmaan netille löydy? IT-alalla olevat kaverit, jotka ovat moista joutuneet käyttämään ovat kaikki tilanneet jostain eBaysta ihan Ciscon kaapelimodeemin käytettynä, jolloin hinta on paljon edullisempi kuin Fritzillä ja toiminta takuuvarmaa toisin kuin operaattorien purkeilla. 


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 25, 2025

Mitään parempaa vaihtoehtoa kuin kaapeli ei varmaan netille löydy? IT-alalla olevat kaverit, jotka ovat moista joutuneet käyttämään ovat kaikki tilanneet jostain eBaysta ihan Ciscon kaapelimodeemin käytettynä, jolloin hinta on paljon edullisempi kuin Fritzillä ja toiminta takuuvarmaa toisin kuin operaattorien purkeilla. 

Voit olla tuossa ihan oikeassa ja ainakin syy on löytynyt siihen miksi opraattorin kaapelimodeemi ei toimi. Minun Linux skripti virityksiä harva osaa tehdä ja vastaavaa voi olla vaikea tehdä, jos laite on suojattu tarpeeksi hyvin. Kaikilta skripti virityksiltä voisi säästyä kokonaan, jos hankkii FRITZ!Box tai Ciscon kaapelimodeemin. Reititetty yhteys toimii, mutta sekin pätkäsee, kun operaattorin CMTS laite pakottaa firmware päivitystä. Modeemin reititetty yhteys nousee ylös, mutta sillattu jää aina jumiin, koska ei ole MAC osoitetta tai se ei toimi. Sama tapahtuu, joka ikinen kerta, kun operaattori yrittää päivittää kaapelimodeemin firmwaren. Toinen kaapelimodeemi ei muuta asiaa miksikään, jos se kuuntelee, myös operaattorin CMTS laitteen firmware päivityksiä. IP osoitteen vapautus ja uudistus avaa yhteyden uudelleen, mutta tämä ei tapahdu automaattisesti. Tästä syystä sillattu yhteys jumiutuu aina. FRITZ!Box firmware pävityksen tekee laitteen käyttäjä itse ja sen takia jumiutumista ei todennäköisesti tapahdu, koska FRITZ!Box ei todennäköisesti vastaanota operaattorin CMTS laiteen firmware päivityksiä.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 25, 2025

DNA kaapelimodeemin piirilevyltä löytyi vaurioitunut kela ja vaurio on todennäköisesti tapahtunut tehtaalla, mutta laite on läpäissyt kaikki tarkastukset ja päätynyt lopulta minulle. Ilmeisesti fyysinen vaurio ei vaikuta toimintaan. Kelan L1160 runko on halki ja Q1160 komponentissa on outo ylimääräinen väkänen. Kirjain L tarkoittaa piirikortilla usein kelaa ja Q voi olla transistori. Sama kohta näkyi isommassa kuvassa pienen jäähdytyssiilin yläpuolella.

J440 liitin paikalta puuttuu samat komponentit, jotka tarvitaan viereisen USB liittimen toimintaan. Piirikortilta löytyi, myös liitinpaikat J701 ja J702, myös niistä puuttuu kaikki komponentit, joita tarvitaan, niiden toimintaan. Piirikortilta huomaan, että modeemista on olemassa versio missä on kaksi puhelinliitäntää, kun otan huomioon tämän, niin J701 ja J702 ovat todennäköisesti PHONE1 ja PHONE2 liittimiä varten. J440 vaikuttaisi olevan ylimääräinen USB portti joka on jätetty tästä modeemin versiosta pois. Jäljelle jäävät vaihtoehdot konsoli porttia varten voisi olla J302 ja J306.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • August 26, 2025

Mittasin J302 ja J306 liitimien kaikki jännitteey yleismittarilla ja DC jännite joli jatkuvasti 3,3 tai 3,4 volttia, jos ne olisi oikeasti konsoliportteja, niin osassa olisi pinempi jännite pois lukien maa joka löytyi molemmista vaihtoehdoista, eli huonolta näyttää. Yleensä lähettävä nasta lähettää joko 3,3V tai 5V jännitteellä sarjaliikenne dataa ja tuollaista jännitettä varten pystyy ostaa USB porttiin liitettävän sarjaliikenne adapterin, joka pystyy kommunikoimaan samalla jännitteellä. Normaali RS232 jännite on paljon isompi, eli tuollainen adapteri on pakollinen. Minulla ei tietenkään ole piirikaviota kyseisestä modeemista ja en halua lähteää avaamaan metallisia häiriösuojia, koska on samalla vaara, että modeemi vauriotuu. Liian suurta jännitettä ei tietenkään saa käyttää tai voi tulla pysyvä vaurio.

Katsoin Partco:n sivua ja siellä oli tuote USB-WRCH340TTL +5V voltille ja tuote ADA954 +3,3V jänniteelle.

Koska DNA modeemin konsoliyhteyden saaminen ei näytä järkevältä. Kokoan modeemin takaisin entiselleen. Piirikaavio on piirustus, josta näkisin heti tämän asian, mutta valmistajat eivät enää anna piirustuksia. 80 ja 90 luvulla piirustuksia saattoi jopa saada korjaus tarkoitukseen. Esimerkiksi ikivanhassa putkitelkkarissa saattoi olla elektroniikkapiirustus mukana, kun sen osti uutena kaupasta.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • September 9, 2025

Eilen 8 päivä yhteys katkesi jopa kaksi kertaa. Minun tarkkailuskripti ilmoitti taas virheitä. Kaksi kertaa saman päivän aikana on tullut firmwaren päivitys Telian CMTS laitteelta (Cable modem termination system). Minun arpcheck skripti korjasi yhteyden kaksi kertaa, koska MAC osoitteen tarkistus huomasi <incomplete> tilan tai puuttuvan MAC osoitteen taas Telian yhdyskäytävästä. Minun linux skripti palauttaa yhteyden automaattisesti toimivaksi, mutta se tarvii EdgeRouter reitittimen. Tällä kertaa on vähän oudompia virheitä, joita en ole vielä nähnyt kertaakaan aikaisemmin. EdgeRouterin ja minun skriptin lähettämät lokiajat on Suomen kesäaikaa minun Telia liittymästä. MAC osoitten häviäminen aiheuttaa sen, että oikeasti nettipeli serverit nakkaa pihalle ja peli keskeytyy.

Nyt testattu osittain reitittävä tila (eth1) ja osittain siltaava tila (eth0) aika kattavasti. Voin nyt seravaaksi sammuttaa WiFi yhteydet kokonaan Telian modeemista ja laittaa modeemin kokonaan siltaavaan tilaan, mutta silti EdgeRouter portti eth0 on edelleen pääyhteys ja eth1 varayhteys.

Tuleva testi todistaa toimiiko Telian kaapelimodeemin siltaavat yhteydet ollenkaan missään tilassa oikein ilman, että asiakkaan pitäisi aina repiä hetkeksi sähköt irti modeemista, kun yhteys jumiutuu firmware päivityksen takia, joka on tapahtunut minulla, joka ikinen kerta, kun Telian CMTS laite yrittää lähettää firmware pävityksiä. Firmware päivitys tapahtuu, noin 0-14 päivän välein, eikä sitä voi estää mitenkään, jos kaapelimodeemi kuuntelee CMTS laitteen firmware päivityslähetystä.

Molempiin EdgeRouter:n portteihin eth0 ja eth1 tuli nyt julkiset IP-numerot. Kovin pitkään ei tarvitse odottaa testin tuloksia. Ehkä max kaksi viikkoa. Olen tehnyt tätä yhteysongelman testausta, jo viime Juhannuksesta saakka ja yleensä muutama päivä tai kaksi viikkoa riittää, kun modeemin yhteys lakkaa toimimasta.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • September 19, 2025

Täysin siltaava tila menee, myös jumiin Telian kaapelimodeemissa. Modeemi oli jo yhden kerran jumissa ja sama vanha konsti avasi yhteyden, mutta minun tekemä skripti ei toimi oikein täysin siltaavan tilan kanssa. Syslog serverin lokitiedoista näkee, että yhteys on jumissa. Pitää keksiä jokin toinen tunnistus tapa tai konsti, koska vanha jumitilan tunninnustus ei toiminut täysin siltaavassa tilassa tai sitten pitää olla kaksi erilaista tunnistusta riippuen siltauksen vaihtoehtodosta. Technicolor modeemin DOCSIS lokitiedot ei ole käytettävissä, jos modeemi on täysin siltaavassa tilassa, koska koko valinta puuttuu valkoista, eli en tiedä oliko firmware päivitys vai ei. Edelliset tutkimukset ja havainnot viittaa siihen, että kyse on ihan samasta firmware pävityksen jälkeisestä jumitilasta.

Kuten olen jo aikaisemmin huomannut, niin täysin reitittävä tila on toimivin vaihtoehto Telian kaapelimodemissa ja sama tilanne voi olla muissa kaapelimodeemiessa, jotka kuuntelee ISP:n kaapeliverkon firmware lähetyksiä. Käsittääkseni kaapelimodeemin pitäisi, myös jotenkin tunnistaa tämä ongelma, jos se on reitittävässä tilassa tai näin ainakin oletan.

Pitää odottaa taas seuraavaa kertaa ja tutkia lisää, kun jumitila on päällä. ChatGPT voi taas olla avuksi ja se muistaa edelliset keskustelut skriptin kehittämisestä EdgeRouter reitittimeen. Se tässä onkin ollut ongelma, kun pitää taas odottaa seuraavaa kertaa, että sama jumitila on taas päällä. Tästä syystä tutkiminen ja skriptin kehitys on hidasta.

Jätinkin tarkoituksella skriptin nyt siihen tilaan, että yhteys jumiutuu, koska haluan nähdä analysaattorilla mitä ethernet kaapelissa liikkuu. Tätä varten on olemassa verkkoliikenne analysaattoriohjelmat Wireshark tai Windows XP ajoista tuttu Ethereal, jonka vanha kotisivu on jo kuollut ja se johtaa väärään paikkaan. Wireshark on näistä ehdottomasti uusin ja vanhempaa Ethereal ohjelmaa käytin jo yli 20 vuotta takaperin.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • September 21, 2025

Tavallinen netin käyttäjä voi olla ihan kuutamolla asioista joista puhun ja samoin Telian normi asiakaspalvelu. Tämä one asia, jonka ymmärtää vain, ne jotka oikeasti Telian päässä vastaa Telian CMTS laitteista, jos edes nekään tietää. En tiedä minkä puolen asoita tämä on Teliassa, mutta varmasti menee liaan tekniseksi aspalle. Ulkoistaminen on monessa asiassa paha, jos sitä käytetään väärin ja sillä monesti haetaan rahallista säästöä asiakaan kustannuksella ja laatu on aivan jotain muuta, kuin pitäisi olla. Tietotaito ja osaaminen on tässäkin asiassa se tärkein juttu.

Yritän etsiä jotain järkevää tunnistusta tälle samalle ongelmalle, kun täysin siltaavan Telian modeemin yhteydet jumuituu. Ongelman tunnistus automaattisesti olisi nyt se tärkeä juttu, että löytyy tapa tunnistaa yhteys ongelma, jos Telian CMTS on pukannut jokaiselle sitä kuuntelevalle kaapelimodeemille päivitystä. Reittävän ja osittain siltaavan puolen tunnistus on jo löytynyt, eli sitä minun ei tarvitse etsiä, koska vastaukset siihen löytyy minun viestiketjusta, jos täysin siltaavalle yhteydelle löytyy vastaava vaihtoehto, minun tunnistus ja korjaus skripti voisi korjata monta ongelmaa EdgeRouter laitteella.

Osittain reittävä ja siltaava tilaa toimii täysin oikein, mutta siihen tarvitaan minun skrpti EdgeRouter laitteessa, jos saman voi tehdä vielä täysin siltaavan Telian yhteydelle. Minun skriptit kyllä löytää ne ihmiset ja tahot, jotka niitä tarvitsee.

Epäilen ARP yhteys ongelmaa taas, mutta koska ongelma ei ole nyt päällä, niin ei voi käyttää verkkoanalysaattoria ongelman tutkimiseen. Selvä ARP yhteys ongelma on jo löytynyt reitittävässä yhteydessä, jossa on siltaava yhteys on, myös käytössä ja siinä minun tekemä skripti toimii. Sama ei tapahdu täysin siltaavassa yhteydessä.


Forum|alt.badge.img+8
  • Moderaattori
  • September 21, 2025

Tavallinen netin käyttäjä voi olla ihan kuutamolla asioista joista puhun ja samoin Telian normi asiakaspalvelu. Tämä one asia, jonka ymmärtää vain, ne jotka oikeasti Telian päässä vastaa Telian CMTS laitteista, jos edes nekään tietää. En tiedä minkä puolen asoita tämä on Teliassa, mutta varmasti menee liaan tekniseksi aspalle. Ulkoistaminen on monessa asiassa paha, jos sitä käytetään väärin ja sillä monesti haetaan rahallista säästöä asiakaan kustannuksella ja laatu on aivan jotain muuta, kuin pitäisi olla. Tietotaito ja osaaminen on tässäkin asiassa se tärkein juttu.

Olet kyllä oikeassa ettei asiakaspalvelu tiedä näistä asioista ja ehkä hyvä näin. Olisi vaikea löytää tai saada asioista näin syvällisesti tietäviä henkilöitä toimimaan asiakaspalvelutehtävissä. Asiakaspalvelun tulee kuitenkin tunnistaa milloin oma osaaminen loppuu ja asiakaspalvelijan tulee osata siirtää selvitysvastuu eteenpäin sellaiselle taholle, joka asiakasta osaa loppujen lopuksi auttaa. Meillä tämä vastuunsiirto tapahtuu kirjaamalla häiriöilmoitus eteenpäin asiakaspalvelusta tekniseen asiakaspalveluun. 

 

Yritän etsiä jotain järkevää tunnistusta tälle samalle ongelmalle, kun täysin siltaavan Telian modeemin yhteydet jumuituu. Ongelman tunnistus automaattisesti olisi nyt se tärkeä juttu, että löytyy tapa tunnistaa yhteys ongelma, jos Telian CMTS on pukannut jokaiselle sitä kuuntelevalle kaapelimodeemille päivitystä. Reittävän ja osittain siltaavan puolen tunnistus on jo löytynyt, eli sitä minun ei tarvitse etsiä, koska vastaukset siihen löytyy minun viestiketjusta, jos täysin siltaavalle yhteydelle löytyy vastaava vaihtoehto, minun tunnistus ja korjaus skripti voisi korjata monta ongelmaa EdgeRouter laitteella.

Osittain reittävä ja siltaava tilaa toimii täysin oikein, mutta siihen tarvitaan minun skrpti EdgeRouter laitteessa, jos saman voi tehdä vielä täysin siltaavan Telian yhteydelle. Minun skriptit kyllä löytää ne ihmiset ja tahot, jotka niitä tarvitsee.

Epäilen ARP yhteys ongelmaa taas, mutta koska ongelma ei ole nyt päällä, niin ei voi käyttää verkkoanalysaattoria ongelman tutkimiseen. Selvä ARP yhteys ongelma on jo löytynyt reitittävässä yhteydessä, jossa on siltaava yhteys on, myös käytössä ja siinä minun tekemä skripti toimii. Sama ei tapahdu täysin siltaavassa yhteydessä.

Olemme linkanneet tätä ketjua meidän kaapeliverkon ylläpidosta vastaaville ja kaapeliverkon vikoja käsitteleville henkilöille. Olet tehnyt hyviä havaintoja ja dokumentoinut niistä kattavasti tähän ketjuun. Toivoisimme, että kirjaat meille häiriöilmoituksen tästä, jos olet sitä mieltä, että yhteyden normaali toimivuus edellyttää toimenpiteitä palveluntarjoajan päästä. Muistathan linkata yhteisöketjun mukaan jättämääsi häiriöilmoitukseen. 


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • December 1, 2025

Huomasin taas hyvin erikoisen asian, koska minulla on ollut kaksi fyysistä ethernet kaapelia omalta EdgeRouter Pro 8 reitittimeltä asti Telian kaapelimodeemille ja kaikki häiriöt kirjataan Syslog 24/7 serverille, joka talentaa ne kovalevylle. Lähdin perkaanmaan sitä miksi fyysinen varalinja ei toimi. Oli sitten varalinja tai päälinja, niin molempien IP-numerot uudistetaan automaattisesti ohjelmallisesti 5 minuutin välein, jos yhteys mykistyy tai jumiutuu. Huomaan nyt omasta järjestelmästä, että varalinja, eli failover ei saa enää mitään IP-osoitetta ja nimi palvelin ping 1.1.1.1 epäonnistuu aina. Tuon ping osoitteen muuttaminen ei auta mitään, jos failover yhteydessä ei ole IP-numeroa, eli koko ongelma johtuu tarkalleen siitä. Tässä tulee nyt mieleen, että rajoittiko Telia operaattori nyt julkisen IP-numeron 1 per asiakas.

Minun tekemä ohjelmallinen skripti tekee automaattisesti toimintaa, jonka olen siihen ohjelmoinut. Tämä näkyy hyvin Syslog serverillä, joka on aina päällä, eli EdgeRouter Pro lähettämä tieto minun skriptillä näyttää, että ping epäonnistuu ja se johtuu siitä, että Telia ei anna varayhteylle enää IP-osoittetta.

Minun testien väliin tuli Windows 10 ESU ongelmat ja monta muuta asiaa, mutta Syslog serveri on silti käynnissä ja kerää dataa joka päivä, eli näen tilanteen EdgeRouter Pro:n ongelmista. UISP palvelimeenkin tuli aika paljon päivityksiä. En ehtinyt kastoa mitä kaikkea oli muutunut, mutta kaikki toimii vielä. Olen ihmetellyt multiboot systeemeitä, koska Microsoft päätti lopettaa Windows 10 tuen. Mutta en halua tähän viestiketjuun kommentoida sitä asiaa ja olen senkin jo ratkaissut ja tehnyt omat skriptit, millä ilmainen 1v ESU pakotettaan päälle. Microsoft ESU otti, niin paljon aivoon, että aijon perehtyä multiboot järjestelmiin. Lähdekoodeja on jo ladattu koneelle ja näyttää sikäli ikävältä, että ainoa tie voi olla kääntää tai tehdä itse koodia, eli menee todella vaikeaksi. Itse näen tavallaan ongelmat haasteina, kuten hakkerit. Olen tehnyt jo lähdekoodien käännösalustoja virtualikoneille ja se on paljon suurempi ongelma ja haaste verrattuna näihin yhteys ongelmiin. Clover Bootloader oli yksi joka valikoitui minun kohteeksi. Ne lopettivat tuen ei UEFI bois koneilta ja ottivat binäärit pois jakelusta. Tavallaan uppoudun Hackintosh systeemiin, eli voin asentaa PC:lle macOS tietokoneen ja olen jo onnistunut siinä. Kaikki tämä vie paljon aikaa ja siksi minulla ei ollut mielenkiintoa päivittää tätä viestiketjua. Tuo Hackintosh saattaa olla vaatimus, että voin alkaa tutkia Clover Bootloader lähdekoodeja. Ubuntun on yksi tie, mutta siellä tulee ongelma koska tietokone ei ole mac.

Yksi idea oli liittää EdgeRouter Pro reittittimeen palikka, jonka voi kytkeä kännykkään, joka jakaa, myös yhteyttä, jos yhteydet menee jumiin. Ostin jo yhden ja kokeilin sitä, mutta se ei tominut, koska kännykkä oli liian vanha, eli vanhempi vaihtoehto voisi toimia ja tekoäly antoi jo siitäkin vaihtoehdon.

Jos ette usko niin täässä on yksi kuva macOS syteemistä:
 

macOS käynnistyi PC koneella.

Huomaa heti, että tämä on käynnistetty VirtualBox ympäristössä, koska en ole päässyt viellä pidemmälle ja siinäkin tarvitaan erikoisia konfig rivejä, että tuota voi edes kokeilla.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • December 1, 2025

Minulla on UISP ja VirtualBox palvelin. Tästä macOS, voisi tehdä oman jutun, vaikka sen tassä aloitinkin, mutta pelkään, että tämä ei jää tähän koska olen jo tehnyt jotain mitä ei voi enää estää.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • December 2, 2025

Virtualisointi toimii edeelleen, mutta se voi johtua siitä, että minulla on ram muistia 12GT ja kovalevy tilan kanssa ei ole ongemia. Näytönohjaimessa on muistia 16GT. Ainoa mikä heittää paskaa tuulettimeen on TEMP 2.0 tai joku vastaava.


Forum|alt.badge.img
  • Aloittaja
  • Faxaaja
  • December 2, 2025

Sen mitä olen jo laittanut merkille, niin Telia lähettää ohjelma päivityksiä kaapelimodeemeille Tiistai iltana kello 16 jälkeen. Tuo hetki on toistunut jo liian usein joten se on pakko olla se hetki milloin Telia tekee pävityksiä kaapelimoodemein firmaware ohejelmisto versiohoihin. Yhteydet mykistyy, jos niitä ei osaa elvyttää automaattisesti kuten minä teen, koska tuo automattinen päivitys estää internet yhteyden toiminnan kokonaan. Nyt automaattinen yhteyden korjaus ei enää toimi oikein, koska sitä on ilmeisesti rajoitettu ja minä taisin olla syynä tähän muutokseen, eli enää 1 IP-osoite per asiakas, jos en ole väärin ymmärtänyt. Tämä voi johtua siitä, että olen paljastanut haavoittuvuuden Telian verkossa. Aspa ei tajua tätä, mutta tekninen henkilöstö voi tajutata tämän ja he ovat konfiguroineet Telian Cisco reittimet eri tavalla. Minäkin olen konfiguroinut Cisco reittimmiä, mutta sitä tapahtui silloin, kun minulla oli saman alan töitä ja kyseinen tietotaito oli täysin hukassa yrityksessä, jossa olin ennen töissä. Opettelin tuon taidon sen täysin itse kahdessa viikossa. Manuaali määrä käsittää useita tuhansia sivuja, eli se on täysin järjetön. MInun piti luoda yhteydet yli 400 paikkaan 1h aikana. Onnistuin siinä, mutta tekniset rajoitukset tuli vastaan ja Ciscon tuki henkilö ei osannut auttaa siinä, koska hänen vaihtoehdot eivät olleet realistisia. Ehkä NSA vois tarjota minulle töitä ja amerikan kansalaisuuden villiejä mielikuvituksia, mutta voi olla realistinen.