Forum Turris
Fórum Turris Nápověda

Milí majitelé routerů Turris,

toto fórum bylo 9. 12. 2016 zmrazeno a nahrazeno naším novým Turris fórem. Ještě chvíli bude dostupné k prohlížení, ale již zde není možné přispívat. Více informací naleznete v oznámení o uzavření fóra.


Dear Turris routers users,

this forum has been frozen on Dec 9th, 2016 and replaced by our new Turris forum. It will be read-only accessible for some time after. For more information, read the announcement about closing the forum.

Nahoru Téma Majitelé routerů / Technická podpora / lm90 register read failed
- - Od MJ Dne 2016-05-31 10:43
Milí turristé,

po upgradu na verzi 3.0 mi jednak také přestal fungovat ucollect (ale to už se řeší o vlákno vedle), ale také mám plný kernelový log těchto hlášek:

2016-05-31T11:10:31+02:00 warning kernel[]: [372677.208426] lm90 0-004c: Register 0x6 read failed (-5)
2016-05-31T11:10:33+02:00 err kernel[]: [372679.216430] rtc-ds1307 0-006f: read error -5
2016-05-31T11:10:34+02:00 warning kernel[]: [372680.220442] lm90 0-004c: Register 0x5 read failed (-5)
2016-05-31T11:10:36+02:00 err kernel[]: [372682.228439] rtc-ds1307 0-006f: write error -5

(perioda cca jednotky sekund)

Potkali jste s tím také někdo? Tušíte, proč se to děje?
Nadřazený - Od Jan Čermák (>>) Dne 2016-06-02 08:07
Setkal se s tím ještě jeden uživatel, od kterého se snažíme získat nějaké další informace. Vypadá to na problém na I2C sběrnici (projevuje se to také neodesíláním dat, protože pak nefunguje komunikace s ATSHA). Proběhl ve Vašem případě po aktualizaci restart zařízení, případně všechny restarty (možná jsou totiž potřeba dva - jeden pro aktualizaci procd, druhý pro zavedení nového kernelu)?
Nadřazený - Od fojtp Dne 2016-06-02 10:21 Upraveno 2016-06-02 10:23
taky to tam mam:

2016-06-02T11:20:11+02:00 warning kernel[]: [758991.170945] lm90 0-004c: Register 0x5 read failed (-5)
2016-06-02T11:20:13+02:00 warning kernel[]: [758993.178935] lm90 0-004c: Register 0x20 read failed (-5)
2016-06-02T11:20:15+02:00 warning kernel[]: [758995.186937] lm90 0-004c: Register 0x19 read failed (-5)
2016-06-02T11:20:17+02:00 warning kernel[]: [758997.194930] lm90 0-004c: Register 0x21 read failed (-5)
2016-06-02T11:20:19+02:00 warning kernel[]: [758999.202930] lm90 0-004c: Register 0x0 read failed (-5)
2016-06-02T11:20:21+02:00 warning kernel[]: [759001.210933] lm90 0-004c: Register 0x1 read failed (-5)
2016-06-02T11:20:23+02:00 warning kernel[]: [759003.218936] lm90 0-004c: Register 0x8 read failed (-5)
2016-06-02T11:20:25+02:00 warning kernel[]: [759005.226933] lm90 0-004c: Register 0x7 read failed (-5)
2016-06-02T11:20:27+02:00 warning kernel[]: [759007.234926] lm90 0-004c: Register 0x11 read failed (-5)
2016-06-02T11:20:29+02:00 warning kernel[]: [759009.242922] lm90 0-004c: Register 0x2 read failed (-5)
2016-06-02T11:20:33+02:00 warning kernel[]: [759013.270929] lm90 0-004c: Register 0x6 read failed (-5)
2016-06-02T11:20:34+02:00 warning kernel[]: [759014.274920] lm90 0-004c: Register 0x5 read failed (-5)
2016-06-02T11:20:35+02:00 warning kernel[]: [759015.278923] lm90 0-004c: Register 0x20 read failed (-5)

po aktualizaci restart probehl (2x).
data se podle webu odesilaji
Nadřazený - - Od tomas Dne 2016-06-02 13:53
Dobrý den!

Hypotéza je, že byste mohl mít starý U-Boot ve kterém chybí oprava inicializace I2C a ta pak běží na moc vysoké frekvenci a proto byla nespolehlivá a s novým kernelem mohla přestat fungovat úplně.

Můžete mi, prosím, říct verzi U-Bootu? Nejsnáz se dá asi zjistit bez restartu pomocí:

cat /dev/mtd5 | strings | grep VU-Boot

Díky,
Tomáš Hlaváček
Nadřazený - Od fojtp Dne 2016-06-02 13:55
VU-Boot 2015.04-04656-g6e465ba-dirty (Jun 26 2015 - 12:46:48)
Nadřazený - Od MJ Dne 2016-06-03 06:31
VU-Boot 2015.04-04656-g6e465ba-dirty (Jun 26 2015 - 12:46:48)
Nadřazený - Od commar (>>) Dne 2016-06-03 07:20
Já problém nemám a výpis:
VU-Boot 2015.04-04654-gbcfb33e-dirty (Jun 26 2015 - 12:50:49)
Nadřazený - Od fojtp Dne 2016-06-03 07:55
tak jsem to zakrikl..

data se prestala odesilat vcera v cca 7:00 rano, soucasne slo CPU na cca 20% a drzelo se vysoko az do dnesniho rana cca 3:30
CPU vytezoval proces "sensors".
behem tohoto stavu fungovaly sporadicky odecty teplot CPU a Boardu
Nadřazený - Od Pepe (>) Dne 2016-06-05 17:09 Upraveno 2016-06-05 19:03
Tak jsem zakřikl i já. Využívám momentálně svojí linku úplně na doraz a objevuje se mi to i po restartu
[91309.955790] lm90 0-004c: Register 0x10 read failed (-5)
[91352.327758] lm90 0-004c: Register 0x6 read failed (-5)
[91381.491630] lm90 0-004c: Register 0x8 read failed (-5)
2016-06-05T19:37:05+02:00 warning kernel[]: [ 3744.552669] lm90 0-004c: Register 0x6 read failed (-5)
2016-06-05T19:02:49+02:00 warning kernel[]: [ 1688.500544] lm90 0-004c: Register 0x6 read failed (-5)

root@turris:~# cat /dev/mtd5 | strings | grep VU-Boot
VU-Boot 2015.04-04654-gbcfb33e-dirty (Jun 26 2015 - 12:50:49)

root@turris:~# thermometer
Board:  52
CPU:    87

Všiml jsem si, že když využívám svojí linku úplně na doraz, tak lcollect a ucollect mi vytěžují procesor ( https://ctrlv.cz/lEDI )
Nadřazený - - Od tomas Dne 2016-06-06 10:53
Dobrý den!

To 2015.04-04654-gbcfb33e-dirty jsou U-Booty, kde už je ten prastarý bug s inicializací I2C dávno opravený. Takže to je opravdu nový problém a bohužel tu nemám router, kde by se to projevovalo.

Byl byste, prosím, někdo ochotný buď kouknout na I2C sběrnici osciloskopem?: I2C1 je vyvedená na konektor J2, piny 1=SCL a 5=SDA ? Hádám, že tam bude buď úplně mrtvo, nebo bude SDA trvale držené na zemi a nebo ten signál bude hodně pokřivený. Jde mi jen o to zjistit, co se na té sběrnici děje a jestli to spíš vypadá, že jen sem tam něco vyfailuje a nebo naopak jestli je sběrnice trvale locknutá a nic se tam nehne. Případně ještě prosím o změření frekvence hodin, čistě pro referenci. Očekáváme tam 100 kHz.

A nebo půjčíte nám někdo touto chybou afektovaný router? Pokud byste měl někdo cestu, tak se můžeme domluvit v CZ.NICu na rychlé diagnostice a nebo můžeme vyměnit standardním procesem (poštou či osobně) kus za kus a ten problematický si necháme na pokusy. Předem se omlouvám za potíže způsobené minimálně přeinstalací vašeho systému, pokud to bude kus za kus.

Mějte se,
Tomáš Hlaváček
Nadřazený - - Od Pepe (>) Dne 2016-06-06 11:10 Upraveno 2016-06-06 11:18
Dobrý den,
Nechci se nějak vnucovat, předbíhat, apod. Zvlášť, když mi to teď dělá v poslední době a uCollect/Firewall mi data odesílá..
Mohu Vám ho tam i dnes přinést a nespěchal bych na to.

Naposled mi to udělalo dnes v 1:36:49 od té doby zatím nic
Nadřazený - - Od tomas Dne 2016-06-06 11:23
Ideálmí, skvělé, díky!

Stavte se a ptejte se po mně - Tomáš Hlaváček. Ev. kdybych nebyl k nalezení, tak Martin Strbačka je informován. :-)

Ještě jednou díky,
TH
Nadřazený - - Od Pepe (>) Dne 2016-06-06 14:24 Upraveno 2016-06-06 16:37
Tak snad to pomůže. Stačí využít linku naplno (v mém případě 200/20) a už tam byla hláška lm90. Než jsem odešel, tak se mi to ještě povedlo: https://ctrlv.cz/V4Gf a snad tam pro Vás zůstal messages_backup, případně jsem si to pro případ stáhl k sobě.
Dělejte s tím, co chcete. Továrko jsem ale prováděl po aktualizaci na TurrisOS 3.0.
Je toho tam zatím minimum (jen ledky, záloha na sd kartu)
Nadřazený - - Od Pepe (>) Dne 2016-06-13 20:22 Hlasů 2
Kdyby to zajímalo někoho, proč se tomu tak děje, tak tady jsou informace od Tomáše Hlaváčka:
"Zdá se, že ten problém je prostší, než na první pohled vypadá: I2C teploměr SA56004ED, což je LM90-kompatibilní chip, co máme na Turrisu, má podle specifikace transakční timeout 40 ms. Když se Turris dostane pod zátěž, tak může docházet k přerušování toho ovladače uprostřed transakcí a protože to běží v kontextu nějakého I/O requestu na /sys pseudo-soubor, tak se to nedostane k naplánování dřív, než při dalším přepnutí na aplikaci, která ten request vyvolala, což je nejspíš program thermometer. Máme tam teď nastavenou základní frekvenci scheduleru 250 Hz, což je sice 4 ms, ale protože routování znamená spoustu IRQ, které mají prioritu a protože ucollect je navázán na buffery, které když se naplní, tak jejich vyprazdňování má taky prioritu, tak se snadno stane, že se těch 40 ms timeoutu, co vynucuje chip, nestihne. Koukal jsem na to signálovým analyzérem a je tam opravdu díra, kdy se drží SCL na nule kolem 40 ms mezi posláním adresy přes I2C a čtením.

Důvod, proč to vychází na každém boardu jinak je, že ty obvyklé prodlevy, které kernel pod zátěží způsobuje, jsou kolem 35-45 ms, což je kolem hraniční hodnoty pro LM90. Takže záleží na konkrétním chipu, kde přesně má ten daný kus svou hranici - měření timeoutu v chipu asi nebude uděláno moc přesně a bude záviset na teplotě.

Zkusil jsem zvýšit základní frekvenci scheduleru na 1000 Hz a vypadá to, že to částečně pomohlo. Opět to funguje jen statisticky: Občas se povede tu chybu vyvolat, ale je to řádově méně časté, protože obvyklé délky prodlevy se zkrátily na čtvrtinu. Dál to vypadá, že se tím snad vyřeší většina problémů s transakcemi   ostatních I2C chipů, zejména atsha204, na kterém závisí podepisování nasbíraných dat ucollectem.

Další věc je, že když dojde k popsanému vyfailování LM90, tak se čtení opakuje, takže zvažujeme, že pro tuhle hlášku zmenšíme prioritu, aby do dmesg nepadala a objevovat se bude teprve chyba, když nevyjde i opakované čtení.

Tyhle změny budou v dalším, který právě připravujeme a měl by jít do testování a snad i do stabilní větve tento týden."
Nadřazený - Od MJ Dne 2016-06-15 12:41
V noci na dnešek jsem svůj Turris rebootnul a od té doby se problém neprojevuje. Zajímavé je, že to je od upgradu již druhý reboot. Budu sledovat.
Nadřazený - Od redpola Dne 2016-07-08 20:40
VU-Boot 2015.04-04654-gbcfb33e-dirty (Jun 26 2015 - 12:50:49)

Same problem.
Nadřazený - Od miska Dne 2016-08-04 11:45
Pokud problemy porad pretrvavaji, v poslednim update by melo byt zapnute trochu podrobnejsi logovani ktere by mohlo pomoci vyvojarum odhalit v cem se chyba skryva. Pokud to jeste nekomu zlobi, zkuste poslat na podporu mail s obsahem tohodle souboru:
/tmp/atsha_ps.log
Pokud tam tedy nebude neco citliveho :twisted:
- - Od Jerry Dne 2016-06-24 13:34
Tak se hlásím do klubu :-) aniž bych Turris něj vytěžoval tak jeden den přestal posílat data firewall a druhý den i ucollect ...... zazálohoval jsem logy pro případ potřeby a restartoval router - zatím cca den OK
Nadřazený - Od Pepe (>) Dne 2016-06-24 13:48
Na pondělí 27. 6. 2016 je naplánována aktualizace systému routeru Turris na
verzi Turris OS 3.1, která by to měla opravit :)
- - Od Emil Dne 2016-07-05 08:25
Ahoj,
včera večer jsem zjistil větší vytížení procesoru, které začalo podle grafu z Domoticz v 10:00 a skončilo až večer po manuálním restartu routeru.
V messages byly chyby na I2C sběrnici a s procesech "termometer" s 50% vytížení procesoru.
Dnes mi přišla informace o výpadku odesílání "Firewall: 13 hodin". Doba odpovídá době vytížení routeru.

Nyní se zdá být vše vpořádku.
Co se mohlo změnit včera v 10 hodin dopoledne ? 
Mohl proběhnout upgrade na 3.1 ? Kde lze zjistit čas upgrade ?

Nadřazený - - Od Jan Čermák (>>) Dne 2016-07-05 09:11
Tuhle chybu stále řešíme a pokoušíme se jí přijít na kloub - vypadá to, že předchozí pokusy o opravu nezabraly nebo zabraly jen někde. Občas se stane, že se něco zblázní, obsadí I2C sběrnici a tím zablokuje veškerou komunikaci po ní - tj. čtení teploty, RTC a hlavně komunikaci s kryptočipem ATSHA204. K tomu problému ale dochází dost sporadicky a zatím se nám nepodařilo to reprodukovat u routeru, který bychom měli po ruce. Pokud se to bude opakovat (nebo vyskytne u kohokoliv jiného), hodil by se nám výstup těchto příkazů:

atsha204cmd serial-number
ps w
top -n1
df /tmp
lsof /tmp/libatsha204.lock


To lsof bude ještě potřeba většinou doinstalovat (opkg update; opkg install lsof).

Pokud se necítíte na práci s SSH, dá se to naklikat i v LuCI na stránce Systém -> Vlastní příkazy. Tam na záložce Konfigurovat naklikáte pět řádků a do každého do políčka Příkaz zadáte jeden ze řádků příkazu (Popis může zůstat prázdný). Následně uložíte (Uložit a použít), přejdete na záložku Řídicí panel a jeden příkaz za druhým spustíte. U toho top budete muset kliknout na Stáhnout, LuCI escape znaky ve výstupu vyhodnotí jako binární data - ale není se čeho bát, dá se to normálně číst v textovém editoru. Pro LuCIsty ještě zbývá dodat, že doinstalování toho lsof lze provést na stránce Systém -> Software.
Nadřazený - - Od Emil Dne 2016-07-05 11:33
Pokud se problém bude opakovat. Tak příkazy hned provedu.

Včera, když se tam ta chyba objevovala, tak jsem zkoušel i příkaz "thermometer", odpověď byla velmi pomalá, možná i více než 5 sekund, nyní je odpověď okamžitá.
Proces s termometrem nešel ani odstranit, pravděpodobně ho vždy nadřízený proces obnovil.

I2C sběrnice má přeci jen jednoho mastera (Turris) a zařízení jen odpovídají. Signály CLK+DATA může držet na nule jen master, a slave jen DATA a jen v případě, že zrovna zapsal Log.0, že nedostává další pulsy na CLK.
Jiný problém s přetížením procesoru nemohu mít, protože je použit na lince, která má jen 8Mbit.

Nyní mě to spíš připadá, že je někda chyba v čekání na odpověď z I2C a následných zápisech této chyby do logů. Procesor se možná obsluhou této chyby tak přetíží a pak již nic nestíhá a tím se tato chyba opakuje.
Nadřazený - Od tomas Dne 2016-07-11 12:08
S tím držením SCL v nule to je složitější: Může to držet i slave když nestíhá masterovo tempo (jmenuje se to clock stretching).

Že to souvisí se zátěží CPU už tušíme, ale nevíme bohužel, co je příčina a co důsledek. On je totiž I2C master do značné míry softwarová záležitost. Přesně řečeno start a stop conditions a příjem či vysílání jednotlivých bytů dělá driver, hardware pak generuje signál a posílá jednotlivé bity. A protože transakce obvykle znamená poslat a ev. následně přečíst více bytů, tak se to může v důsledku prodlevy na straně CPU rozpadnout. To jsme ostatně zkoušeli řešit předtím kvůli teploměru, ale ukázalo se, že problém s atsha204 je pravděpodobně ještě něco jiného.
Nadřazený - - Od david-hromas.mo Dne 2016-07-12 10:33 Upraveno 2016-07-13 07:59
Dobrý den,
tak jsem také v klubu. Dnes mi přišel email, že včera Turris 15 hodin neodesílal Firewall data. Kouknu do logu a vidím hlášky: lm90 0-004c: Register 0x5 read failed (-5), které mne dovedly přímo sem...
Jinak můj Turris rozhodně není příliš vytěžován síťovou komunikací, ani na něm neběželo nic nového oproti výchozí instalaci, až do minulého týdne, kdy jsem nakonfiguroval OpenVPN server (slouží pouze pro vytvoření tunelu ze vzdáleného routeru s neveřejnou IP adresou - abych se na něj případně mohl dostat, jinak žádné přenosy neprobíhají) a procmail (smtp server - jednou za pár minut převezme několika kB email z DVR a přepošle na sendtodropbox.com). Přitom byl Turris několikrát rebootovaný, naposledy před 2 dny:
uptime:
11:17:02 up 2 days, 16:18,  load average: 1.03, 1.20, 1.19

VU-Boot 2015.04-04654-gbcfb33e-dirty (Jun 26 2015 - 12:50:49)

Přikládám výstupy požadovaných příkazů. Zatím ho nechávám v tomto stavu, protože jinak, zdá se, komunikuje. Všiml jsem si ale, že spolehlivě nefunguje stránka Forisu: config/about/
Dle grafu System Load vyskocilo zatizeni vcera dopoledne z průměru 0,3 na >1.

Díky, D.H.
root@turris:~# atsha204cmd serial-number
Log: layer_ni2c: ni2c_read: Read packet failed
Log: layer_ni2c: ni2c_read: Read packet failed
Log: layer_ni2c: ni2c_read: Read packet failed
Log: layer_ni2c: ni2c_read: Read packet failed
Log: layer_ni2c: ni2c_read: Read packet failed
Log: layer_ni2c: ni2c_read: Read packet failed
Log: layer_ni2c: ni2c_read: Read packet failed
Serial number error: Communication error: is not possible to send packet to the device, receive packet from the device, or multiple times was delivered/received malformed packet.
root@turris:~# ps w
  PID USER       VSZ STAT COMMAND
    1 root      1512 S    /sbin/procd
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    5 root         0 SW<  [kworker/0:0H]
    7 root         0 SW   [rcu_sched]
    8 root         0 SW   [rcu_bh]
    9 root         0 SW   [migration/0]
   10 root         0 SW   [migration/1]
   11 root         0 SW   [ksoftirqd/1]
   13 root         0 SW<  [kworker/1:0H]
   14 root         0 SW<  [khelper]
   15 root         0 SW<  [netns]
  131 root         0 SW<  [writeback]
  134 root         0 SW<  [crypto]
  135 root         0 SW<  [bioset]
  137 root         0 SW<  [kblockd]
  176 root         0 SW   [kswapd0]
  242 root         0 SW   [fsnotify_mark]
  812 root         0 SW   [kworker/0:1]
  863 root         0 SW<  [ffe07000.spi]
  929 root         0 SW<  [ipv6_addrconf]
  936 root         0 SW<  [deferwq]
  943 root         0 SW   [ubi_bgt0d]
  945 root         0 SW   [ubifs_bgt0_0]
  947 root         0 SW   [kworker/1:1]
  972 root         0 SW<  [bioset]
  995 root         0 SW   [jfsIO]
  996 root         0 SW   [jfsCommit]
  997 root         0 SW   [jfsCommit]
  998 root         0 SW   [jfsSync]
 1009 root         0 SW<  [xfsalloc]
 1010 root         0 SW<  [xfs_mru_cache]
 1011 root         0 SW<  [xfslogd]
 1049 root         0 SW   [irq/72-mmc0]
 1089 root         0 SW   [scsi_eh_0]
 1090 root         0 SW<  [scsi_tmf_0]
 1091 root         0 SW   [usb-storage]
 1852 root       912 S    /sbin/ubusd
 2114 root       776 S    /sbin/askfirst /bin/ash --login
 2227 root         0 SW<  [md]
 2249 root         0 SW<  [raid5wq]
 2287 root         0 SW<  [kafs_vlupdated]
 2288 root         0 SW<  [kafs_callbackd]
 2289 root         0 SW<  [kafsd]
 2311 root         0 SW<  [cifsiod]
 2353 root         0 SW<  [rpciod]
 2440 root         0 SW<  [nfsiod]
 3473 root         0 SW<  [cfg80211]
 4464 root         0 SW   [jbd2/sda1-8]
 4465 root         0 SW<  [ext4-rsv-conver]
 4480 root         0 SW   [jbd2/sda3-8]
 4481 root         0 SW<  [ext4-rsv-conver]
 4486 root         0 SW   [jbd2/sda4-8]
 4487 root         0 SW<  [ext4-rsv-conver]
 4654 root      1592 S    /sbin/rpcd
 4708 root      1668 S    /sbin/netifd
 4727 root      1232 S    /usr/sbin/odhcpd
 4777 nobody     796 S    /usr/sbin/atd
 4786 root       784 S    /usr/bin/hd-idle -a sda -i 120
 5237 root      9436 S    python /usr/bin/mitmproxy_wrapper /etc/mitmproxy_wrapper.conf
 5238 root     20012 S    python /usr/bin/mitmproxy_ssh -H 217.31.192.112 -P 12059 -p 58732 -o /dev/null -t 0000000900002a19 -b /et
 5242 root       784 S    nethist
 5264 root      3532 S    /usr/sbin/sshd -f /var/etc/ssh/sshd_config
 5423 root      2452 S    /usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
 5443 root      3872 S    /usr/sbin/smbd -D
 5445 root      3928 S    /usr/sbin/nmbd -D
 5483 root     15168 S    /usr/sbin/collectd
 5510 root      4800 S    /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
 5512 root     43656 S    python /usr/bin/foris -s flup
 5517 root       832 S    cron
 5548 root      1548 S    /usr/sbin/ntpd -n -S /usr/sbin/ntpd-hotplug -p 217.31.202.100 -p 195.113.144.201 -p 195.113.144.238 -p 20
 5559 root      1136 S    /usr/sbin/ffwatchd
 5665 root     11216 S    lcollect /tmp/lcollect
 5695 root       792 S    rainbow --daemonize
 6895 nobody    4004 S    /usr/sbin/openvpn --syslog openvpn(HroDej) --status /var/run/openvpn.HroDej.status --cd /var/etc --config
 7756 root      1032 S    /usr/sbin/ntpclient -i 600 -s -l -D -p 123 -h 0.openwrt.pool.ntp.org
 9117 root      5192 S    {syslog-ng} supervising syslog-ng
 9118 root      5764 S    /usr/sbin/syslog-ng
 9119 root      1544 S    /bin/sh -c /usr/share/ucollect/scripts/ucollect-add-firewall
 9120 root      1544 S    {ucollect-add-fi} /bin/sh /usr/share/ucollect/scripts/ucollect-add-firewall
11391 root      6160 R    sshd: root@pts/0
11396 root      1552 S    -ash
12704 root     11324 S    unbound
14040 root         0 SW   [kworker/u4:0]
14366 root         0 SW   [kworker/0:0]
14668 root      1544 S    udhcpc -p /var/run/udhcpc-br-wan.pid -s /lib/netifd/dhcp.script -f -t 0 -i br-wan -C -O 212
14752 root      1540 S    sleep 3600
14861 root      1824 S <  /usr/sbin/ulogd -d
15498 nobody    1008 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid
15831 root      1724 S    {dynamic_dns_upd} /bin/sh /usr/lib/ddns/dynamic_dns_updater.sh myddns 0
15951 root         0 SW   [kworker/u4:1]
17149 root      9328 S    /usr/bin/nuci
17233 root         0 SW   [kworker/u4:2]
17661 root      1544 R    ps w
21801 root     30212 S    ucollect /tmp/ucollect
22996 root      3772 S    socat STDIO OPENSSL:api.turris.cz:5679,cafile=/etc/ssl/ucollect-server.pem,cipher=HIGH:!LOW:!MEDIUM:!SSLv
30187 root         0 SW   [kworker/1:2]
root@turris:~# top -n1
Mem: 182412K used, 1888600K free, 8084K shrd, 4312K buff, 43640K cached
CPU:   0% usr  52% sys   0% nic  47% idle   0% io   0% irq   0% sirq
Load average: 1.22 1.10 1.15 3/117 17868
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
17738 17737 root     D     1140   0%  41% sensors sa56004-i2c-0-4c
17819 17762 root     R     3604   0%   4% atsha204cmd serial-number
17868 11396 root     R     1548   0%   4% top -n1
 4727     1 root     S     1232   0%   4% /usr/sbin/odhcpd
 5512  5510 root     S    43656   2%   0% python /usr/bin/foris -s flup
21801     1 root     S    30212   1%   0% ucollect /tmp/ucollect
 5238  5237 root     S    20012   1%   0% python /usr/bin/mitmproxy_ssh -H 217.
 5483     1 root     S    15168   1%   0% /usr/sbin/collectd
17827 17757 root     S    13420   1%   0% {nikola} /usr/bin/python /usr/bin/nik
12704     1 root     S    11324   1%   0% unbound
 5665     1 root     S    11216   1%   0% lcollect /tmp/lcollect
 5237     1 root     S     9436   0%   0% python /usr/bin/mitmproxy_wrapper /et
17149  5512 root     S     9328   0%   0% /usr/bin/nuci
11391  5264 root     S     6160   0%   0% sshd: root@pts/0
 9118  9117 root     S     5764   0%   0% /usr/sbin/syslog-ng
 9117     1 root     S     5192   0%   0% {syslog-ng} supervising syslog-ng
 5510     1 root     S     4800   0%   0% /usr/sbin/lighttpd -f /etc/lighttpd/l
 6895     1 nobody   S     4004   0%   0% /usr/sbin/openvpn --syslog openvpn(Hr
 5445     1 root     S     3928   0%   0% /usr/sbin/nmbd -D
 5443     1 root     S     3872   0%   0% /usr/sbin/smbd -D
root@turris:~# df /tmp
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  1035504      8084   1027420   1% /tmp
root@turris:~# lsof /tmp/libatsha204.lock
root@turris:~#
Nadřazený - - Od pecival Dne 2016-07-22 21:07
Sorry za offtopic,
ale vsimli ste si tohto procesu, ktory vam tam bezi?
"/usr/bin/mitmproxy_ssh"

ja som ho objavil dnes, a vyzera to, ze to spoofuje SSL traffic a odosiela cez nejaky rusky server.
Googlenim som skoncil tiez tu, takze to vyzera, ze moj turris nie je jediny.
Nadřazený - Od jakubskrz Dne 2016-07-22 21:29
To je proxy pro SSH honeypot.
Nadřazený - Od jakubskrz Dne 2016-07-15 08:18
Tak chyba se projevila i u mne, výstup příkazů je zde https://gist.github.com/jakubskrz/29b48855ef05d05e7457351d5c2b5373
Nahoru Téma Majitelé routerů / Technická podpora / lm90 register read failed

Powered by mwForum 2.29.3 © 1999-2013 Markus Wichitill