Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 ... 46 47 [48] 49 50 ... 84
706
Server / Re:Server pro malou firmu
« kdy: 23. 01. 2020, 19:03:50 »
Až na ty kamery mi přijde, že to musí zvládnout kde co. Otázkou je jestli kupovat přímo server nebo vzít nějaké lepší
pc.

Dělal jsem 6 Vivotek kamer (točí HD) připojených na Intel NUC za pár tisícovek, vím že to není žádný super řešení a ten jeden disk je tam fakt na hraně, ale na to jakej jsem měl rozpočet a další podmínky to hraje super. Takže pokud není potřeba dělat na tom "serveru" postprocesing, jako detekce pohybu, rozpoznávání objektů,... tak není potřeba žádnej super HW,...

Odpusťte mi zvědavost: Nuc? Do toho se vejde dovnitř disk? Nebo zvenčí? Nebylo by upřesnění - jaký disk a jakou sběrnicí připojený? (USB/SATA) Dělám do včel, zajímají mě "takticko-technická data" - Vaše odpověď mi řekne, kolik má to úložiště cca IOps. A pokud to není obchodní tajemství: jaký software ty streamy ukládá na disk? Něco specifického na tom serveru (RTP sběrač / RTSP povelovač, HTTP olizovač), nebo kamery sypou data do souborů na SMB/NFS share apod? Jaký dává jedna kamera bitrate / počet snímků za sekundu?

707
Já pořád nějak nechápu, proč bych měl v PVLAN dělat proxy ARP, k čemu by mi to bylo?
No v technické rovině, pokud chcete aby na sebe "izolované" porty v rámci PVLAN navzájem neviděly, tak halt se nebudou vidět ani pro potřeby ARPu. Napřímo neproleze ani ARP request, ani ARP response. Proto jim bude promiskuitní default gateway dělat prostředníka ("proxy") i v tom ARPu. Potažmo skrz gateway pak poteče i všechen užitečný provoz.

A pokud se ptáte "ale k čemu to všechno", jako že konkrétní use-case / scénář... to je taky dobrá otázka. Třeba chceme šetřit adresním prostorem, proto všichni účastníci v jednom subnetu, ale zároveň nechceme, aby se navzájem ohrožovali, a jenom dost vyjímečně mají potřebu a nárok, bavit se navzájem zcela konkrétním a dobře filtrovatelným protokolem - a v tom případě je chceme nějak filtrovat routerem/firewallem (nad rámec toho, co zvládnou dnešní switche v hardwaru i "napřímo", a že toho zvládnou poměrně dost). Aneb dosaďte si své vlastní paranoidní zadání :-)

No... tohle mi nejde moc do hlavy. Na ingressu přiletí paket. Poslat ho do obou VLAN by znamenalo, ten paket zdvojit/naklonovat a dát každé kopii jinou značku. Protože v paketu je VLAN tag jenom jeden. Pro "point to point" spojení (TCP relace) toto nedává smysl. Pro komunikaci jednotlivými pakety by to pro některé aplikace smysl mít mohlo... ale je to divoké.

Podle mě by neposílal dva packety. Představte si switch, který má jednu ARP pro všechny VLAN společnou. Potřebujete odeslat packet a zeptáte se Who Has IP a povolíte to proswištět do všech portů v obou VLAN. Odpoví však jen jeden konkrétní. Získáte MAC a pak už switch ví, kam další (L3) provoz posílat. VLAN fungují na mnoha switchích "jen" jako filtr, které porty vynechat při přepínání.

A tak to potom jo, takhle tomu rozumím.
Tzn. v rámci switche se nerozhoduje podle VLAN tagu, ale podle ingressového portu a sady filtrů.
Tzn. dilemma nastane ve chvíli, kdy je případně třeba paket označkovat = na egressu do nějakého trunku, který nese obě VLANy.
BTW nepleťte si prosím ARP tabulku (L3) s FDB=CAM tabulkou (L2) - ale kromě toho jednoho slůvka se zbytkem souhlasím, včetně toho jak ARP request už si svého adresáta najde, a pak se naučí MAC adresa tázaného stroje na konkrétním portu (objeví se v CAM tabulce) - toto napříč dvěma VLANami (implementováno filtrem).

708
Takže si představte "primární" ... aplikační odpověď proletí stejným způsobem na dva hopy opačným směrem.

Rozumím. A co je v tom za problém?

...tak... já jsem asi neměl v úmyslu, dělat z toho tragédii :-) ale děkuji za nahrávku ;-)

Jistě uznáte, že je to uspořádání dost nezvyklé. Obecně proxy ARP je taková berlička, historicky pro zařízení s dementním IP stackem, kterému nešlo nastavit default route (nepočítal s provozem mimo lokální subnet). Tradičně se o tom tvrdilo, že je to nečistá věc, narušuje normální života běh, zvyšuje zátěž na routeru, přidělává správci bolení hlavy a po nocích žere osamělá malá koťátka.

Zas pokud "promiskuitní" gateway odpovídá na *všecky* ARPy "jasně, to jsem já", tak s tím asi moc práce navíc nemá, protože prohledávat nějaký seznam nemusí. ARP tabulka se seznamem klientů v LAN funguje v gatewayi zřejmě normálně. Čili zbývá případná námitka, že protáhnout všechen provoz v LAN segmentu skrz gateway a zase zpátky je mrháním kapacitou LAN a výkonem gatewaye, ale v principu... pokud tohle nakonfigurujeme, tak přeci přesně tohle jsme chtěli, žejo?

Něco v tom smyslu jsem v nějakých čínských návodech taky zaznamenal, ale vždycky jsem to hodil za hlavu s tím, že mám asi vlčí mlhu, nebo že documentation writer rozumí spíš angličtině než základním principům. Na egressu bych tomu rozuměl: přijde paket s jednou nebo druhou značkou, vypadne vždycky tímhle portem. Ale opačným směrem lze ten paket poslat pochopitelně jenom do jedné z obou VLAN. Do které? No tak se jedna určí jako default. Nojo, ale pokud je to odpověď na dotaz "z ne-defaultní VLAN", tak se tazatel odpovědi nedočká. Tzn. možné to asi je, ale praktický smysl v tom moc nevidím.

Já si myslím, že port nastavený do dvou VLAN to pošle do obou. ARP mu odpoví (snad) jen z jedné. Ale účel toho fakt nechápu.

No... tohle mi nejde moc do hlavy. Na ingressu přiletí paket. Poslat ho do obou VLAN by znamenalo, ten paket zdvojit/naklonovat a dát každé kopii jinou značku. Protože v paketu je VLAN tag jenom jeden. Pro "point to point" spojení (TCP relace) toto nedává smysl. Pro komunikaci jednotlivými pakety by to pro některé aplikace smysl mít mohlo... ale je to divoké.

Jinak ono i na tagovaném (trunkovém) portu reálně žije dost netagovaného provozu - především všelijaké režijní protokoly. Třeba STP nebo všelijaké průmyslové protokoly pro kruhovou redundanci jedou nad LLC, což je "režijní subvrstva" v rámci L2, enkapsulovaná v rámcích 802.2/802.3 - kdežto užitečná TCP/IP data jedou v enkapsulaci "Ethernet II" (a těch se týká tagování/trunkování). Ono lze na VLANu nahlížet buď jako na "rouru pro payload", nebo jako bezbranný atribut v hlavičce paketu. A co jsem viděl, jak se switche chovají třeba k IEEE1588=PTP, tam je VLAN tag taky spíš jako atribut, než jako roura. Případně může jet PTP mezi switchi netagovaně, smícháno s tagovanými rámci ostatního payloadu...

709
Ono se tím zřejmě dá např. stáhnout i L3 provoz v rámci L2 segmentu tak, aby tekl skrz default gateway, kde se dá na L3 ofiltrovat (je potřeba tomu trochu pomoct proxy ARPem).

Nechápu..?
[...]
Nemám vyzkoušeno, ale mělo by to fungovat tak, že broadcasty z promiscuous uslyší všichni. Broadcasty z community uslyší všichni v rámci komunity + všichni promiscuous. Broadcasty z private uslyší jen promiscuous porty.

Takže si představte "primární" VLAN ošetřenou pomocí jediné PVLAN v režimu "isolated", na ní několik klientů a jedna gateway v režimu "promiscuous". Mezi klienty v rámci subnetu chcete navzájem na L3 omezeně komunikovat, ale nechcete, aby se viděli přímo na L2. Takže jim "isolated" režimem zabráníte, aby o sobě na L2 navzájem jakkoli napřímo věděli. Pokud takto izolovaný klient pošle ARP "who has", bez dalšího ošetření by se mu nikdo neozval. Proto je údajně možnost, na gatewayi rozjet "proxy arp", tipuju automatický pro celý subnet. Prostě když se izolovaný klient zeptá ARPem na libovolnou adresu, ozve se mu (ARP "is at") bez rozmýšlení gateway: "já gateway mám tuhle adresu". A klient pošle svůj dotaz "sousedově IP adrese" na MAC adresu gatewaye. Gateway ten paket přijme, na třetí vrstvě prohlédne, zjistí že ho má poslat zpátky do rozhraní, ze kterého paket přišel, ale s tím se počítá - pokud paket vyhoví pravidlům, odešle ho zpátky tímtéž rozhraním, ovšem jinému izolovanému klientovi... A aplikační odpověď proletí stejným způsobem na dva hopy opačným směrem.

Na některých switchích jsem viděl ještě horší věc: port, který je v access režimu a zároveň ve více VLAN. To teprve musí být bordel a bezpečnost vniveči.
Něco v tom smyslu jsem v nějakých čínských návodech taky zaznamenal, ale vždycky jsem to hodil za hlavu s tím, že mám asi vlčí mlhu, nebo že documentation writer rozumí spíš angličtině než základním principům. Na egressu bych tomu rozuměl: přijde paket s jednou nebo druhou značkou, vypadne vždycky tímhle portem. Ale opačným směrem lze ten paket poslat pochopitelně jenom do jedné z obou VLAN. Do které? No tak se jedna určí jako default. Nojo, ale pokud je to odpověď na dotaz "z ne-defaultní VLAN", tak se tazatel odpovědi nedočká. Tzn. možné to asi je, ale praktický smysl v tom moc nevidím.

710
Odpusťte malý přílepek. Náhodou jsem narazil na cosi "pro mě nového" k VLANám a vzpomněl jsem si na tohle nedávné téma (které už stejně mezitím trochu převálcovalo původní dotaz, takže se snad nic nestane, když přidám ještě toto).

Všiml jsem si na taiwanských průmyslových switchích různých značek fičury zvané "private VLAN" - v průběhu posledních let několikrát, ale nevěnoval jsem tomu pozornost, považoval jsem to za čínskou inovaci. Ale když jsem potkal třetí značku, která to má ve firmwaru, začal jsem "větřit změnu počasí". Taiwanci to nemívají nikde v kostce popsáno "v koncepční rovině" - a jednotlivá konfigurační okýnka mívají v návodu popis cca "toto je konfigurační okýnko". No a usvědčil jsem se z neznalosti - ono to zřejmě přišlo původně od Cisca. Už před 10 lety o tom psal Petr Bouška na Samurajovi. V trochu sušším podání se lze něco dočíst na Wikipedii.

O co jde? Dá se tím detailněji regulovat "viditelnost" mezi porty v rámci VLANy navzájem. Dá se nastavit jeden port (obvykle L3 default gateway) jako "promiskuitní" (dá všem), a klientské porty jako "navzájem izolované". Nebo lze nastavit i klientské porty jako "komunitní" = smí se bavit mezi sebou navzájem. Na Ciscu je to tak, že v rámci konkrétní rodičovské VLANy se dají vykolíkovat menší podmnožiny / sub-VLANy, a v každé z nich se dá říct, jestli mají být porty v jejím rámci "izolované", nebo "komunitní". Přitom se všechny smí bavit s týmiž "promiskuitními" porty v rámci VLANy a klidně sdílejí L3 subnet. Číňani to zřejmě mají implementováno o něco jednodušeji / v detailech jinak, ale pozoruju tam podobné konfigurační opšny. Prostě doteď jsem žil v představě, jak jsou VLANy jednoduchá a přehledná záležitost, včetně třeba Q-in-Q, a teď jsem poznal jeden stinný kout, kde... Sodoma Gomora. Ono se tím zřejmě dá např. stáhnout i L3 provoz v rámci L2 segmentu tak, aby tekl skrz default gateway, kde se dá na L3 ofiltrovat (je potřeba tomu trochu pomoct proxy ARPem).

Zatím jsem si na to nesáhl rukama a není mi jasné, co to má za dopad třeba na funkce založené na L2 broadcastu (jiné než kde broadcastuje default GW). Může to být asi dost mazec.
Na první pohled mám pocit, že o toto by se měl starat někdo, kdo ví co dělá a dokáže dost podrobně ladit případné konfigurační přehmaty/nedomyšlenosti. Nic pro čarodějova učně, který zrovna zvládnul základní bezelstné VLANy.

711
Server / Re:Přenos velkého množství dat po síti
« kdy: 21. 01. 2020, 11:58:08 »
Disky na serverech mountovat s -o noatime, pokud jsou točivé a mohly by se stát úzkým hrdlem.

Pokud je to v LANce, asi má smysl také do /etc/sysctl.conf
Kód: [Vybrat]
net.ipv4.tcp_slow_start_after_idle=0
alias
Kód: [Vybrat]
echo 0 > /proc/sys/net/ipv4/tcp_slow_start_after_idle
(default je 1 = zapnuto = ohleduplný rozjezd TCP přenosů)

Pokud jde o nějakou WAN ve které lze očekávat cestou úzká hrdla, tak bych ji tímhle asi netrápil - tzn. nechal bych to v defaultu = 1 = ohleduplné chování TCP relací.

712
Hardware / Re:Astrometa DVB-T2 ladí jen DVB-T
« kdy: 21. 01. 2020, 06:59:42 »
jsou tam dve, ale chovaji se stejne.
Kód: [Vybrat]
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 01)
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)

To je divné, 10ec:8168 jsou skutečně klasická IDčka, modul r8169 by je měl podporovat, ve zdrojáku vidím jasně
Kód: [Vybrat]
PCI_VDEVICE(REALTEK,	0x8168)

Jestli má ta mašina něco za sebou, nemáte ten modul jenom historicky blacklistovaný? Třeba pomocí
Kód: [Vybrat]
/etc/modprobe.d/blacklist.conf

Ten soubor se může jmenovat všelijak, důležité je, že by měl obsahovat řádek
Kód: [Vybrat]
blacklist r8169
Nebo r8169 vážně vůbec není přítomen v tom backportovaném kernelu?
Kód: [Vybrat]
find /lib/modules/ -name "r8169.ko" -print

Já pokud z různých důvodů potřebuju čerstvější kernel, tak si kompiluju ze zdrojáků vanilku, takže backportovaný v zásadě neznám.

713
Hardware / Re:Astrometa DVB-T2 ladí jen DVB-T
« kdy: 20. 01. 2020, 21:28:52 »
Ovladač r8169.ko Vám nevyhovuje?

Aha, našel jsem nějaké vlákno, načaté v roce 2011, kde se doporučuje kompilovat ze zdrojáků driver od Realteku.
Že údajně je r8169 rozbitý. Fakt je to ještě rozbité? Já si jenom velmi matně vybavuju, že jsem to jednou kdysi v tomhle kontextu taky kompiloval ze zdrojáků "out of tree", ale to je snad 10 let zpátky. Posledních několik let jedu pár Realteků na r8169 na gigové síti a nějak si neuvědomuju, že bych s tím měl jakýkoli problém... Dovedu si představit, že by se do toho mohli míchat Gremlini v oblasti ASPM, ale to by snad mělo jít řešit (vypnout) i jinak, než kompilovat zastaralý Realtečí driver...

714
Hardware / Re:Astrometa DVB-T2 ladí jen DVB-T
« kdy: 20. 01. 2020, 21:09:37 »
Cožeto?
Ultra-klasickej Realtek RTL8168/8169 že nemá ovladač ve vanilce?
Vedle Intelu e1000e/igb ta vůbec nejrozšířenější síťovka?
Ovladač r8169.ko Vám nevyhovuje? Nebo v tom backportovaném kernelu nebyl?
Pokud nevyhovuje tak proč, proč proboha kompilujete driver pro tuhle fakt nejběžnější síťovku, pro úplně nejnovější kernel, skrz berličku zvanou DKMS?
Něco jsem přehlíd? Ta Vaše síťovka má divná PCI IDčka, že se na ni vanilkový driver nechytí?
Fakt se nechytil od přírody, že ho řešíte ručně? :-O

715
Sítě / Re:Kamerový systém nefunguje s novým PoE switchem
« kdy: 19. 01. 2020, 23:47:49 »
Čili: prověřte možnost, že Vám nesedí "mode" A vs. B mezi novým switchem a kamerou!
To je jedna možnost, ale PD by mělo podle normy podporovat obě varianty.
Nedělám si srandu, v té kameře co jsem měl na stole bylo na první pohled v PoE vstupu cosi blbě - všechny čtyři páry na dva Graetze určitě neměla. Proto říkám: rozebrat a prověřit.

Jo a díky za rozsáhlou korekturu :-)

716
Hardware / Re:Astrometa DVB-T2 ladí jen DVB-T
« kdy: 19. 01. 2020, 23:40:41 »
Jo a spíš než w_scan nebo i w_scan2 doporučuju t2scan.

717
Sítě / Re:Kamerový systém nefunguje s novým PoE switchem
« kdy: 18. 01. 2020, 20:08:18 »
Asi ti moc nepomůžu, jen upřesním jednu věc. Mám jinou Hikvision kameru a u ní je to nejspíš stejný - Ta kamera chce 12V NEBO PoE 802.3af (což je 48V). Těch 12V je přes takovej ten klasickej kulatej konektor no a POE je RJ45. Jsou tam asi dva nezávislý měniče na nízký napětí (3,3V?) spojený paralelně na výstupu co napájí vnitřní logiku no a ten jeden je optimalizovanej pro fungování na 48V a druhej na 12V. Jak říkám - jen pro upřesnění

Velmi správně! Tesat. Snad bych jenom opravil, že ty dva měniče jsou nejspíš v kaskádě:

1) z RJ45 je krmený měnič, který bere "48V jmenovitých", tzn. reálně by měl přežít až k 60V a reálně se spokojí možná i
s mnohem méně - ale 12V mi přijde málo, řekl bych až na hraně

2) dutý konektor "12V" je uvnitř kamery připojený paralelně s výstupem prvního snižujícího měniče, a navazuje druhý měnič, který vyrábí interních 3.3V nebo kolik. Čekal bych těch větví možná i víc, 3.3V je na dnešní procesory poměrně vysoké napětí, hodí se spíš pro vnější rozhraní, pro "core logic" vídám spíš větve 2.5/1.8/1.5 nebo až kolem 1 Voltu. Tenhle druhý měnič taky nebude úplně vybíravý, je to prostě buck converter, odhadem by přežil třeba až kolem 16 V a spokojí se možná i se 7-9 Volty.

Ono to má taky tu logiku, že vyrábět malá napětí 3.3V a méně "buck" konvertorem přímo z cca 50 V nevychází konstrukčně moc dobře, ten "transformační poměr" je prostě moc velký, těžko se volí součástky aby pracovaly v optimálním režimu. S mezipřistáním na 12V to dává mnohem lepší smysl.

Diky za reakci. Mel jsem to vzdy pres PoE nic se na tom nemenilo ten kulaty konektor se nikdy nepouzil.

Otázka je, zda jste si vědom pár dalších nuancí okolo "PoE".

Pokud je někde napsáno 802.3af/at, očekává se jmenovité napětí na drátech 48 V a handshake.
"Power Sourcing Equipment" tzn. switch nebo injektor se má napřed zdvořile zeptat (nějakým slabým proudem) zda protistrana podporuje normu, a pokud ne, tak nepustí napájení.
"Powered Device" = koncové zařízení = kamera by měla handshake podporovat, jinak od košer 802.3af/at injektoru nedostane krmení. Ale pokud naopak přiložíte na dráty 48V pasivním injektorem, tak kamera nejspíš pojede, handshake nehandshake - a dost možná se spokojí i s nižší hladinou, třeba 24V, protože ten buck converter nebývá dvakrát vybíravý a neodpojí se, pokud nedostane na začátku zdvořilý handshake (ale rovnou tvrdé napájení). Pokud toto pácháte, měl byste si sám zajistit nadproudovou ochranu.

Další věc: standardní 802.3af/at PoE se vyskytuje ve dvou variantách pinoutu. V zásadě:
Mode A = napájení je na oranžovém páru proti zelenému
Mode B = napájení je na modrém páru proti hnědému.
Standard neříká, že správně je A nebo B. Obě varianty jsou možné. Standard tuším pouze říká, že se smí posílat napájení pouze po dvou párech - čili je třeba si vybrat, zda A nebo B, nikoli oboje současně. Což je trochu paradoxní ustanovení, s ohledem na věčný boj, jak skrz ty tenké drátky a přechodové odpory protlačit co nejvíc šťávy. Existují v Asii výrobci, kteří vyrábějí injektory využívající právě všechny čtyři páry naráz, a prodává se to s velkou slávou jako ultra-výkonná varianta PoE (až 60W na port, tzn. 2x tolik co 802.3at). Každopádně tato vlastnost je rarita, zcela určitě na straně injektoru (PSE).

Pokud mohu soudit, 802.3af/at-kompatibilní injektory a switche obvykle umí mode A, a v tom případě *pouze* mode A. Tzn. pokud se jedná o stovkový Ethernet (data tečou pouze po oranžovém a zeleném páru) tak je konstrukčně zvolena "složitější cesta", napájení je přiloženo frekvenční výhybkou (nebo středovou odbočkou na signálovém trafu) na páry, které zároveň přenášejí užitečná data - namísto aby se napájení připojilo natvrdo na modrý proti hnědému, kde pak ani není potřeba výhybka, protože ty páry nejsou ve stovkovém Ethernetu využity pro data.

Naopak levné "nestandardní" PoE s použitím pasivních injektorů a na nižších hladinách (např. 12-24V, klasicky Mikrotik) s oblibou využívá modrý proti hnědému. Chtělo by se řící "mode B", až na to, že to jinak nelze označit za 802.3af/at compatible PoE (napětí je blbě a chybí handshake). Jako injektor/splitter de facto stačí, nakrimpovat si svůj vlastní patchcord, ze kterého si odbočíte modrý a hnědý pár a čokoládou připojíte na napájecí měnič (do krimpované RJ45 přijde jenom oranžový a zelený). Levné injektory/splittery za třicet korun jsou přesně toto, jenom v cudné krabičce z Číny.

Slušná koncová zařízení (PoE PD) obvykle obsahují "dvojitý Graetz" = paralelně dva Graetzovy můstky, a na jejich vstupy se připojí středové odbočky všech čtyř vinutí na "linkové straně" signálového trafa. No a tím se možná dostáváme k dalšímu jádru pudla :-)

Měl jsem před pár lety na stole nějakou čínskou kameru, ne úplně nejlevnější, měla tuším i mechanické naklápění ve dvou osách a dost slušně citlivý snímač pro noční provoz. Kolega ji přinesl s tím, že "je úplně nová, ale ani nepípne". Záruční samolepky kupodivu neměla, takže jsem vlezl dovnitř... a došel jsem tuším k tomu, že funguje při napájení 12V dutým konektorem, a že PoE má zřejmě skutečně 802.3af/at compliant (obsahovala PD controller chip a měnič na 48V) ale je možné, že tehdy brala napájení jenom z hnědého a modrého. Nerad bych kecal, ta vzpomínka je matná, už je to dávno a nedokážu dohledat žádný záznam.

Čili: prověřte možnost, že Vám nesedí "mode" A vs. B mezi novým switchem a kamerou!

Když říkáte, že jste to doteď napájel PoE a "nějak to šlo", co to bylo zač? Košer 802.3af, na drátech 48V? Nebo nějaká pasivní/nestandardní varianta? On PoE standard ne nadarmo říká, že na 48V lze dodat až 15W na výstupu PSE (tzn. na PD mínus úbytky na vedení a kontaktech). Problém je maximální proud, který je to schopno přenést. Pokud po drátech pošlete pasivním injektorem a splitterem 12 V, tak při shodném proudovém omezení máte šanci poslat do drátů nějaké 4W - ovšem to nezohledňuji skutečnost, že určitý konkrétní úbytek napětí ze jmenovitých 48V bolí podstatně míň, než tytéž "ztracené volty" ze jmenovitých 12V! Takže reálně na 12V protlačíte spíš ještě mnohem míň. Ona ta kamera co jsem ji měl rozebranou taky nežrala jmenovitých 5W trvale, ale spíš 2W. Tzn. je možné, že jste prostě na hraně s těmi úbytky, zejm. pokud nevíte přesně, co děláte. Odtud moje zcela základní pravidlo: "měřit, měřit, měřit". Co si nezměřím, to nevím! Mnohokrát jsem zažil sáhodlouhé teoretické debaty všelijakých teoretiků, dokud jsem nepřiložil hrot multimetru, nebo ještě lépe sondu osciloskopu. A bylo po debatě :-D

A souhlasím s Wangarad, že by stálo za to, pokud kamery nějakou dobu fungovaly, tak zkontrolovat kondíky v měničích uvnitř - aspoň vizuálně. Vsadil bych se, že nějaký vodnatý elyt tam bude. Náhrada polymerem je první věc, co bych zkusil.

Tzn. přimlouvám se: vlezte do té kamery dovnitř. Nemusíte loupat optiku od snímače, jenom sundejte kryt a podívejte se, co je uvnitř. Nejspíš Vám to bude celé jasnější.

Optimálním měřícím přístrojem pro diagnostiku spínaných měničů je bohužel osciloskop - pokud je tam sušený kondík a na něm VF střídavina, ukáže multimetr leda halušky. Pokud jsou měniče v pořádku, měl by Vám multimetr stačit. Prostě řemeslník se pozná podle vercajku.

Pokud ten problém dohledáte = změříte, případně pořešíte jedno-dvě kurvítka, a není tam ochozeného něco dalšího (hlavně mechanické díly pohonů), možná Vám budou staré kamery ještě dlouho věrně sloužit. Pokud je bez diagnózy vyhodíte a koupíte nové v podobné cenové relaci, tím jste se neposunul o moc dál - nic jste se nenaučil a možná si zopakujete nějakou předchozí chybu. Přispějete na hromadu elektro-šrotu a podpoříte výrobce v plánování životnosti.

718
Sítě / Re:rozdeleni switche
« kdy: 17. 01. 2020, 12:05:16 »
Ano, některé lepší switche umí oddělené FDB per VLAN.

Díky za potvrzení. Právě jsem matně vzpomínal, že na Catalystech jsem někdy (většinou to byly chyby!) viděl MAC na více vlanách a marně jsem si dnes lámal hlavu, proč by měly mít switche jen jednu tabulku bez odlišení, jestli je k tomu racionální důvod (kromě zlevnění návrhu).

Podle mého je to prostě výsledek postupného inkrementárního vývoje. Když se do switchových čipsetů přidávaly VLANy, tak na mechanismy fungování FDB vlastně nebylo třeba šáhnout (učení adres a následně procházení tabulky při forwardovacích rozhodnutích), jenom se přidal nějaký filtr podle VLAN ID a logika přidat/odstranit značku (per port). Per-VLAN FDB znamená, že je třeba FDB rozšířit o další pole (Vlan ID) a "třídící klíč" tím o pár bitů narostl... Ani nevím, jestli je sdílená FDB stanovena jako součást 802.1Q. On s tím tuším taky dál souvisí třeba Spanning Tree Protocol. Ten taky standardně nejede "per VLAN", ale globálně (untagged i na trunku?) Jak moc volně/těsně souvisí per-VLAN STP a FDB, to teď z hlavy nedám...

719
Sítě / Re:rozdeleni switche
« kdy: 16. 01. 2020, 21:40:49 »
„...it's possible to force a switch to re-learn a MAC address to a "wrong" port (= away from the correct port) by sending a packet with the "attacked" MAC address as a source address in the attacking frame (= MAC address spoofing), from an untagged port belonging to a different VLAN.“

Jak by to mělo fungovat? Přepínač odešle následné pakety určené pravému příjemci do VLAN útočníka? Když zavysílá pravý příjemce ze své VLAN, tabulka se opět přepíše zpět a útok končí? Co když má přepínač (jako např. Mikrotik RB260) zamykání portů k MAC?

Nenapadá mě, jak by se to dalo zneužít kromě DoS útoku - switch si bude myslet, že MAC adresa je v jiné VLAN, ale mezi VLAN packety nepředá. Tedy "odstřihne" od sítě oprávněného uživatele, nic víc se nestane. Nechci teď kecat, ale myslím, že lepší switche mají ARP oddělenou podle vlan, tam nehrozí ani to.

Některé switche umí zamknout port na stejnou MAC adresu - buďto úplně na pevno, nebo s karenční dobou (dalších X hodin je port uzamknutý). Tam, kde se řeší bezpečnost, se to používá. VLAN není jediným řešením bezpečnosti, je to jen jeden z nástrojů a jejich použití se řídí požadovanou úrovní bezpečnosti.

Přesně tak, lze to použít jenom pro DoS útok. I tohle riziko ale může někomu vadit.

A pak jsou nějaké... obskurní a staré rodiny protokolů nad Ethernetem v "průmyslu", které třeba používají tutéž MAC adresu na jakékoli síti pro nějakou well-known funkci. Potíž je, když takových sítí pustíte do VLANového switche několik paralelně. Polezou si navzájem do zelí.

Ano, některé lepší switche umí oddělené FDB per VLAN.

720
Sítě / Re:Datová síť v novostavbě
« kdy: 16. 01. 2020, 12:14:19 »
V coaxu byste potřeboval mnohem vyšší kmitočet na přenos stejného množství informací.

A co je na tom spatne? Pokud je bezny coax schopen prenaset 0-1500Mhz a mit tam (i diky stineni) 16384 QAM tak si spoctete jakeho dosahnete datoveho toku.

Popravdě jsem to myslel spíš tak, že je trochu zbytečné, pokud se bude tahat nový kabel tak jako tak, snažit se převodovat TV+SAT analogově do CAT5/6/7 nebo naopak přenášet Ethernet v dnešní době po koaxu. Prostě ty technologie mají každá nějakou svoji obvyklou nosnou vrstvu a materiálovou skladebnost a snažit se to ohnout přes koleno a poslat po nějakých jiných drátech je sice známka punku, ale mělo by to mít nějaký důvod (např. nemožnost natáhnout "ten správný" kabel).

Stran: 1 ... 46 47 [48] 49 50 ... 84