Po restartu mi nenabehl Turris omnia uplne a zustal v nejakem mezikroku (nenabehly skoro zadne sluzby, openvpn, port forwarding, LXC etc) kde byl pristupny port 80 z WANu … ikdyz by tento port mel byt uzavreny pro WAN…
pres WAN fungoval Foris i Luci takze se mi povedlo ho restartovat znovu a pak uz nabehl v poradku.
je bezne ze v urcitem okamziku kdyz TO startuje je volne pristupna pres WAN rozhrani?
To rozhodně není běžné, jediná možnost co vím že toto nastává je, když k aktuálně běžícímu kernelu nejsou k dispozici správně moduly. V takovém případě nenaběhne firewall. Jen na Omnii taková situace moc nemá jak nastat.
Pokud se Vám to podaří zreprodukovat zbovu, je možné nám zaslat diagnostiky?
Já zase mám zkušenost, že když bootuje Omnia, je dočasně WAN port jako LAN a po naběhnutí ovladače (nevím přesně který, je to moc rychlé - asi tenhle Marvell 88E6176) se porty správně seřadí.
Je to opravdu neobvyklé a vzácné, narazil jsem na tento fakt při mé úplné degradaci bootu, tzn. musel jsem provést kroky, které vedou na připojení přes seriovou linku, povolení TFTP a přenosů zImage souborů (jako tomu je v případě OpenWrt). Abych mohl komunikovat přes TFTP, je potřeba přehodit RJ45 konektor z LAN do WAN a pak to jde.
Podle mého takový dopad na bezpečnost při bootu je opravdu zanedbatelná, protože aby někdo mohl komunikovat při boot procesu, musí se nejprve napojit na seriovou linku a do 5s musí stisknout jakékoli tl. aby se boot zastavil a mohl komunikovat. I když je boot v degradaci, jiná možnost stejně není, aby mohl nějak Omnii ublížit (či získat nějaké informace), musí se napojit na seriovou linku a zadat patřičné příkazy - jinak to nejde.
EDIT: správně ještě doplním, že to nemá nic společného s problémem od @jork.
Výchozí konfiguraci switche kde vše vede do lan mohu potvrdit. Problém je v architektuře swconfig a to, že konfigurace naskočí až v průběhu bootu. Toto se mění s DSA.
Na druhou stranu musím popřít vaše tvrzení, že se vám to děje s WAN portem. Ten nevede přes switch a vede přímo do CPU. Je přímo nastaven do zóny wan. V lan bridgi se prostě neobjeví.
Prováděl jsem “Method 2 - TFTP with serial”: [OpenWrt Wiki] toh:turris_cz.nic:turris_cz.nic_omnia
Kdyby tomu tak nebylo, proč tedy musím přehazovat RJ45 z LAN do WAN?
Co prosím? V tom případě se asi jedná o chybu konfigurace v OpenWRT.
Na desce je wan port přímo do cpu. Pokud konfigurace neřekne, že má být součástí lan bridge tak součástí lan nebude. S tím nemá switch co dělat. V Turris OS taková konfigurace není, nemohu mluvit za OpenWRT.
Edit: už chápu. Pletete si co se děje. U-boot na Omnii neumí pracovat se switchem a swotch je vypnutý. Není tedy možné bootovat přes tftp přes switch. Je nutné použít wan port omnie. Nechápu kde jste se spletl, ale přesně ten důvod proč strkáte rj-45 do wan je proto, že nevede přes switch. 
Víceméně si to můžete zkusit - za mě: opravdu tento postup funguje, takže tomu tak je. Mám (měl jsem, jednu jsem prodal) dvě Omnie, jednu s 1GB RAM, druhou s 2GB RAM, u obouch postup funguje a funguje oboustranně: nejenom pro nahrání OpenWrt, ale i při obnově Turris OS - jinak řečeno: tento postup mi zachráníl Omnii a mám znovu TOS(4 beta).
Ano funguje. To nemusím zkoušet. Takhle pouštíme testy. Přijde mi, že se nechápeme a hlavně, že to co popisujete není vůbec problém na který naráží @jork.
Ano, já tomu říkám “… mezi židlí a klávesnicí…”. Z mé strany to byla jenom zmínka mých postřehů, kdyby na to někdo třeba přišel. A pravděpodobně to nebude ten případ od @jork.
nevim jak tento problem zreprodukovat, nebot jsem dal jen po delsi dobe restart TO a krom pokusu s schnapps export (ktery mi vyexportuje pouze par prvnich obrazu a zbytek zahlasi chybu) jsem nic jineho nedelal. bohuzel ani zaslani logu bych nevedel jak udelat neb mam TO par tisic km daleko 
a jelikoz ma byt co chvili Turris OS4 tak snad to bude uz v poradku 
Ehm… tohle se většinou děje protože začíná selhávat interní flesh paměť. Nové snapshoty bývají poškozeny a někdy update projde, ale některé soubory se neaktualizují. To by vysvětlovalo stav kdy máte neshodu mezi kernel verzí a moduly. Nechci Vás ale strašit, nemusí to být ono. Jen si pro jistotu zkontrolujte jestli se Vám systémový log neplní hlášeními o timeoutech z btrfs a chybách btrfs.
V systemovem logu (pokud to je ten v Luci / Status / System Log) nemam nic o timeoutech z btrfs (jedine netdata spatne neco cte … viz…err netdata[6933]: BTRFS: failed to read ‘/sys/fs/btrfs/3009dff1-fd4f-4b45-a942-35a55aca3ed6/allocation/data/total_bytes’ ).
nicmene pak by me zajimalo jak bez fyzickeho pristupu k routeru prehodim system z interni flash na SSD (ktery mam jiz pripojen a vyuzivan na /srv) … a stejne takovou operaci nezvladnu ani kdybych mel router u sebe
Ajaj, takže nějaké chyby s BTRFS jsou. Toto téma jako netdata … BTRFS: failed to read … je rozebírané dost často ̶a̶ ̶j̶e̶ ̶t̶o̶ ̶z̶ ̶d̶ů̶v̶o̶d̶ů̶ ̶p̶o̶u̶ž̶i̶t̶í̶ ̶b̶a̶l̶í̶č̶k̶u̶ ̶N̶e̶t̶d̶a̶t̶a̶ ̶n̶a̶ ̶v̶n̶i̶t̶ř̶n̶í̶ ̶F̶l̶a̶s̶h̶ ̶p̶a̶m̶ě̶t̶i̶.̶
Jako první začněte zde:
Pak převeďte LXC, aby plně využíval extérní uložiště (jestli již není pozdě, na SSD), z návodu zde:
(možná bude zapotřebí provést scan a repair BTRFS uložiště: Manpage/btrfs-check - btrfs Wiki)
a ještě zkuste provést příkaz a zeptat se Turis Týmu, jestli není před koncem životnosti eMMC:
cat /sys/block/mmcblk0/stat | awk '{print $7}'
(zdroj: Chyby, které vedou k nefunkčnosti připojení - #35 by cynerd - SW pomoc [CZ] - Turris forum, ale zde jste se již aktivně podílel v předešlých příspěvcích)
Myslim si, že ta Vase proaktivita by mohla být občas na skodu.
Koukal jste se na jak funguje Netdata, případně na konfigurační soubor, který se nachází na http://192.168.1.1:19999/netdata.conf , pokud Netdata máte nainstalovanou a spuštěnou? Zjistil byste, že logy, cache, lib a další se zapisují do /var. Tedy do operační paměti a tedy po restartu zařízení jsou data pryč. Co se uchová jsou 3 veci. Konfiguraky v /etc/netdata, binarka v /usr/sbin a web v /usr/share/netdata. Takže by mě velmi zajímalo jak jste dostal k tomuto závěru.
Harmless. Znamená to pouze že Netdata nemůže přečíst daný soubor.
Byla myšlena chyba např.
2019-04-03 12:32:44 warning kernel: [ 1715.417882] BTRFS warning (device mmcblk0p1): csum failed ino 9886 off 393216 csum 1000242804 expected csum 2049996767
případně jiná obdobná.
Je tedy na tento problem nejake reseni? kdyz si totiz nevsimnu hned ze se mi router sam restartoval, tak nezjistim ze jsou porty otevrene volne do internetu a je hned TO vice zranitelna bych rekl.
interni pamet vypada v poradku,
vypadky napeti nejsou (vse je na nove UPS)
volneho mista na interni pameti je take jeste kolem 5GB
nebezi tam nic extra narocneho co by potrebovalo onech 2GB ram