Zatuhávání domácí Wifinky NETIS

[mpcz]

Dík, v době Netisu to samozřejmě nešlo, klient (rodiče + náruživý hráč) to vždy vypli/zapli když jim to minutu nešlo. Pro jsem tam poslal RB a udělal skript, který vše uložil, když to přestalo pingat na půdu. Před tím skript uložil vše, co jsem uměl uložit. Tam jsem si všiml, že v logu chyběly některé údaje, které tam rozhodně měly být, přestože tam byl delay 2 minuty. Příčinu jsem ani nestihl zjistit, protože mi klient nahradil RB zase zpátky Netisem - ten je prý lepší - má dvě antény. Pokud by bylo možné tam vlézt z druhé strany, určitě by to bylo mnohem lepší, to uznávám, ale třeba v 21 hodin večer, kdy k tomu zpravidla docházelo, si takovou akci nedovedu dost dobře představit.
Že ten profi měřič to rozpitvá do podrobností, to věřím, ale nemám ho, takže v tuto chvíli nic. Zřejmě by to vedlo k odhalení event. problému na kabelu, pokud by nebyl typu např. "protlačený kabel pod prahem" ke kterému dojde na sekundu při došlápnutí.
Ještě zkusím přehodit kabel na půdě do jiného RB, který tam je vedle té 433ky a jsou z něho napojeni i jiní klienti (ti jsou všichni bez problémů).
Ještě se vracím k tomu častému záznamu 9003 v torchu, který (možná) něco nazačuje o loopu. Dá se něco z RB na půdě, který je celou dobu dostupný, vydolovat více o tomto řádku? (Proč tam ten řádek je, odkud přišel, nějaké adresy atd.). Děkuji, mpcz, 21/12/2018

[hapi]

to je nejspíš aktivní detekce loopu od nějakýho switche.

[ludvik]

Ne nejspíš, ale určitě.
https://www.iana.org/assignments/ieee-8 ... bers.xhtml

Abys věděl, odkud to je, musíš zjistit MAC.

[mpcz]

Ano, dík, to se lehce řekne, ale jak. Výše se zmiňuji o svém souboji se smyčkou, která je v jiných případech popsána logem Mikrotiku a ani tam jsem úspěšný nebyl. Tady je navíc komplikace, že se nedá v místě zřídit nějaké výzkumné pracoviště na delší dobu a spoléhat se můžu jen na ten HW, který tam je. mpcz, 22/12/2018

[rsaf]

Že tam chodí packet nějaké detekce ještě zdaleka neznamená, že to smyčkuje. Nevím, co chceš slyšet. Vyměnit všechny aktivní prvky za nové, jiné (a nějaké co běžně používáš a problémy s tím nejsou), vyměnit zdroje, překonektorovat, vyměnit kabel. Třeba můžeš provizorně natáhnout kabel okno-okno, za týden se kvůli toho nikdo nezblázní.
Pokud tam není PoE a stačí 100MBit tak dolů po jednom UTPčku pošli dvě služby, když se jedna sekne pojede jim ta druhá a nebudou to muset resetovat (a ty se tam třeba budeš mít možnost podívat).

[mpcz]

Dík, sám nevím, třeba něco, co tu ještě nebylo a pomůže to. Například návod na cílené hledání smyčky, ať už tady je nebo ne, popř. v jiných místech, kde to smyčku v MKT přímo vypisuje v logu. Už to tu píši poněkolikráte, že všechno je vyměněno, teď i překonektorováno, včetně zdrojů. A také opakovaně, že výměna celé délky kabelu je v současné době prakticky neproveditelná a není to lenost. A hlavně se může stát, že po velké akci bude problém nevyřešen, což nebude působit dvakrát dobře.
Ten nápad s druhou službou po "POE" páru ale není vůbec špatný, původně jsem to měl ve vhodné chvíli v úmyslu přehodit na ten "POE" pár, ale takto asi bude možnost do toho spodního RB vlézt a možná něco odhalím (pokud nebude seklý totálně). mpcz, 22/12/2018

[rsaf]

Tak pokud by se úplně zasekávalo zařízení dole - více kusů a více různých, pak je to asi prostředím nebo napájením (např. od spínání nějakého homemade/šmejd stmívače...).
Pak mě ještě napadá bordel v elektrorozvodech (upadlý PEN) díky čemuž se můžou na ethernetu objevit různé rozdílné potenciály - zkusil bych napájení spodního rádia přes PoE z půdy.
Kabel je stíněný?

[mpcz]

Zdravím, tak nakonec došlo k nočnímu výjezdu, přestalo je to bavit to vypínat a zapínat. Vyzbrojil jsem se kromě klasického "digitálního čínského" měřiče na přerušené žíly a zkraty i "moderním" měřičem izolačního odporu z družstva invalidů PU371, který jsem úspěšně používal před 40 lety na zemní kabely. Žíly stíněného kabelu byly všechny okruhově OK, ale pozor, PU-čko našlo na některých žílách kolísající svody desítek až stovek kiloohmů. Vybral jsem žíly izolačně čisté a ty dva čisté páry jsem použil. Link ihned naskočil a od té doby už netwatch neposlal ani jednu poruchovou SMS o ztrátě konektivity do domácí wifinky klienta.
V prsa se ovšem nebiji, protože po otevření logu routeru na půdě je vidět, že je sice situace stabilizovaná, ale k odlinkování dochází i nadále, pouze s tím rozdílem, že pouze na sekundu/dvě a hlavně se to hned zbrchá. Udělá to takový shluk cca 2x denně. Domácí wifinka od té doby nevykazuje žádný restart.
Paket s eth. protokolem 9003 se tam vyskytuje často i nadále, v helpu jsem o něm našel jakési pojednání, ale nic o tom, jak najít příčinu. mpcz, 23/12/2018

14:00:18 dhcp,info dhcp1 deassigned 192.168.114.115 from 00:FC:F6:09:C3:CC
14:00:18 dhcp,info dhcp1 assigned 192.168.114.115 to 00:FC:F6:09:C3:CC
14:09:25 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link down
14:09:26 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link up (speed 100M, full duplex)
14:33:37 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link down
14:33:39 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link up (speed 100M, full duplex)
15:37:20 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link down
15:37:22 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link up (speed 100M, full duplex)
15:37:24 system,info address changed
15:37:40 system,info address changed
15:51:55 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link down
15:51:57 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link up (speed 100M, full duplex)

[rsaf]

Ale ten paket přece není příčina. Pokud je někde nějaký loop detect, tak je ten paket OK. Jak myslíš, že se pozná smyčka? Vyšleš si něco svého a pokud se to vrátí, je smyčka.
Formát toho co posíláš je dobré zvolit takový, který se na síti moc nevyskytuje aby (žralo by to výkon) a snadno se to odlišilo (ideálně v tcam). Takže prostě vlastní ethertype.

Megmetem jsem UTPčko tedy nikdy neměřil, ale pokud je měřící napětí jen 100V tak bych čekal svody v řádu MOhm - to by ukazovalo na poškozený, třeba zatečený, kabel.

[KoZLiCeK]

Zdravím, tak nakonec došlo k nočnímu výjezdu, přestalo je to bavit to vypínat a zapínat. Vyzbrojil jsem se kromě klasického "digitálního čínského" měřiče na přerušené žíly a zkraty i "moderním" měřičem izolačního odporu z družstva invalidů PU371, který jsem úspěšně používal před 40 lety na zemní kabely. Žíly stíněného kabelu byly všechny okruhově OK, ale pozor, PU-čko našlo na některých žílách kolísající svody desítek až stovek kiloohmů. Vybral jsem žíly izolačně čisté a ty dva čisté páry jsem použil. Link ihned naskočil a od té doby už netwatch neposlal ani jednu poruchovou SMS o ztrátě konektivity do domácí wifinky klienta.
V prsa se ovšem nebiji, protože po otevření logu routeru na půdě je vidět, že je sice situace stabilizovaná, ale k odlinkování dochází i nadále, pouze s tím rozdílem, že pouze na sekundu/dvě a hlavně se to hned zbrchá. Udělá to takový shluk cca 2x denně. Domácí wifinka od té doby nevykazuje žádný restart.
Paket s eth. protokolem 9003 se tam vyskytuje často i nadále, v helpu jsem o něm našel jakési pojednání, ale nic o tom, jak najít příčinu. mpcz, 23/12/2018

14:00:18 dhcp,info dhcp1 deassigned 192.168.114.115 from 00:FC:F6:09:C3:CC
14:00:18 dhcp,info dhcp1 assigned 192.168.114.115 to 00:FC:F6:09:C3:CC
14:09:25 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link down
14:09:26 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link up (speed 100M, full duplex)
14:33:37 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link down
14:33:39 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link up (speed 100M, full duplex)
15:37:20 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link down
15:37:22 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link up (speed 100M, full duplex)
15:37:24 system,info address changed
15:37:40 system,info address changed
15:51:55 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link down
15:51:57 interface,info ether4 - SU od 22.12.2018 - pro NETIS - DHCP 192.168.114.0/24 link up (speed 100M, full duplex)

vymenil bych kabel.Idealne za FTPcko.

[mpcz]

Ideálně si přečíst alespoň pár příspěvků zpět. Kabel vyměnit nelze, už JE stíněný a tak zbývá pouze řešit to, jestli ta výměna náhodou není zbytečná.
Mimoto, je zajímavý ten čas spadnutí linku, ten mi přijde (i když nevím proč) divný, že je to pravidelně sekunda/dvě. Navíc, při měření rychlosti to jede pravidelně a dlouhodobě klasických 97/97 Mbit, (než se to sekne totálně) což nějak jistě na poruchu kabelu neukazuje. Ty funkční páry jsou změřeny a ručím za jejich funkčnost. Ten starodávný MEGMET PU371 100/500V a Ohmetr používám již 40 let a nikdy mě to nezklamalo. Pokud MP řekly, že je kabel čistý, vždycky BYL čistý. Skoro začínám věřit, že se bude jednat o nějakou méně známou funkci/chybu od Sergeje, která se projevuje pouze při nějaké souhře okolností. A ta chyba ve vypisování času pádu a nahození linku také možná naznačuje, že tam není něco ve stoprocentním pořádku. Napsal jsem Sergejovi, co si o tom myslí on, uvidíme. mpcz, 25/12/2018

[KoZLiCeK]

Ideálně si přečíst alespoň pár příspěvků zpět. Kabel vyměnit nelze, už JE stíněný a tak zbývá pouze řešit to, jestli ta výměna náhodou není zbytečná.
Mimoto, je zajímavý ten čas spadnutí linku, ten mi přijde (i když nevím proč) divný, že je to pravidelně sekunda/dvě. Navíc, při měření rychlosti to jede pravidelně a dlouhodobě klasických 97/97 Mbit, (než se to sekne totálně) což nějak jistě na poruchu kabelu neukazuje. Ty funkční páry jsou změřeny a ručím za jejich funkčnost. Ten starodávný MEGMET PU371 100/500V a Ohmetr používám již 40 let a nikdy mě to nezklamalo. Pokud MP řekly, že je kabel čistý, vždycky BYL čistý. Skoro začínám věřit, že se bude jednat o nějakou méně známou funkci/chybu od Sergeje, která se projevuje pouze při nějaké souhře okolností. A ta chyba ve vypisování času pádu a nahození linku také možná naznačuje, že tam není něco ve stoprocentním pořádku. Napsal jsem Sergejovi, co si o tom myslí on, uvidíme. mpcz, 25/12/2018

Tak na takove laborovani bych nemel cas.Vymenil bych RB a netis (aktivni prvky na koncich kabelu) a pokud by to stale blblo tak kabel.

[mpcz]

Tak speciálně shrnu co je několikrát opakováno výše pro kolegu Kozlicka: Kabel vyměnit NELZE, už JE stíněný a tak zbývá pouze řešit to, jestli ta výměna náhodou není zbytečná, (čemuž začínám i trošku věřit), koncové prvky vyměněny beze změny několikrát i za jiné typy. V současné době se problém projevuje pouze zalogováním pádu linku v RB na půdě na 1 sec, přičemž spodní stroj to v logu nemá. I když zůstává pár nesrovnalostí a podivností, klient je nyní stabilizován a to je hlavní. mpcz, 25/12/2018

[KoZLiCeK]

Tak speciálně shrnu co je několikrát opakováno výše pro kolegu Kozlicka: Kabel vyměnit NELZE, už JE stíněný a tak zbývá pouze řešit to, jestli ta výměna náhodou není zbytečná, (čemuž začínám i trošku věřit), koncové prvky vyměněny beze změny několikrát i za jiné typy. V současné době se problém projevuje pouze zalogováním pádu linku v RB na půdě na 1 sec, přičemž spodní stroj to v logu nemá. I když zůstává pár nesrovnalostí a podivností, klient je nyní stabilizován a to je hlavní. mpcz, 25/12/2018

tak kdyz kabel s konektorama je ok. tak uz zbyvaj jen aktivni veci ja konci kabelu.vymenit za novy a hotovo.(to rb je uz stejne historie a netis sra..a)

[hapi]

vyhoď tu RB433.