Turris 1.0 naprosto rozsypaný, takto rozbít se povedlo naposled minulý rok pŕed vánoci.
Zkoušel jsem návrat schanpps rollback ale žádný snapshot nefunguje správně a wifi už vůbec nenaběhne, updater havaruje naprosto pokaždé. Nefunguje mi teď doma vůbec nic, ani drátová síť se nedostane na internet. Jsem z toho zoufalý a navíc teď před vánoci vůbec nemám čas se v tom hrabat a zkoušet to rozběhnout když to zrovna nejvíc potřebuji.
Udělejte rollback na nějakou dřívější zálohu, pak restart a ve Forisu si zakažte aktualizace, pravděpodobně máte nainstalovaný nějaký svůj balíček, (nebo někým jiným zkompilovaný) a nedoběhla vám aktualizace.
Mě pomohlo všechny tyto balíčky odebrat, nechat jen to od turris teamu, pak aktualizace proběhla bez problému.
Projděte forum, vše co popisujete se tu už řešilo.
Odstranil jsem unison, links, tree a updater doběhl zdá se OK. Jestli najede síť zjistím až dorazím domů ale spíš to vypadá že wlan rozhraní neexistují protože se mi přes wifi nepřipojil žádný telefon tablet co je doma… Jak nakonfiguruji uživatelské balíčky aby se toto již příště nestalo, v diagnostice vidím chybu ERROR(“No /etc/opkg/customfeeds.conf file. No opkg feeds are included.”) také přestal fungovat OpenVPN server v diagnostice chyba2017-12-14T12:59:54+01:00 err openvpn(server_turris)[5353]: ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
2017-12-14T12:59:54+01:00 notice openvpn(server_turris)[5353]: Exiting due to fatal error opakovaně.
Při pokusu otevřít wifi záložku ve forrisu chyba
An unexpected error has occurred
We are sorry, but your request raised an unexpected error. More information about this error may be found below.
If you are willing to help us with fixing of the problem, download the following error protocol and send it to us with a short description of the steps that led to the error to our email address tech.support@turris.cz (the protocol contains only a copy of the following informations).
Při zpracování požadavku došlo k chybě
Omlouváme se, ale během zpracování Vašeho požadavku došlo k nečekané chybě. Detailní informace naleznete níže.
Pokud nám chcete pomoci s odstraněním chyby, stáhněte následující protokol o chybě a zašlete nám jej s krátkým popisem okolností vzniku chyby na adresu tech.support@turris.cz (protokol obsahuje pouze kopii informací uvedených na této stránce).
RPCError(‘Command to get wireless-cards failed with code 256 and stderr nl80211 not found.\n’,)
Stack trace
Já musel natvrdo odpojit router od napájení, vše na USB nejelo.
No, budu vám držet palce.
Tak povedlo se updatovat poté co jsem provedl přesně to co jste radil, provedl jsem schnapps rollback, odebral jsem balíčky unison, links, tree, zakázal aktualizace, spustil updater a prošlo to. Problém byl nejspíš v tom že jsem se pokoušel pouště updater vždy poté co jsem odebral jeden balíček postupně zřejmě se tak něco mezitím rozbilo a i když pak updater konečně doběhl bez chyb tak wifi ani routování wan 2 lan nefungovalo. Tahle zmršenou aktualizaci sem nezažil od wifi gate v prosinci minulého roku. Nenapadlo by mne že instalace custom build balíčků, které nemají s funkčností routerů vubec nic společného se dá úplně rozbít celý turris.
Nějak nevím co bych k tomu dodal… 
1 Like
Tohle bych neoznačil ani za workaround… Na vlastních balíčcích jsem v podstatě závislý. Zatím jsem při jednom z minulých updatů jen (ručně) opravil syntaxi v .lua, aby byla aktuální.
Opravdu se těším, jestli někdy za pár let bude to LEDE/wrt… Přijde mi, že problémy jsou čistě jen s nádstavama nad tím (málo lidí na vývoj, testování, odladění).
Úplně nejlepší by byly dvě větve. Čistá, openwrtovská, o kterou by se v podstatě NIC nemusel starat… Tam by vše fungovalo, a security updaty by určitě vycházely včas. A druhá, NICovská, kde by mohli dávat svoje Forisy, honeypoty, majordoma, kresdy, knoty apod. nádstavby pro uživatele, kteří by je využívali.
Možná, že by se ten workload snížil výrazně i po přičtení nákladu práce na udržování dvou větví… V cílovém segmetu lidí, kteří chtějí STABILNÍ základ, a s custom nádstavbama si poradí sami bude tipuju hodně…
Já teda zatím žiju víceméně bez problémů, od začátku s vyplýma aktualizacema s tím, že ale musím aktuálně sledovat forum. Aktualizuju, jen když jde o nějaké CVE (aspoň se šetří flash). Co mě až tak nebaví, je neustálé hlídání co se kde rozbilo, abych to případně ručně doupravil.
Ten vývoj a realizace poměrně kvalitního HW by si zasloužil trochu opravit pošramocenou pověst, “čistá” verze softu by tomu pomohla, a i HW by koupilo o dost víc lidí globálně, kdyby vědělo, že tam to OpenWRT běží po másle…
Jen čistě můj názor, vývojářům držím palce.
P.S.: Zatím jedu na 3.8.4, a vzhledem k tomutu Known bugs in Turris OS 3.9 and recommended solutions se do vyšších verzí bohužel opravdu nepohrnu.
Úplně nejlepší by byly dvě větve. Čistá, openwrtovská, o kterou by se v podstatě NIC nemusel starat… Tam by vše fungovalo, a security updaty by určitě vycházely včas. A druhá, NICovská, kde by mohli dávat svoje Forisy, honeypoty, majordoma, kresdy, knoty apod. nádstavby pro uživatele, kteří by je využívali.
Mám takový pocit, že zas tak jednoduché to nebylo 
1 Like
Já bych vydal další číslo korporátních Turris news … dobrá nálada se musí udržovat, i kdyby na chleba nebylo!
1 Like
BTW: když jsem vyřešil problémy s kernelem (spustil hook) a pro jistotu odinstaloval unison, nechal plně projet update a zase zpátky nainstaloval unison - můžu restartovat, nebo raději počkat? 
Turris 1.0 na VDSL šlape po update dobře 
Díky moc za ten Netstat 
Jen jsem teda po update zrušil Majordomo a toto na mě vyskočilo, mám to prosím nějak řešit? Nebo je to ok?
Po aktualizaci na 3.9 a kontrole zmizel otevřený port 22 - (kontrola z WAN pomocí webu https://www.grc.com/.) Zřejmě to souvisí s avizovanou jinou funkcí a exportem do Haas.
Ale …
-
to že nevidím otevřený port je v pořádku ?
-
Jak naložit s existujícím přesměrováním ?
Turris Honeypot
IPv4-tcp Z libovolný hostitel v wan Via libovolná IP routeru at port 22
libovolný hostitel, port 58732 v lan
1 Like
PaKon mi neprodukuje ziaden vystup
nechal som to aj cez noc a teraz je na routri aktivita.
Mě také zmizel vnější port 22 a Telnetem se tam samozřejmě nepřipojím. To znamená, že HaaS klient nefunguje - data na HaaS serveru také žádná nejsou. Před aktualizací mé Omnie na verzi 3.9 byl Honeypot plně funkční…
Tak jsem problém vyřešil. Zase byla problémem žádná dokumentace a typická polovičatá práce NIC.cz.
Předchozí Honeypot vyžadoval uživatelsky definovaný PortForwarding portu 22 na interní port Honeypotu. HaaS proxy si naopak vytváří přesměrování sám, pokud ovšem port 22 není uživatelsky přesměrován 
Prostě smažte/zneplatněte uživatelské přesměrování portu 22 a restartujte službu haas_proxy.
Zkusil jsem se připojit telnetem haas a je extrémně pomalý - odezva na odeslané příkazy minimálně 1-2s.
1 Like
To samý. Ale při instalaci to hlásilo chyby. Tuším něco s IPtables. Neměl jsem na to moc času, tak jsem to, zatím, neřešil. Asi zkusím deinstalaci balíšku a jeho reinstalaci a podívám se na to, co to hlásí.
Aha, tak se to řeší ve vlákně: Známé chyby v Turris OS 3.9 a doporučená řešení
Ano, potvrzuju, odezva je pomalejší.
A nechápu proč není nikde uvedeno, že původní přesměrování 22 -> 58732 je nutné smazat, protože samo se nesmaže.
3 Likes
protože NIC. Žádný jiný argument mě nenapadá
1 Like
Přitom by stačilo pár řádek do dokumentace.