Zyxelin 4 & 5G reitittimet LTE7460 yms

En ole kirjaa pitänyt, mutta alkaa tuntua, että olisko sittenkin kosteilla keleillä vaikutusta asiaan..
Toivottavasti vika on tässä, eikä protokollapuolella tai perus-computessa.
Vai mahtaako palstalta löytyä temppuilevia Zyxeleitä, jotka ovat kuivissa ja lämpimissä sisätiloissa tai ainakin suoralta sateelta suojassa
 
Toivottavasti vika on tässä, eikä protokollapuolella tai perus-computessa.
Vai mahtaako palstalta löytyä temppuilevia Zyxeleitä, jotka ovat kuivissa ja lämpimissä sisätiloissa tai ainakin suoralta sateelta suojassa

Omalla kohdalla purkki oli ensin n. 6kk sisällä ja toimin hyvin. Siirsin purkin ulos viime keväänä (kiinni antenniputkeen katolle). Ja se toimi tosiaan hyvin aina syksyyn asti. Nyt purkki on taas ollut kuukauden sisällä ja ongelmat jatkuu. Ei mitenkään mahdotonta että kosteus olisi päässyt sisälle ja tehnyt tuhojaan. Korkit ja tiivisteet oli kaikki paikoillaan, kun laite oli ulkona kyllä.
 
Omalla kohdalla purkki oli ensin n. 6kk sisällä ja toimin hyvin.
Yhdessä kaupassa on Veikkauksen peliautomaatin ja ikkunan välissä sisäpuolella joku Zyxel. Mallista ei ole tietoa, kun noita on samannäköisessä kopassa useampia. Ei myöskään siitä, onko tuo Veikkauksen vai kaupan käytössä. Mutta veikkaisin ainakin kympillä sitä, että tuokin toimii moitteetta (ellei ole siihen jäänyt koristeeksi). Voisiko vastaavia asennuksia löytyä muualtakin
EDIT: Kyseessä siis Veikkauksen setuppi, injektorilla ja melko järeällä ulkoisella reititin/palomuurilla (tod.näk)
 
Viimeksi muokattu:
Mahtaakohan täälläkin kosteuden takia zyxel sekoilemaan? Tuon ollut aina ulkona räystään alla kylläkin. Masto on 400m päässä näköyhteys.
Nyt on muutaman kerran vrkssa hakenut uutta osoiteta ja saanut saman.
Alas paukuttaa vähän yli maksimia speedtestin mukaa download 100mbs spederan liittymä niin tulee jopa 112, mutta uppi on 1-2mbps. Puhelimella {op7t) 4gssä paukkuu täysiä 148/45.
 
Omalla kohdalla purkki oli ensin n. 6kk sisällä ja toimin hyvin. Siirsin purkin ulos viime keväänä (kiinni antenniputkeen katolle). Ja se toimi tosiaan hyvin aina syksyyn asti. Nyt purkki on taas ollut kuukauden sisällä ja ongelmat jatkuu. Ei mitenkään mahdotonta että kosteus olisi päässyt sisälle ja tehnyt tuhojaan. Korkit ja tiivisteet oli kaikki paikoillaan, kun laite oli ulkona kyllä.

Joskus lueskelin että perinteinen ethernetkaapeli päästää aikaa myöden kosteuden sisään ulkokäytössä. En tiedä pitääkö tuo paikkansa.

Itsellä on ulkokäyttöön tarkoitettua kaapelia tuossa. Samoin piuhassa sellainen lenkki että vesi valuu läpiviennistä hiukan alemmaksi...
 
Olisiko sim-lukijassa jotain kontaktihäiriötä, ilmankosteuteen liittyen? Sen kanssa kannattaa olla erittäin varovainen. Jos se hajoaa, koko laite on tietysti käyttökelvoton.
Speksien perusteella hieman epäilyttää, onko tuota oikeasti ulkokäyttöön edes suunniteltu: LTE7460-M608 4G LTE-A Outdoor Router | Zyxel

IP65 Enclosures

Operating Environment
  • Temperature: -40°C to 60°C (-40°F to 140°F)
  • Humidity: 5% to 95% (Non-condensing)

Eihän tuon kuulukkaan speksien mukaan kestää Suomen ilmastoa ulkona, koska ajoittain syhteellinen ilman kosteus on Suomessakin 100 prosenttia.
 
Eihän tuon kuulukkaan speksien mukaan kestää Suomen ilmastoa ulkona, koska ajoittain syhteellinen ilman kosteus on Suomessakin 100 prosenttia.

Missä maassa ilmakosteus ei ole ajoittain 100% esim vesisateella ?
Montako kosteuden vaurioittamaa laitetta on osunut vastaan?

Kun laite on jatkuvasti sähköissä kiinni niin se pitänee sisukset kuivana ainakin sen osalta ettei pelkkä ilmankosteus sitä tuhoa.

Oma laite on kestänyt 3.5v pihalla. Toki ei ole suorassa vesisateessa vaan räystään alla joka on toimivuuden kun puolesta parempi paikka kuin antennimasto. Antennimastossa tulee häiriöitä muista tukiasemista miltei 360 astetta joka puolelta. Räystäällä rakennus itsessään peittää osan "häiriöstä".

Ja alkuun ainakin jos käytössä on sisäkäyttöön tarkoitettua kaapelia niin ne vaihtoon. Kosteus menee kaapelin sisään tai ainakin riski siihen on olemassa. -> Selecting the Correct Outdoor Ethernet Cable

Ja missä se kaapeli nyt sitten kulkeekaan niin vara ei koskaan kaada venettä eli kaapeliin kannattaa jättää tuollainen lenkki vettä varten.
1608861190690.png
 
Viimeksi muokattu:
Vettä hörppäävää ethernet-kaapelia ei ole taidettu käsitellä tässä ketjussa, joten se on varteenotettava vikamahdollisuus. Tarkistakaa eth RX/TX-virheet modeemin suuntaan, joilla on ongelmia. Normaali nolla on tavoiteluku.
 
täällä on myös vesilenkit tehty ja kaapelikin ulkokäyttöön tehty.
tein juuri testiä parit buutit zyxelin kuikasta speedtestin tulokset 82/4 ja 87/2 ip vaihtui toisella kertaa.
ivo resetti minuutin verran sähköittä 74/43 (ip vaihtui)
harmi kun opnsense ei tokene yleensä tuosta ivoresetistä vaan vaatii ip haun tai buutin niin ajastaisin automaatti buutin tuolle home assistantista. viritin jo aikaa sitten wifi pistorasian perään näitä tilanteita varten :)
pingit on kyllä olemattoman huonot >28ms aina, kun vaikkapa oneplus 7t samassa kohtaa ja oletettavasti samasta mastosta välillä jopa 15ms
 
harmi kun opnsense ei tokene yleensä tuosta ivoresetistä
1) Teetkö ivo-bootin injektorille? 2) Onko opnsense kytketty suoraan injektoriin (ei kytkintä tms. välissä)? 3) Onko Zyxelissä sallittu kaikki bandit, joita se tukee?
 
pingit on kyllä olemattoman huonot >28ms aina, kun vaikkapa oneplus 7t samassa kohtaa ja oletettavasti samasta mastosta välillä jopa 15ms

Tuosta ei kannata olettaa mitään ellei katso cellidtä esim cellmapperin kartasta. Mullakin tuo purkki oli ainakin pari vuotta yhteydessä samaan mastoon mutta nyt syystä tai toisesta vaihtaa mastoa välillä. Mutta niin kauan kun tuo pelaa niin olkoot noin.
 
1) Teetkö ivo-bootin injektorille? 2) Onko opnsense kytketty suoraan injektoriin (ei kytkintä tms. välissä)? 3) Onko Zyxelissä sallittu kaikki bandit, joita se tukee?
1) juu injektorille ivoresetti.
2) kyllä, tai poesta menee esxi kortin yhteen porttiin joka on ainostaan opnsenselle tarjottuna vswitchin kautta.
3) on, tosin olen miettiny jos laittaisi vain nuo cellmapperin mukaan näkyvät.
 
Sain Zyxelin tuesta uudemman firmiksen 7460-laitteelle. Löytyy täältä:

Ei tietoa muutoksista tai muusta. Päiväys on Tue Apr 30 08:52:08 2019. Näyttäis toimivan omassa laitteessa. Tämä on siis tuen yritys korjata noita resettejä.
EDIT: _käyttö omalla vastuulla_! En tiedä mitä tuo on syönyt tai miten hyvin sen toiminta on validoitu.
 
Viimeksi muokattu:
Sain Zyxelin tuesta uudemman firmiksen 7460-laitteelle. Löytyy täältä:

Ei tietoa muutoksista tai muusta. Päiväys on Tue Apr 30 08:52:08 2019. Näyttäis toimivan omassa laitteessa. Tämä on siis tuen yritys korjata noita resettejä.
Oliko tuo B-sarjalainen jotain betafirmistä? C-sarjaa ainakin nuo julkaistut.
 
Mulla ei ole tietoa. Tuki jakoi tuon ilman saatesanoja.
Murossa oli aikoinaan B-sarjan firmistä jaossa ja on (vakaa) betaversio. C on sitten julkaisuversio.

 
Tämän LTE 7460:n osalta on kyllä ollut ihmeellinen tuo softatuki. Laite tullut myyntiin alkuvuodesta 2017 ja viimeisin jakoon asti ilmestynyt firmis joulukuulta 2017. Yhteensä (vain) neljä vakaata firmistä kyseiselle laitteelle julkaistu. Betafirmiksiä on yksittäiset asiakkaat saaneet tuesta ongelmia kohdatessa, mutta vaikea uskoa, että laitteen nykyfirmis olisi edes heidän mielestään niin bugivapaa ettei ole ollut tarvetta päivittää -> ftp://ftp.zyxel.co.uk/LTE7460-M608/firmware/

Ei siinä kohtuullisen vakaahan tuo (ABFR.4)C0 on,ainakin sillattuna, mutta kyllä tuossa on bugeja tullut vastaan. System log näyttää 99% käytännössä tyhjää, joskus tehnyt selittämättömiä boottauksia, Elisan verkossa ei osannut nostaa takaisin korkeimpia taajuuksia kun ne palasivat tukiasemasta virransäästön jälkeen käyttöön ja huonoilla signaaliarvoilla laite jäätyi aina välillä niin ettei muu kuin virtojen pois käyttäminen auttanut.

Tuo jäätymisongelma loppui kuin seinään kun alle 500m päähän tuli tukiasema ja signaaliarvot ovat mallia täydelliset, paitsi SNR joka heittelee 0-25 välillä aivan randomisti, mutta niin vaihteli huonossakin verkossa ja eri operaattorilla joten olen tullut siihen tulokseen, että firmiksessä kusee tuon arvon näyttäminen. Mitään pienintäkään vaikutusta ei ole ollut nopeuksiin tai viiveeseen, oli sitten SNR 0, 5 taikka 25.

Oma yksilöni keikkuu maston nokassa. Nykyisin ei olisi ehkä tarvetta kun tukiasema niin lähellä, mutta eipä siitä haittakaan ole. Toivo elää, että tuohon tukariin tulisi 5G niin sitten vaihtuu Zyxel saman mallisarjan 5G versioon jos vain tuo nykyinen 750€ riistohinta siitä laskee ~400-450€ tietämille.

2019-01-12 13.23.45 – kopio.jpg
 
Viimeksi muokattu:
Tämän LTE 7460:n osalta on kyllä ollut ihmeellinen tuo softatuki. Laite tullut myyntiin alkuvuodesta 2017 ja viimeisin jakoon asti ilmestynyt firmis joulukuulta 2017. Yhteensä (vain) neljä vakaata firmistä kyseiselle laitteelle julkaistu. Betafirmiksiä on yksittäiset asiakkaat saanet tuesta ongelmia kohdatessa, mutta vaikea uskoa, että laitteen nykyfirmis olisi edes heidän mielestään niin bugivapaa ettei ole ollut tarvetta päivittää -> ftp://ftp.zyxel.co.uk/LTE7460-M608/firmware/

Ei siinä kohtuullisen vakaahan tuo (ABFR.4)C0 on,ainakin sillattuna, mutta kyllä tuossa on bugeja tullut vastaan. System log näyttää 99% käytännössä tyhjää, joskus tehnyt selittämättömiä boottauksia, Elisan verkossa ei osannut nostaa takaisin korkeimpia taajuuksia kun ne palasivat tukiasemasta virransäästön jälkeen käyttöön ja huonoilla signaaliarvoilla laite jäätyi aina välillä niin ettei muu kuin virtojen pois käyttäminen auttanut.

Tuo jäätymisongelma loppui kuin seinään kun alle 500m päähän tuli tukiasema ja signaaliarvot ovat mallia täydelliset, paitsi SNR joka heittelee 0-25 välillä aivan randomisti, mutta niin vaihteli huonossakin verkossa ja eri operaattorilla joten olen tullut siihen tulokseen, että firmiksessä kusee tuon arvon näyttäminen. Mitään pienintäkään vaikutusta ei ole ollut nopeuksiin tai viiveeseen, oli sitten SNR 0, 5 taikka 25.

Oma yksilöni keikkuu maston nokassa. Nykyisin ei olisi ehkä tarvetta kun tukiasema niin lähellä, mutta eipä siitä haittakaan ole. Toivo elää, että tuohon tukariin tulisi 5G niin sitten vaihtuu Zyxel saman mallisarjan 5G versioon jos vain tuo nykyinen 750€ riistohinta siitä laskee ~400-450€ tietämille.

2019-01-12 13.23.45 – kopio.jpg
SINR arvon näyttämisessä tuskin on ongelmaa. Jos käyttöliittymän arvojen päivitysväli on vaikka 2 s niin mahdollisesti epästabiileissa olosuhteissa SINR voi olla tuon kahden sekunnin syklin sisällä mitä vaan, vaikkapa 0...30. Tarkempaan havainnointiin tarvitaan reaaliaikasoftaa.
 
SINR arvon näyttämisessä tuskin on ongelmaa. Jos käyttöliittymän arvojen päivitysväli on vaikka 2 s niin mahdollisesti epästabiileissa olosuhteissa SINR voi olla tuon kahden sekunnin syklin sisällä mitä vaan, vaikkapa 0...30. Tarkempaan havainnointiin tarvitaan reaaliaikasoftaa.

Mutta samalla saman operaattorin toisella liittymällä talon sisällä Huawein ja ZTE:n modeemilla testattuna SNR pysyy aikalailla samana koko ajan, vaihtelu ihan 1-5 arvon välillä. Tiedä sitten ottaako Zyxel niin kovasti häiriötä jostain, mutta ei toisaalta ole hirveästi jaksanut edes kiinnostaa, koska yhteyteen ei ole ollut ainakaan mitään näkyvää merkitystä.
 
kerrohan @ghostio kokemuksia sitten tuosta. oma sillattuni sekoilee välillä että tekisi mieli kokeilla mutta jos ei toimi niin kai siihen tuon viimeisen saa päälle flässättyä.
 
Ite pistin ghostion firmiksen samantien sisään. Ilmoittelen tuloksista.

EDIT: Ainakin 14h nyt pysynyt yhteydessä. Tämä firmis näköjään näyttää tornin Cell identifier numeron jotenkin ihmeellisesti tyyliin "0x97814"
 
Viimeksi muokattu:
Ei apua ainakaan omiin resetteihin. Yön ja aamun aikana tullut muutama reset:

Koodi:
 04:42:04 up 12:25,  0 users,  load average: 4.34, 4.20, 4.21
ssh: connect to host 192.168.1.1 port 22: Network is unreachable
04:44:04 up 1 min,  0 users,  load average: 3.36, 1.09, 0.38
...
10:00:24 up  5:17,  0 users,  load average: 4.47, 4.46, 4.49
ssh: connect to host 192.168.1.1 port 22: Network is unreachable
10:02:41 up 1 min,  0 users,  load average: 4.40, 1.51, 0.54
...
11:08:56 up  1:07,  0 users,  load average: 4.32, 4.36, 4.39
ssh: connect to host 192.168.1.1 port 22: Network is unreachable
11:10:57 up 1 min,  0 users,  load average: 3.31, 1.08, 0.38
...
11:26:00 up 16 min,  0 users,  load average: 4.33, 4.27, 2.88
ssh: connect to host 192.168.1.1 port 22: Network is unreachable
11:28:00 up 1 min,  0 users,  load average: 3.33, 1.10, 0.39

Kyselen siis ssh:n yli purkin uptimen minuutin välein. Tuossa vain kiinnostavat osat.
 
Katsoin ihan samaa: Load lukemien mukaan reititin on yli 300% ylikuormitettu, eli prosessit joutuvat odottamaan vuoroaan, eikä laite ole voinut idlata lainkaan minuutin, 5 minuutin eikä 15 minuutin aikana.
 
top:n mukaan laitteella ei pyöri juuri mikään, et en ihan ymmärrä et mistä nuo lukemat tulee.
Koodi:
top - 12:38:04 up  1:11,  1 user,  load average: 4.25, 4.26, 4.38
Tasks: 100 total,   1 running,  99 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.4 us,  4.4 sy,  0.0 ni, 90.8 id,  0.0 wa,  0.0 hi,  3.4 si,  0.0 st
KiB Mem :   164488 total,    65548 free,    27380 used,    71560 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   125315 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND           
 4884 admin     20   0    3088   1092    792 R 22.2  0.7   0:00.07 top               
    1 admin     20   0    1712    544    480 S  0.0  0.3   0:02.80 init             
    2 admin     -2   0       0      0      0 S  0.0  0.0   0:00.00 kthreadd         
    3 admin     20   0       0      0      0 S  0.0  0.0   0:13.84 ksoftirqd/0       
    5 admin      0 -20       0      0      0 S  0.0  0.0   0:00.00 kworker/0:0H     
    7 admin     20   0       0      0      0 S  0.0  0.0   0:02.87 rcu_preempt       
    8 admin     20   0       0      0      0 S  0.0  0.0   0:00.00 rcu_bh           
    9 admin     20   0       0      0      0 S  0.0  0.0   0:00.00 rcu_sched         
   10 admin      0 -20       0      0      0 S  0.0  0.0   0:00.00 khelper           
   11 admin     20   0       0      0      0 S  0.0  0.0   0:00.25 kworker/0:1       
   12 admin      0 -20       0      0      0 S  0.0  0.0   0:02.81 kworker/0:1H
 
$ df
$ top -d 60

Odota vähintään minuutti, että top päivittää toisen kerran
 
$ df
$ top -d 60

Odota vähintään minuutti, että top päivittää toisen kerran

Alla. Seurasin joskus myös muistinkäyttöä ja siinä ei näkynyt mitään muutosta useampien päivien aikana.

Jos pistän esim. speedtestin päälle, niin muutama kworker alkaa käyttämään 5-15% CPU:ta ja heti testin jälkeen palaa takaisin 0%.

Koodi:
admin@LTE7460:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
ubi0:rootfs              62728     43220     19508  69% /
tmpfs                    82244        84     82160   0% /run
tmpfs                    82244       416     81828   1% /var/volatile
tmpfs                    82244      3788     78456   5% /dev
tmpfs                    82244       416     81828   1% /var/lib
ubi1:data               168364       276    163252   0% /data
overlayfs                82244        84     82160   0% /etc
overlayfs                82244        84     82160   0% /lib/firmware
overlayfs                82244        84     82160   0% /system
overlayfs                82244        84     82160   0% /www/pages
overlayfs                82244        84     82160   0% /usr/share
overlayfs                82244        84     82160   0% /var/db
ubi0:modem               29148     29148         0 100% /firmware

top - 13:09:23 up  1:42,  1 user,  load average: 4.24, 4.40, 4.46
Tasks: 100 total,   1 running,  99 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.1 us,  1.6 sy,  0.0 ni, 97.1 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem :   164488 total,    65684 free,    28004 used,    70800 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   125623 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND           
 1320 admin     20   0    7008   1600   1232 S  1.0  1.0   1:12.17 mald             
  730 admin     20   0   22040   4364   1760 S  0.7  2.7   0:53.50 malmanager       
   15 admin     20   0       0      0      0 D  0.6  0.0   1:35.46 kworker/u2:1     
 7771 admin     20   0       0      0      0 S  0.5  0.0   0:04.47 kworker/u2:3     
 7460 admin     20   0       0      0      0 S  0.4  0.0   0:13.81 kworker/u2:5     
 7906 admin     20   0       0      0      0 D  0.2  0.0   0:00.14 kworker/u2:0     
    7 admin     20   0       0      0      0 S  0.1  0.0   0:04.31 rcu_preempt       
   16 admin      0 -20       0      0      0 D  0.1  0.0   0:03.73 kworker/u3:0     
 7883 admin     20   0    3088   1172    856 R  0.1  0.7   0:00.16 top               
    3 admin     20   0       0      0      0 S  0.0  0.0   0:17.57 ksoftirqd/0       
   12 admin      0 -20       0      0      0 S  0.0  0.0   0:04.43 kworker/0:1H     
   59 admin     20   0       0      0      0 S  0.0  0.0   0:02.57 kworker/0:2       
  752 admin     20   0    1732    504    452 S  0.0  0.3   0:02.41 systemui
 
Juuri noissa kworker+mald+malmanager näkyy iso epäsuhta %CPU:n ja kokonaisajoajan (TIME h:mm:ss)/uptime -suhteen välillä.
Olisiko jatkuvasti kovaa keskeytyskuormaa modeemilta cpu:lle

EDIT: Vai voisiko tuo TIME olla sittenkin yksikössä m:ss.ss
EDIT2: On se
 
Ilmeisesti systeemin load average näyttää niin isolta, koska siinä on mukana D-tilassa olevia prosesseja (busy-looppaavat ja odottavat modeemia). Eihän varsinkaan siltaavassa tilassa olevalla CPU:lla ole muutakaan järkevää tekemistä kuin kuljettaa dataa modeemilta ethernetiin ja päinvastoin
 
$ last -x

Näyttääkö tuo minkälaista listaa, ovatko shutdownit hallittuja vai ei
 
$ last -x

Näyttääkö tuo minkälaista listaa, ovatko shutdownit hallittuja vai ei

Hiljaista on.
Koodi:
admin@LTE7460:~# last -x

wtmp begins Fri Jan  2 05:51:03 1970

Koko systeemi (poislukien /data) näyttäis olevan ro-moodiin mountattu. Ei taida juuri mikään normaali linux-kama säilyä resetin yli.
Koodi:
admin@LTE7460:/# mount
ubi0:rootfs on / type ubifs (ro,relatime,bulk_read)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /var/volatile type tmpfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
tmpfs on /var/lib type tmpfs (rw,relatime)
ubi1:data on /data type ubifs (rw,relatime)
overlayfs on /etc type overlayfs (rw,relatime,lowerdir=/etc,upperdir=/run/etc)
overlayfs on /lib/firmware type overlayfs (rw,relatime,lowerdir=/lib/firmware,upperdir=/run/firmware)
overlayfs on /system type overlayfs (rw,relatime,lowerdir=/system,upperdir=/run/system)
overlayfs on /www/pages type overlayfs (rw,relatime,lowerdir=/www/pages,upperdir=/run/pages)
overlayfs on /usr/share type overlayfs (rw,relatime,lowerdir=/usr/share,upperdir=/run/share)
overlayfs on /var/db type overlayfs (rw,relatime,lowerdir=/var/db,upperdir=/run/db)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
ubi0:modem on /firmware type ubifs (rw,relatime)
 
Näkisikö mitään, jos jättäisi ssh-yhteyden päälle ja odottaisi seuraavaa boottia
$ dmesg -w
 
Kokeilin tuota joskus, mutta mielestäni siihen ei jäänyt mitään. Voin kyllä kokeilla uudestaan.
 
Pystyyköhän tuon watchdogin stoppaamaan? Silloin jos laite jää jumiin, niin se ei resetoi omia aikojaan. Ei tuo tietenkään muuta todista kuin sen, että siinä tapauksessa softa vaan jumahtaa jossain kernel-driverissa ehkä. Pitäisi saada kernelistä pakotettua dumppeja, että näkisi missä se jumii, ja tämä vaatii symbolit (ja sourcet).

Kernel oli aika vanha, ja jossain 3.x -sarjalaisessa oli aikoinaan work queue -bugi, joka aiheuttaa jumeja.
 
Minulla huhtikuussa 2020 Verkkokaupasta ostettu lte7460. Laite (asennettu talon katolle) toimi loistavasti (sama ip parhaimmillaan 1.5kk) marraskuun puoliväliin saakka, mutta tämän jälkeen ip ruvennut vaihtumaan useamman kerran päivässä ja laite boottailee itseänsä. Elisan mukaan tukiasemassa (~300m päässä, erinomainen signaali) ei ongelmia / viimeaikaisia muutoksia. Sain Zyxelin tuesta tuon yllä linkatun beta-firmiksen, mutta sen asentamisella ei mitään vaikutusta. Sama SIM Huawein purkissa ei aiheuta vastaavaa pätkimistä. Testasin myös Telian liittymällä. Sama lopputulos.
 
Testasin myös Telian liittymällä. Sama lopputulos.
Vähän tulee taas ympäristöolosuhteet mieleen yhtenä vaihtoehtona, kun moni muu asia on poissuljettu tai ainakin epätodennäköinen.
Onko ethernet-kaapeli ulkokäyttöön tarkoitettua? Oletko sattunut kokeilemaan toista soveltuvaa injektoria?
 
@mikajh käyttämäni ethernet-kaapeli on ulkokäyttöön tarkoitettu. Olen testannut välipäivät laitetta myös sisätilassa, ei vaikutusta (tosin signaali sisällä myös heikompi). Toista injektoria en ole kokeillut.
 
Mä olen kokeillut kahta eri injektoria. Ei vaikutusta ainakaan omalla kohdalla. Kokeilin myös pitää laitetta UPS:n takana, mutta siitäkään ei ollut mitään apua.
 
Joskus aikoinaan USB:sta virran saavat mokkulat kärsivät virran vähyydestä joka sai ne boottaamaan.
Tämän LTE7460:n ja LTE7490 injectoreissa oli hiukan eroa tehoissa, 48V 0,35A vs 0,5A.
 
Itsellä hävisi kaikki jumit ja ongelmat, kun laitoin erillisen reitittimen Zyxelin perään kiinteällä IP:llä. Zyxel edelleen reitittävänä, koska ei ole julkista IP:tä, niin reitittimelle näkyvän osoitteen vaihtumisesta olisi todennäköisesti enemmän haittaa kuin hyötyä.

Aiemmat ongelmat liittyivät aika selkeästi DHCP:n toimintaan, laitteet ei saaneet aina IP-osoitetta.
 
Itsellä hävisi kaikki jumit ja ongelmat, kun laitoin erillisen reitittimen Zyxelin perään kiinteällä IP:llä. Zyxel edelleen reitittävänä, koska ei ole julkista IP:tä, niin reitittimelle näkyvän osoitteen vaihtumisesta olisi todennäköisesti enemmän haittaa kuin hyötyä.

Siltaavaksi se Zyxel ja vauhdilla :hammer: vai onko reititin vain AP modessa? Jos ei ole niin sitten ei ole mitään syytä pitää Zyxeliä reitittävässä tilassa. Ei se julkinen tai ei-julkinen IP sotke mitenkään.
 
Siltaavaksi se Zyxel ja vauhdilla :hammer: vai onko reititin vain AP modessa? Jos ei ole niin sitten ei ole mitään syytä pitää Zyxeliä reitittävässä tilassa. Ei se julkinen tai ei-julkinen IP sotke mitenkään.
Muutama vuosi sitten oli toisaalla ongelma, että sillatun Zyxelin perässä oleva reititin vaati bootin, jos julkinen IP vaihtui. Eli en näe mitään hyötyä sillata Zyxeliä, kun se siltauskin on aika viritelmän näköinen kun katsoo niitä skriptejä Zyxelin firmiksessä.
 
Ainakin itsellä on käynyt mielessä että tuossa omassa zyxelissä aihettaa jotenkin ongelmaa juurikin se DHCP client puoli eli IPn saanti operaattorilta, vaikka oma purkki on siltaavassa tilassa. Tuo Zyxelin siltaus ei sitten ole puhdas siltaus vaan jonkinlainen IP sharing tyyppinen ratkaisu sillä jos Zyxelissä on etähallinta päällä pääsee laitteen hallintaan kiinni internetistä vaikka laite olisikin sillatustta tilassa.
 
Ainakin itsellä on käynyt mielessä että tuossa omassa zyxelissä aihettaa jotenkin ongelmaa juurikin se DHCP client puoli eli IPn saanti operaattorilta, vaikka oma purkki on siltaavassa tilassa. Tuo Zyxelin siltaus ei sitten ole puhdas siltaus vaan jonkinlainen IP sharing tyyppinen ratkaisu sillä jos Zyxelissä on etähallinta päällä pääsee laitteen hallintaan kiinni internetistä vaikka laite olisikin sillatustta tilassa.
Tietääkseni mobiiliverkon yli IP ei tule DHCP:llä, vaan verkon signaloinnista. Tästä tulee yhden IP:n liittymäkohtainen rajoitekin. Zyxelin oma DHCP-serveri sitten jakaa tuon operaattorin IP:n sillatussa tilassa eteenpäin. Ja jos Zyxelin DHCP serveri jumittaa välillä, varmin ratkaisu on omien päätelmien mukaan kiinteä IP. Saatan olla väärässäkin.
 
Tietääkseni mobiiliverkon yli IP ei tule DHCP:llä, vaan verkon signaloinnista. Tästä tulee yhden IP:n liittymäkohtainen rajoitekin. Zyxelin oma DHCP-serveri sitten jakaa tuon operaattorin IP:n sillatussa tilassa eteenpäin. Ja jos Zyxelin DHCP serveri jumittaa välillä, varmin ratkaisu on omien päätelmien mukaan kiinteä IP. Saatan olla väärässäkin.
Oman kokemuksen mukaan tuossa jumii joku muu kuin pelkkä dhcp serveri koska tuonhan pitäisi vastata sillatussa tilassa myös "sisäverkon" hallinta ip:hen ja ainakin oma kun on jumissa niin se ei näin tee.
 
Oman kokemuksen mukaan tuossa jumii joku muu kuin pelkkä dhcp serveri koska tuonhan pitäisi vastata sillatussa tilassa myös "sisäverkon" hallinta ip:hen ja ainakin oma kun on jumissa niin se ei näin tee.
Aivan, oman jumittaessa tosiaan avoimet yhteydet pelaa, mutta uudet laitteet eivät saaneet IP:tä eli varmaan eri "ominaisuus" kyseessä.
 

Statistiikka

Viestiketjuista
259 342
Viestejä
4 509 977
Jäsenet
74 355
Uusin jäsen
anomuumi

Hinta.fi

Back
Ylös Bottom