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 / Turris 2.5
- - Od Michal Dne 2015-08-10 10:57
Po dnešní aktualizaci jsem provedl restart. Po restartu nenaběhne luci ani foris, spojení na internet funguje.
Nadřazený - - Od araman Dne 2015-08-10 12:15
zkusit uplně odpojit napájení na 30vteřin ..
Nadřazený - - Od commar (>>) Dne 2015-08-10 12:37
u mě proběhl restart bez problému, jen v Majordomo se mi zobrazuje jen dnešek,
starší data ve složce jsou ale v LuCI se nezobrazují.
Nadřazený - Od PabloRadegast (>) Dne 2015-08-10 15:11
Muzu potvrdit, ze data Majordoma se chovaji nejak divne.
Tento mesic jakoby vynuloval a zobrazuje jenom a pouze muj NAS, ktery jede od upgradu, ale trebaze jsem dneska stahl cca. 1GB, tak mi ukazuje jenom 6.64 KB

Majordomo - přehled
Měsíc: 2015-08 (od: 2015/08/01 00:01)
Klient   Počet (download)   Packet size (download)   Velikost dat (download)   Počet (upload)   Packet size (upload)   Velikost dat (upload)   Detaily
Synology   46   6.64 KB   4.84 KB   54   10.90 KB   8.65 KB   Zobrazit detaily

Po rozkliknuti detailu mesice situace stejna, ale kdyz rozkliknu treba vcerejsek, tak uz to ukazuje realne prenesene data. Bohuzel data pro dalsi zelezo na vnitrni siti se ztratilo.
Nadřazený - - Od PabloRadegast (>) Dne 2015-08-13 13:49
Dobry den,
Majordomo se od posledniho update chova opravdu nejak divne. Vypada to, jako by nezobrazoval vsechny data vsech periferii v domaci siti. Mam do Turrise zapojeny 3 zeleza + jeste neco pres wi-finu, ale Majordomo mi zobrazuje od posledniho update jenom jedno zelezo a to jeste k tomu spatne. Videt to je na nasledujicim obrazku: http://www.imagehosting.cz/?v=majordomo.png. Pritom jsem si jisty, ze tento a minuly tyden jsem na klienta PR74kabel nastahoval velka data, protoze jsem delal reinstall Windows 7 a stahoval update balicky.
Dival jsem se do souboru, ktere si Majordomo uklada a vypada to, ze do dennich a hodinovych dat se provoz uklada, ale ne uz do mesicnich souboru.
Nadřazený - Od commar (>>) Dne 2015-08-13 14:06
Počkáme na vyjádření teamu, ale mě se z průměrně 20ti zařízení objevují v přehledu jen tři.
Úplně mi chybějí zařízení připojená kabelem, ty mají pevně danou IP, z mobilních vidím jen dva iPhony.
Nadřazený - - Od Robin Obůrka Dne 2015-08-13 21:04
Dobrý den,

tohle je opravdu velmi divné chování. V Majordomovi se toho sice změnilo hodně, ale jsem si poměrně jistý, že ne v částech kódu, které by mohly způsobovat něco takového.

Střílím od boku, ale zkusíme zúžit oblast pátrání. Poprosím vás o tyto příkazy a úkony:

Nejdříve cd do vaší složky majordomo_db.

Počet špinavých řádků v DB:
cat majordomo_monthly_* majordomo_daily_* majordomo_hourly_* | cut -d, -f11 | grep '^$' | wc -l

Počet čistých řádků v DB:
cat majordomo_monthly_* majordomo_daily_* majordomo_hourly_* | cut -d, -f11 | grep -v '^$' | wc -l

Velikost "staré cache":
wc -l majordomo_serialized_ptr

Jen ať mám představu jestli k migraci došlo v pořádku.

Dále, vyberte nějaký hodinový soubor, kdy mělo být připojených více klientů, jemu odpovídající denní soubor (a možná zkuste i měsíční) a vyzkoušejte tento příkaz:

cat SOUBOR | cut -d, -f2 | sort | uniq -c

Výstup neposílejte, jedná se o vaše MAC adresy a to považuji za citlivější informaci. Zajímám se o to, zda jsou vaši "ztracení klienti" v DB a LuCI je nedovede zobrazit, nebo jestli se klienti nedostanou ani do té DB.  Snad to půjde snadno posoudit.

V této souvislosti mě ještě napadá jedna věc: Na vybraném souboru zkuste porovnat výstup z LuCI a výstup z příkazu majordomo_show.lua SOUBOR. To by mohl být druhý pohled na toho, kdo ztrácí data.

Dále bych ještě poprosil o vyzkoušení toho příkazu cat SOUBOR | cut -d, -f2 | sort | uniq -c na soubor /tmp/majordomo_downsize (pozor: bude prázdný na začátku hodiny, ideální by bylo vyzkoušet ho později v každé hodině) a na souboru /tmp/ucollect_majordomo (ten se eliminuje co 5 minut, takže pokud nebude existovat, tak prosím chvilku počkejte).

Pokud by v DB vaši klienti chyběli, tak mě zajímá, kde se poprvé stalo to, že chybí. Např. pokud budou v /tmp/ucollect_majordomo a už nebudou v /tmp/majordomo_downsize je to pro mě velmi dobré nasměrování k problému.

A jako poslední zkontrolujte obsah souboru /tmp/lcollect/lcollect. V sekci config interface by měla být volba ifname 'br-lan' (případně odpovídající nastavení pro vaši sít) a v sekci config plugin by v listu ignore_subnet měl být výčet všech možných lokálních sítí, které se u vás vyskytují. Pokud se tam objevují nějaké veřejné subnety, je to také užitečná informace.

Vím, že je toho hodně, ale opravdu tápu a potřeboval bych vědět, kde hledat. Děkuji
Nadřazený - - Od commar (>>) Dne 2015-08-13 21:51
Nebylo by jednodušší když vám někam postnu celou složku _db?
Vy se tím jistě prohrabete líp než já.
Každopádně je jisté že k nabourání došlo po aktualizaci.
Nadřazený - - Od Robin Obůrka Dne 2015-08-13 22:38
Zjistil bych z toho jen polovinu z těch potenciálních problémů. Pokud se povede zjistit, že je problém někde v migraci dat, tak pak by to mohlo být zajímavé.

Ale abych byl korektní: Jsou to poměrně citlivá data a oficiálně je od vás nemohu žádat. A upřímně bych z toho neměl dobrý pocit, kdybych takovými daty disponoval.
Nadřazený - Od commar (>>) Dne 2015-08-13 22:45
Dobře, zîtra se tím pokusím prokousat.
Nadřazený - - Od commar (>>) Dne 2015-08-14 07:59 Upraveno 2015-08-14 08:21
Zasílám domluvená data:
MAC adresy jsem malinko upravil, snad se v tom vyznáte....
Snad jsem udělal vše, kdyby něco pište, můžem si klidně i zavolat...

EDIT: ještě doplním, že obsah složky majordomo_db mažu vždy první den v měsíci, 5 minut po půlnoci...



Zaílám domluvená data:

cat majordomo_monthly_* majordomo_daily_* majordomo_hourly_* | cut -d, -f11 | grep '^$' | wc -l
0

cat majordomo_monthly_* majordomo_daily_* majordomo_hourly_* | cut -d, -f11 | grep -v '^$' | wc -l
25979

wc -l majordomo_serialized_ptr
3478 majordomo_serialized_ptr

cat majordomo_hourly_2015-08-13-20 | cut -d, -f2 | sort | uniq -c
     48 00:00:00:2f:39:4f
     59 00:00:00:66:28:79
     78 00:00:00:0c:01:74
    195 00:00:00:9d:91:55
      3 00:00:00:dc:63:48
      3 00:00:00:a0:33:f3
     33 00:00:00:88:71:ba

cat majordomo_daily_2015-08-13 | cut -d, -f2 | sort | uniq -c
     23 00:00:00:66:28:79
     10 00:00:00:0c:01:74
    157 00:00:00:9d:91:55
      6 00:00:00:a0:05:16

cat majordomo_monthly_2015-08 | cut -d, -f2 | sort | uniq -c
     19 00:00:00:66:28:79
      3 00:00:00:0c:01:74
     34 00:00:00:9d:91:55
      2 00:00:00:dc:63:48

majordomo_show.lua majordomo_monthly_2015-08
00:00:00:0c:01:74 (ASUSTek COMPUTER INC.)
         - 2a02:598:a::78:51 - (110/TCP) - (27.000000/2461.000000/517.000000) - (19.000000/1454.000000/70.000000)
         - fra07s27-in-f4.1e100.net - (443/TCP) - (13.000000/6155.000000/5471.000000) - (18.000000/3976.000000/3056.000000)
         - fra07s27-in-f1.1e100.net - (443/TCP) - (7.000000/1316.000000/952.000000) - (10.000000/1748.000000/1212.000000)
00:00:00:66:28:79 (Apple)
         - 32.65.253.112 - (443/TCP) - (6278.000000/331981.000000/4701.000000) - (12358.000000/17431152.000000/16788524.000000)
         - 54.240.226.64 - (443/TCP) - (5273.000000/215902.000000/4970.000000) - (10419.000000/15262043.000000/14845259.000000)
         - s3-ap-southeast-1-w-a.amazonaws.com - (443/TCP) - (1765.000000/75598.000000/4986.000000) - (3424.000000/4909434.000000/4772450.000000)
         - s3-ap-southeast-1-w-a.amazonaws.com - (443/TCP) - (1660.000000/76099.000000/9663.000000) - (2971.000000/3987187.000000/3868299.000000)
         - s3-3-w.amazonaws.com - (443/TCP) - (561.000000/32404.000000/9940.000000) - (1045.000000/1498492.000000/1456644.000000)
         - s3-3-w.amazonaws.com - (443/TCP) - (561.000000/32404.000000/9940.000000) - (1042.000000/1498372.000000/1456644.000000)
         - 17.167.144.34 - (443/TCP) - (130.000000/36649.000000/31413.000000) - (160.000000/102634.000000/96162.000000)
         - 17.151.236.24 - (443/TCP) - (66.000000/14365.000000/11677.000000) - (76.000000/14348.000000/11212.000000)
         - a23-63-92-42.deploy.static.akamaitechnologies.com - (80/TCP) - (17.000000/2090.000000/1190.000000) - (33.000000/2125.000000/325.000000)
         - 17.172.232.205 - (5223/TCP) - (26.000000/6191.000000/4831.000000) - (29.000000/6581.000000/5085.000000)
         - 17.110.227.19 - (443/TCP) - (26.000000/6191.000000/4831.000000) - (29.000000/6597.000000/5101.000000)
         - 17.173.255.74 - (443/TCP) - (12.000000/5933.000000/5441.000000) - (16.000000/4031.000000/3367.000000)
         - a23-62-237-95.deploy.static.akamaitechnologies.com - (80/TCP) - (7.000000/7074.000000/6710.000000) - (9.000000/671.000000/183.000000)
         - 17.178.104.64 - (443/TCP) - (5.000000/226.000000/14.000000) - (6.000000/366.000000/102.000000)
         - 17.178.104.62 - (443/TCP) - (3.000000/139.000000/7.000000) - (4.000000/235.000000/51.000000)
         - defra1-ntp-001.aaplimg.com - (123/UDP) - (0.000000/0.000000/0.000000) - (2.000000/152.000000/96.000000)
         - defra1-ntp-003.aaplimg.com - (123/UDP) - (0.000000/0.000000/0.000000) - (2.000000/152.000000/96.000000)
         - nlams2-ntp-001.aaplimg.com - (123/UDP) - (1.000000/76.000000/48.000000) - (1.000000/76.000000/48.000000)
         - 17.172.232.99 - (5223/TCP) - (0.000000/0.000000/0.000000) - (1.000000/64.000000/0.000000)
00:00:00:9d:91:55 (Apple)
         - 15.gcache.iol.cz - (443/TCP) - (162538.000000/241736970.000000/233284802.000000) - (108697.000000/7357422.000000/765154.000000)
         - 19.gcache.iol.cz - (443/TCP) - (78837.000000/117429201.000000/113329645.000000) - (42409.000000/2680371.000000/187275.000000)
         - fra02s22-in-f0.1e100.net - (443/TCP) - (488.000000/520337.000000/494953.000000) - (578.000000/47165.000000/17085.000000)
         - fra07s31-in-f9.1e100.net - (443/TCP) - (303.000000/318693.000000/302917.000000) - (364.000000/30751.000000/11595.000000)
         - mil01s24-in-f10.1e100.net - (443/TCP) - (110.000000/75243.000000/69515.000000) - (124.000000/25918.000000/19446.000000)
         - mil01s25-in-f10.1e100.net - (443/TCP) - (46.000000/23628.000000/21224.000000) - (55.000000/12478.000000/9598.000000)
         - fra02s22-in-f14.1e100.net - (443/TCP) - (37.000000/28889.000000/26965.000000) - (51.000000/4592.000000/1908.000000)
         - a23-214-175-237.deploy.static.akamaitechnologies.com - (443/TCP) - (60.000000/79935.000000/76815.000000) - (47.000000/3764.000000/1324.000000)
         - fra07s63-in-f8.1e100.net - (443/TCP) - (35.000000/7155.000000/5315.000000) - (39.000000/8917.000000/6853.000000)
         - fra02s27-in-f1.1e100.net - (443/TCP) - (28.000000/6573.000000/5109.000000) - (34.000000/6983.000000/5179.000000)
         - 20.gcache.iol.cz - (443/TCP) - (32.000000/12527.000000/10851.000000) - (33.000000/6819.000000/5083.000000)
         - lga15s42-in-f23.1e100.net - (443/TCP) - (26.000000/6373.000000/5013.000000) - (32.000000/4352.000000/2664.000000)
         - fra07s29-in-f1.1e100.net - (443/TCP) - (25.000000/15682.000000/14410.000000) - (31.000000/2738.000000/1114.000000)
         - 17.173.66.181 - (443/TCP) - (18.000000/10011.000000/9291.000000) - (26.000000/8249.000000/7173.000000)
         - 34.gcache.iol.cz - (443/TCP) - (22.000000/11362.000000/10206.000000) - (25.000000/3189.000000/1869.000000)
         - fra02s17-in-f1.1e100.net - (443/TCP) - (18.000000/7890.000000/6946.000000) - (25.000000/2738.000000/1414.000000)
         - fra07s63-in-f2.1e100.net - (443/TCP) - (19.000000/5704.000000/4732.000000) - (24.000000/4335.000000/3111.000000)
         - fra07s28-in-f25.1e100.net - (443/TCP) - (16.000000/5531.000000/4691.000000) - (23.000000/2948.000000/1728.000000)
         - fra02s22-in-f26.1e100.net - (443/TCP) - (17.000000/5595.000000/4691.000000) - (22.000000/2756.000000/1600.000000)
         - fra02s19-in-f25.1e100.net - (443/TCP) - (18.000000/5354.000000/4410.000000) - (22.000000/2417.000000/1261.000000)
         - ber01s09-in-f23.1e100.net - (443/TCP) - (17.000000/5519.000000/4615.000000) - (21.000000/2532.000000/1428.000000)
         - a23-63-77-183.deploy.static.akamaitechnologies.com - (443/TCP) - (13.000000/10615.000000/9939.000000) - (20.000000/1979.000000/943.000000)
         - fra07s31-in-f7.1e100.net - (80/TCP) - (6.000000/4274.000000/3954.000000) - (7.000000/667.000000/291.000000)
         - fra07s31-in-f1.1e100.net - (443/TCP) - (0.000000/0.000000/0.000000) - (3.000000/164.000000/0.000000)
         - fra07s29-in-f14.1e100.net - (443/TCP) - (1.000000/60.000000/0.000000) - (2.000000/104.000000/0.000000)
         - fra07s31-in-f6.1e100.net - (80/TCP) - (1.000000/60.000000/0.000000) - (2.000000/104.000000/0.000000)
         - fra07s63-in-f6.1e100.net - (443/TCP) - (1.000000/60.000000/0.000000) - (2.000000/104.000000/0.000000)
         - ber01s09-in-f24.1e100.net - (443/TCP) - (1.000000/60.000000/0.000000) - (2.000000/104.000000/0.000000)
         - nlams2-ntp-001.aaplimg.com - (123/UDP) - (0.000000/0.000000/0.000000) - (2.000000/152.000000/96.000000)
         - fra07s28-in-f13.1e100.net - (443/TCP) - (1.000000/60.000000/0.000000) - (2.000000/104.000000/0.000000)
         - fra07s63-in-f14.1e100.net - (443/TCP) - (1.000000/60.000000/0.000000) - (2.000000/104.000000/0.000000)
         - defra1-ntp-001.aaplimg.com - (123/UDP) - (1.000000/76.000000/48.000000) - (1.000000/76.000000/48.000000)
         - defra1-ntp-003.aaplimg.com - (123/UDP) - (1.000000/76.000000/48.000000) - (1.000000/76.000000/48.000000)
         - other - (all/both) - (0.000000/0.000000/0.000000) - (0.000000/0.000000/0.000000)
00:00:00:dc:63:48 (Raspberry Pi Foundation)
         - tik.cesnet.cz - (123/UDP) - (0.000000/0.000000/0.000000) - (6.000000/456.000000/288.000000)
         - other - (all/both) - (0.000000/0.000000/0.000000) - (0.000000/0.000000/0.000000)

cat majordomo_downsize | cut -d, -f2 | sort | uniq -c
    314 00:00:00:2f:39:4f
    163 00:00:00:0c:01:74
     85 00:00:00:9d:91:55
     39 00:00:00:5a:67:9b
      2 00:00:00:dc:63:48

cat ucollect_majordomo | cut -d, -f2 | sort | uniq -c
     11 00:00:00:2f:39:4f
     38 00:00:00:0c:01:74
      4 00:00:00:9d:91:55
      2 00:00:00:dc:63:48

/tmp/lcollect/lcollect

package 'lcollect'

config interface
  option ifname 'br-lan'

config plugin
  option libname 'libplugin_lcollect_majordomo_23.so'
  list ignore_subnet '10.0.0.1/24'
  list ignore_subnet '2a00:1028:8d1b:a90a::1/64'
  list ignore_subnet 'fe80::da58:d7ff:fe00:135/64'

Nadřazený - - Od Robin Obůrka Dne 2015-08-14 08:24
To je zvláštní. Vypadá to, jako by se ti klienti ztratili při přechodu a hodinových a denní souborů do těch měsíčních.

Takže bych poprosil ještě o 2 maličkosti:

1) Část configu /etc/config/majordomo, která specifikuje počty souborů a ten limit max_items_....

2) Pusťte prosím ten příkaz cat SOUBOR | cut -d, -f2 | sort | uniq -c ještě na nějaký hodinový, denní a jim odpovídající měsíční soubor, které všechny budou před instalací nové verze. Tedy asi červenec. Rád bych si byl jistý, že nějací klienti nezmizeli i odsud. To mi trochu zmenší oblast kódu.

Děkuji
Nadřazený - - Od Robin Obůrka Dne 2015-08-14 10:13
Tak už nemusíte nic posílat.

Povedlo se mi nalézt router, který mám dostupný a který tím problémem trpí také. Takže to mohu prošetřit tam. Bohužel to vypadá na nějakou plošnou chybu, která unikla testování, a ne jen na ojedinělý případ.

Děkuji za nahlášení, snad se povede chybu odstranit co nejdříve.
Nadřazený - - Od Robin Obůrka Dne 2015-08-14 13:49
Update: Chybu se povedlo nalézt a opravit.

Opravu se pokusíme vydat co nejdříve jako hotfix (snad už v pondělí) a nečekat na příští release.

Bohužel dochází k přemazávání dat v denních a měsíčních souborech podle toho, jací klienti komunikovali v dané hodině. Dobrá zpráva je, že se to týká pouze aktuálního měsíce a historická data nejsou ohrožena.

Rád bych doporučil následující: V nastavení povolte počet hodinových souborů, který odpovídá nějaké delší době - cca měsíc. Tedy pokud to vaše úložiště pojme. Vzhledem k tomu, že hodinové soubory nejsou poškozeny, mělo by být možné z hodinových souborů zrekonstruovat ty denní a měsíční (ovšem za předpokladu, že ty hodinové budou k dispozici). Dodatečně bych připravil a publikoval nějaký script, který se o tu rekonstrukci postará.

Ještě jednou bych chtěl poděkovat, za data, která jste poskytl. Ani si nedovedete představit, jak nápomocné to bylo.
Nadřazený - Od commar (>>) Dne 2015-08-14 14:45
Rád jsem pomohl, spíše mě překvapuje s jakou rychlostí jste to odhalil a zjednal nápravu.
Já osobně složku majordomo_db pravidelně mažu, starší data pro mě nemají význam,
tento měsíc klidně oželím, teď bude dovolená a od září se uvidí.

Díky a mějte se... Martin Žák
Nadřazený - - Od commar (>>) Dne 2015-08-21 07:28
Byl jsem celý týden pryč, tak dodatečně potvrzuji, po pondělní aktualizaci se vše vrátilo k normálu a data se zobrazují správně.
Díky M.
Nadřazený - Od Robin Obůrka Dne 2015-08-26 13:22
Super, děkuji za potvrzení!
Nadřazený - Od Michal Dne 2015-08-10 12:48
Nepomohlo. Udělal jsem tvrdý reset a už to jede.
- - Od linker Dne 2015-08-10 14:40
Po aktualizacii mi nechce nastartovat uhttpd. Toto je v vo /var/log/messages:
info procd[]: Instance uhttpd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash
Nadřazený - Od Michal Dne 2015-08-10 14:56
já musel doinstalovat uhttpd
Nahoru Téma Majitelé routerů / Technická podpora / Turris 2.5

Powered by mwForum 2.29.3 © 1999-2013 Markus Wichitill