Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Jiri Dobry 24. 02. 2021, 12:24:43
-
Ahoj vsichni.
Schanim 100 Mbit/s ethernet HUB (opravdu HUB, ne switch). Potrebuji se podivat analyzatorem na data ethernet komunikace. A uz me dosla trpelivost s "mirror" funkci switche, protoze to preposlani paketu v nekterych pripadech pakety meni (specielne kdyz jsou pakety nevalidni, nebo se ruzne chova k 802.1Q casti a podobne, ruzne switche ruznych vyrobcu do toho zasahuji jinak).
Bohuzel se uz dloooouho bezne prodavaji jen switche (protoze pro normalni pouziti je to vhodnejsi, nez HUB, samozrejme). A HUB ktery mam v supliku je jen 10 Mbit/s.
Nemate nekdo tip, kde by se dal takovy (muzealni) HW koupit, pripadne nemate nekdo na prodej?
-
Na to nepotrebujes opakovacku, na to staci pasivni tap a pokud staci jeden smer tak obycejna rozdvojka za par korun..
http://internet.vzadeki.com/fotoarchiv/2009/eth_tap_scheme.png
-
Případně by mohlo jít použít linuxový stroj se dvěma síťovkama, udělat nad nimi bridge a na něm nastavit brctl setageingtime 0, čímž by měl efektivně zrcadlit provoz na oba porty.
-
Na optický singlemode se dá koupit splitter s navařenými konektory, např. LC. Nedávno jsem bral dva kusy v Alternetivu (https://www.alternetivo.cz/opticke-site-splittery-couplery_c2291.html), stály mě tuším pod dvě stovky za 1 směr (tzn pro odposlech duplexu jsou potřeba dva).
Splittery / hotový tap na optický multimode je tady u nás na tom hůř s dostupností. Před časem jsem si dovezl hotový "tap" (dva splitry v krabičce) od firmy Garland (https://www.garlandtechnology.com/multi-mode-passive-fiber-network-taps-1g-10g).
Jako odposlech k optickým tapům/splitterům jsou potřeba optické síťovky, což je jednodušší zařídit na gigabitu. Stovkové síťovky se dají taky nakonec nějak sehnat - bohužel dosud obecně slušně dostupné AT2711 od Allied Telesis (https://www.alliedtelesis.com/en/datasheet/2711-series) jsou jenom multimódové. Ale dají se objevit i další výrobci [ 1 (https://www.etherwan.com/products/en400-series) | 2 (http://www.lr-link.com/product/Desktop_Fiber_NIC_Cards/100BaseFXDesktopFiberNIC.html) ], kteří mají pevně osazený single-mode nebo SFP slot.
A na stovkovou metaliku jsem si postavil splitter na bázi odposlechu s rychlými operáky. Hezky plošák se symetrickými cestičkami... a jako každý můj bastl, ve verzi 0.9 to má nečekaný zádrhel: chybí tomu výstupní trafo, které jsem následně musel přidat zvenčí (vrabčí hnízdo). Jinak se mi soufázově rozkmitaly odposlechové zesilovače :-D
Pravda je, že jsem to kupoval a stavěl kvůli odposlechu PTP = potřeboval jsem skutečně nulové dodatečné zpoždění. Pokud takové nároky nemáte, tak má pravdu @uwe.filter, že by mohl stačit soft-bridge. Pokud ovšem nebude mrvit nějaké režijní "link-local" rámce, které byste rád odposlechl *v průběhu zdravé komunikace obou konců*.
BTW tuším jsou protokoly, které se na half-duplexu vůbec nerozběhnou = je otázka, zda byste si pomohl hubem. V tomto směru je duplexní pasivní tap lepší.
-
Případně snad i to nejlevnějsí managované Cisco (pár tisíc za PoE verzi) to umí https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960l/software/15-2_5_e/config-guide/b_1525e_consolidated_2960l_cg/b_1525e_consolidated_2960l_cg_chapter_011001.html
-
Případně snad i to nejlevnějsí managované Cisco (pár tisíc za PoE verzi) to umí https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960l/software/15-2_5_e/config-guide/b_1525e_consolidated_2960l_cg/b_1525e_consolidated_2960l_cg_chapter_011001.html
Schanim 100 Mbit/s ethernet HUB (opravdu HUB, ne switch).
-
Mam v Brne 16-port stary Intel hub (myslim, ze 10/100)
Pokud bys byl ochoten to vymenit za nejaky switch (8+ portu) tak se muzem domluvit, drzim ho jako zalozni zarizeni, pro pripad vypadku domaciho HW.
-
Případně snad i to nejlevnějsí managované Cisco (pár tisíc za PoE verzi) to umí
Problem je v tom, ze "port mirroring" neposila pakety presne tak jak je prijme a nektere nposila vubec. Pokud jsou totiz nevalidni na L2, dela si to co chce. Proto potrebuji "hloupe" zarizeni.
-
Mam v Brne 16-port stary Intel hub (myslim, ze 10/100)
Pokud bys byl ochoten to vymenit za nejaky switch (8+ portu) tak se muzem domluvit, drzim ho jako zalozni zarizeni, pro pripad vypadku domaciho HW.
Vymenim. Napisu PM.
-
Případně by mohlo jít použít linuxový stroj se dvěma síťovkama, udělat nad nimi bridge a na něm nastavit brctl setageingtime 0, čímž by měl efektivně zrcadlit provoz na oba porty.
Bridge preposle pouze validni pakety. Potrebuji se spolehnout, ze mam opravdu vsechny a ne resit stejny problem jako s "port mirroringem", kdy neco zataji, neco opravi.
-
Případně by mohlo jít použít linuxový stroj se dvěma síťovkama, udělat nad nimi bridge a na něm nastavit brctl setageingtime 0, čímž by měl efektivně zrcadlit provoz na oba porty.
Bridge preposle pouze validni pakety. Potrebuji se spolehnout, ze mam opravdu vsechny a ne resit stejny problem jako s "port mirroringem", kdy neco zataji, neco opravi.
Souhlas, bridge přepošle pouze validní pakety. Hubem proleze i vadný paket. Což na odposlouchávající síťovce poznáte nejspíš tak, že bude mít vadné CRC. Toto jsem asi ještě nepotkal, takže Vám nedokážu říct, jestli ten vadný paket dostanete až do wiresharku, nebo se jenom zvýší počítadlo chyb o jedničku (a paket si neprohlédnete).
Spíš než vadné pakety by mi vadilo, že Vám bridge může požrat (nepropustit) STP, LLDP/CDP, LACP, obecně provoz nad 802.2 LLC, možná okrájí VLAN tagy (třeba v závislosti na konfiguraci) apod. Nevím jestli linuxový soft-bridge nějak zasahuje do multicastingu (managed switche se zapnutým IGMP snoopingem tradičně všechen multicast sežerou). Cucám si to dost z palce, ale to byste už snadno poznal sám jestli něco chybí, porovnáním záznamů wiresharku ze dvou rozhraní.
-
Pokud je analyzator (zarizeni) k necemu, tak by prave takovy tap mel integrovat uz sam a to pro oba komunikacni smery, kdyz je pripojene zarizeni FDX. Kdyz totiz budete dekodovat traffic z hubu, znacne tim rozhodite CSMA/CD, a chte nechte budete muset zmenit sit na HDX, ale pak nepoznate z odbocky, ze ktera strana za dany paket muze.
@Rysanek - pasivni (at uz elektricky nebo opticky) tap pripojenej do bezne sitovky prece nechytne link (k tomu musi fungovat oba smery), nebo mate na to nejaky trik?
-
3com Super Stack II, Dual Speed Hub 500
24 portů
Za pivo, nebo poštovné (Příbram).
-
@Rysanek - pasivni (at uz elektricky nebo opticky) tap pripojenej do bezne sitovky prece nechytne link (k tomu musi fungovat oba smery), nebo mate na to nejaky trik?
Jo, je potřeba vypnout všelijaké chytristiky, vypnout autoneg a nastavit natvrdo konkrétní rychlost. Pak Eth portu stačí funkční RX - na optice i na stovkové metalice. (Na metalickém gigu je to celé jinak, to pasivně odposlechnout nejde.)
#!/bin/bash
for netdev in enp2s0 enp3s0
do
ethtool --set-eee $netdev eee off
ethtool --pause $netdev rx off tx off autoneg off
# unfortunately, forced mdix off is exlusive with autoneg off :-(
#ethtool -s $netdev mdix off
ethtool -s $netdev speed 100 duplex full autoneg off
ip link set dev $netdev up
done
-
Pokud je analyzator (zarizeni) k necemu, tak by prave takovy tap mel integrovat uz sam a to pro oba komunikacni smery, kdyz je pripojene zarizeni FDX. Kdyz totiz budete dekodovat traffic z hubu, znacne tim rozhodite CSMA/CD, a chte nechte budete muset zmenit sit na HDX, ale pak nepoznate z odbocky, ze ktera strana za dany paket muze.
Takovy analyzator mame taky. Byl drahy jak prase, nesikovne se pouziva a vyrobce se nyni tvari ze nikdy ani nic takoveho nevyrabel a nepodporovat. V praxi je sice HUB+wireshark omezenejsi reseni, ale vyzkousene a snaze pouzitelene. Blbe je, ze ted ve rezimu skoro vsichni na home office se ten HUB blbe pujcuje.
-
na to jsem před cca 3 lety používal Mikrotik za 500kč.
Měli jsme přoblém že nám nějaká HW ústředna na IP posílala jen fragmenty paketů, ... zjištěno nakonec
Mikrotik sám os sobě umí poslouchat a ukládat provoz do PCAP formátu.
Většina umí i microSD takže můžeš snifovat v podstatě nekonečně.
Pokud to chceš online do Wiresharku tak to umí i streaming.
-
Nepomohlo by tohle?
US $8.00 | Throwing Star LAN Tap 1.5 Network Packet Capture Mod Haker Tool 100% Original Replica Monitoring Ethernet Communication analysic
https://a.aliexpress.com/_m0dY635
-
Možno by bolo lepšie prezradiť či podozrievate hardware, alebo kabeláž. Od toho sa odvíja potreba nejakého vhodného riešenia detekcie problémov. Na problém s kabelážou bude zrejme krátky aj ten HUB ako niekto spomínal CSMA/CD.
-
Podezrelym je SW. Chybne sestaveny paket a embbeded SW nad RTOS.
-
Podezrelym je SW. Chybne sestaveny paket a embbeded SW nad RTOS.
Tohle SW neudělá - protože CRC spočítá přímo MAC. Podobné problémy ladím běžně, HUB Vám ani moc nepomůže, protože většina běžných séťovek paket s vadným CRC nepustí. Problém bude HW nebo semi-HW. Většina moderních PHY obsahuje vnitřní test módy, které je potřeba ověřit. Další problém může býr v odrazech na RMII/MII nebo jeho časování (hodinová hrana vůči datům, ale to bývá provlém spíš na gigabitu, na některých PHY to lze i naladit). Také jsem nedávno řešil problém s o 1% ujetýma hodinama, to byla lahůdka...
Další možnost je se na to podívat osciloskopem a treba sigrokem.
-
Podezrelym je SW. Chybne sestaveny paket a embbeded SW nad RTOS.
Na to by stacil taky aplikacni printf(), ne?
Pokud to nefunguje vubec (treba ze to usekava konce paketu), tak to bude zas spis v driveru sitovky neco ohledne bufferu - pred deseti lety jsem si taky uzil svy s ENC28J60 :-)
-
Tohle SW neudělá - protože CRC spočítá přímo MAC. Podobné problémy ladím běžně, HUB Vám ani moc nepomůže, protože většina běžných séťovek paket s vadným CRC nepustí. Problém bude HW nebo semi-HW.
Ne problem je vazne nekde v SW. Posledne to bylo v chybne vlozene 802.1Q hlavicce. A ohledne CRC mate skoro pravdu. Nastesti jde sitovka donutit prijimat i pakety bez overeni CRC a protoze je to v linuxu, neni problem k tomu presvedcit i driver. Dost HW ma moznost to resit pomoci SW, ale v praxi se to moc nedela, protoze mame pro procesor uzitecnejsi traveni casu nez vypocet CRC, ktery muze delat a overovat HW.
-
Na to by stacil taky aplikacni printf(), ne?
Asi ano, stacil, jen tahle metoda je o par hodin kratsi. :-) Tentokrat to vyresim i bez toho, ale podobne zarizeni se hodi pro priste. Ono uz jen rozsoudit, jesli je problem u odesilatele, nebo prijemce se hodi.
-
Jen nápad, možná blbej - pokud umíš zachytávat jakýkoli pakety, řešit to pomocí "man in the middle" a obejít se bez "rozdvojky" nejde?
-
MitM samozrejme jde taky. Jenze tam jsou podobne problemy jako s port mirroringem. Neni jistota jesli jsem neco nezmenil.
V kazdem pripade dekuji za nabidky. Nabidek na HUBu mam, ze si muzu vybrat! Komunita kolem root.cz prijemne prekvapila. Problem je (skoro) vyresen.
-
Tohle SW neudělá - protože CRC spočítá přímo MAC. Podobné problémy ladím běžně, HUB Vám ani moc nepomůže, protože většina běžných séťovek paket s vadným CRC nepustí. Problém bude HW nebo semi-HW.
Ne problem je vazne nekde v SW. Posledne to bylo v chybne vlozene 802.1Q hlavicce. A ohledne CRC mate skoro pravdu. Nastesti jde sitovka donutit prijimat i pakety bez overeni CRC a protoze je to v linuxu, neni problem k tomu presvedcit i driver. Dost HW ma moznost to resit pomoci SW, ale v praxi se to moc nedela, protoze mame pro procesor uzitecnejsi traveni casu nez vypocet CRC, ktery muze delat a overovat HW.
Tohle mě potenciálně zajímá. Zatím jsem narazil na položku rx-fcs a rx-all ve výpisu ethtool -k , a dále na #defines E1000_RCTL_SECRC (patrně odpovídá rx-fcs) a E1000_RCTL_SBP (store bad packets - natvrdo vypnuto - k čemu to je?) v kódu ovladače Intel igb (pro i210/i350 a další). A na i210 vidím ethtoolem rx-fcs off [fixed], ale rx-all je patrně možné povolit... tady je k tomu nějaký komentář (https://stackoverflow.com/questions/22101650/how-can-i-receive-the-wrong-ethernet-frames-and-disable-the-crc-fcs-calcul), jinak to dokumentované moc není. Zdá se, že rx-fcs on znamená "FCS neořezávej, ale předej vyšším softwarovým vrstvám" a rx-all on znamená "nezahazuj rámce s vadným checksumem, předávej softwaru všechno". Pokud si dneska koupíte na odposlech gigovou intelku, velmi pravděpodobně se bude jednat o i210 nebo i350 (obě obsluhovány driverem igb.ko). Pokud se týče stovkových optických síťovek, viděl jsem je s čipy Broadcom nebo Realtek, nevylučuji ani další výrobce. Mám tady namátkou jednoho stovkového optického realteka (8139too) a ethtool hlásí rx-fcs i rx-all sice oboje off, ale nikoli fixed - a skutečně jdou povolit.
-
Tak s timhle ti moc nepomuzu. Prakticky to vyzkousene nemam. Jen jsem v zivote nekolikrat psal ethernet drivery (celkem 5x, z toho 2x pro linux)
Takze mam nejakou predstavu co se z HW da dostat nahoru, ale zatim jsem to nepotreboval.
-
Odposlech 100BASE-TX linky jsme před lety také řešili a skončilo to zařízení vyrobeným na zakázku, neboť jsme na běžném trhu nic nenašli.
-
Tohle SW neudělá - protože CRC spočítá přímo MAC. Podobné problémy ladím běžně, HUB Vám ani moc nepomůže, protože většina běžných séťovek paket s vadným CRC nepustí. Problém bude HW nebo semi-HW.
Ne problem je vazne nekde v SW. Posledne to bylo v chybne vlozene 802.1Q hlavicce. A ohledne CRC mate skoro pravdu. Nastesti jde sitovka donutit prijimat i pakety bez overeni CRC a protoze je to v linuxu, neni problem k tomu presvedcit i driver. Dost HW ma moznost to resit pomoci SW, ale v praxi se to moc nedela, protoze mame pro procesor uzitecnejsi traveni casu nez vypocet CRC, ktery muze delat a overovat HW.
Ono jako HW to většinou má, nicméně nevím, nakolik je s tím počítáno dál. Já takovou možnost mám (eventuelně poskouchat přímo RGMII, protože gigabit už se přímo poslouchá špatně). Nicméně nevím, zda tyhle data se dají nějak rozumě přecedit výš - nevylím, že by s tím stack v os počítal, protože jde o velkou exotiku, funkční jsem to neviděl. Na druhou stranu rozbitá 802.1Q už by se měla dát napříjmat i normálně, běžnou síťovkou, protože frame jako takový rozbitý nebude (ten by jste na této úrovni vůbec neměl rozbít). Navíc - jak vám to vyřeší HUB (a pokud blbe skládáte pakety, tak je i jedno, že to bude na 10M) když stejně musíte řešit příjem na té síťovce - můžete to připojit přímo...
-
Nepomohlo by tohle?
US $8.00 | Throwing Star LAN Tap 1.5 Network Packet Capture Mod Haker Tool 100% Original Replica Monitoring Ethernet Communication analysic
https://a.aliexpress.com/_m0dY635
Tahle věc je IMO čistě pasivní odbočka. Nemohu vyloučit, že to nakonec taky bude fungovat, ale nepřekvapilo by mě, pokud s tím budou problémy - protože je to impedančně nepřizpůsobené, bude tam přinejmenším útlum, možná i nějaké zkreslení "odrazem". Praktická funkčnost může dost záviset na délce použitých patchcordů apod.
-
Nejsem si jist, zda nejsem pomerne hodne mimo a nebude tam nejaky problem o kterem nevim (FLP, atd.), ale neslo by proti sobe hodit celkem 4 PHY tohoto typu https://www.microchip.com/wwwproducts/en/LAN8700 ? V CN se delaji desticky kde je RJ45+mag+phy+osc+pinheader. Jeden par by slouzil jako 2-port "HUB", dalsi dva pary by byly pasivne na odposlech jednoho a druheho smeru.
-
Nejsem si jist, zda nejsem pomerne hodne mimo a nebude tam nejaky problem o kterem nevim (FLP, atd.), ale neslo by proti sobe hodit celkem 4 PHY tohoto typu https://www.microchip.com/wwwproducts/en/LAN8700 ? V CN se delaji desticky kde je RJ45+mag+phy+osc+pinheader. Jeden par by slouzil jako 2-port "HUB", dalsi dva pary by byly pasivne na odposlech jednoho a druheho smeru.
Našel jsem povícero zmínek (https://www.google.com/search?q=MII+PHY+back+to+back+repeater), že dva kusy MII (https://en.wikipedia.org/wiki/Media-independent_interface) PHY lze zapojit "zády k sobě" prokřížením RX/TX směrů MII sběrnice a vytvořit tak repeater. Nestudoval jsem to do hloubky - čistě selským rozumem bych řekl, že bohužel navrch nejspíš bude potřeba nějaké MCUčko, které "postranním kanálem" zvaným MDIO při startu pokonfiguruje jednotlivé PHY čipy, aby provedly "link up". Množina payloadových signálů MII je plně duplexní a neumožňuje sběrnicové zapojení, pouze point-to-point. Výjimkou je postranní sběrnička MDIO, určená pro management (přístup do konfiguračních registrů PHY) - tato je multidropová, jedním masterem lze mluvit k více slavům, slavové mají každý svou "adresu".
Zdá se, že payloadové signály MII jsou na úrovních TTL a nevšiml jsem si nějakých požadavků na terminaci apod. Takže nevidím velký problém, pokud by se navíc každý směr ještě rozbočil do dvou "cílových PHY" (= odbočit si duplexní odposlech). Tzn. píšete to myslím správně.
-
Ano, pokud PHY nenabehne automaticky, MDIO je potreba. Problem vidim spis v tech FLP nebo necem dalsim co mi je skryto.
Kazdopadne mne napadla jeste jedna bastlirska cesta, nektere uplne lowcost switch obvody tusim od Realteku maji moznost port-mirroringu. Tyto switche obvykle funguji tak ze tam je ten switchovaci IC a k tomu nejaka I2C/SPI konfiguracni EEPROM, kterou by mozna stacilo preprogramovat. Ty obvody umi fungovat i jako slave, kdy nejaky MCU pres stejnou sbernici cte jejich registry, kde je opet spousta zajimavych veci a samozrejme to vsechno co se konfiguruje z te EEPROMky. Takhle funguji lowcost manageovatelne switche (typicky se seriovym portem, switch + 8051ka :) )
-
Ano, pokud PHY nenabehne automaticky, MDIO je potreba. Problem vidim spis v tech FLP nebo necem dalsim co mi je skryto.
Kazdopadne mne napadla jeste jedna bastlirska cesta, nektere uplne lowcost switch obvody tusim od Realteku maji moznost port-mirroringu. Tyto switche obvykle funguji tak ze tam je ten switchovaci IC a k tomu nejaka I2C/SPI konfiguracni EEPROM, kterou by mozna stacilo preprogramovat. Ty obvody umi fungovat i jako slave, kdy nejaky MCU pres stejnou sbernici cte jejich registry, kde je opet spousta zajimavych veci a samozrejme to vsechno co se konfiguruje z te EEPROMky. Takhle funguji lowcost manageovatelne switche (typicky se seriovym portem, switch + 8051ka :) )
Zkuste prozkoumat tohle, jsou tam i obrazky s HW upravami
https://github.com/libc0607/Realtek_switch_hacking
-
Zdá se, že payloadové signály MII jsou na úrovních TTL a nevšiml jsem si nějakých požadavků na terminaci apod. Takže nevidím velký problém, pokud by se navíc každý směr ještě rozbočil do dvou "cílových PHY" (= odbočit si duplexní odposlech). Tzn. píšete to myslím správně.
Bohuzel u MII je clock opacnym smerem, takze to lehce rozdvojit nepujde (nemate garanci ze to bude fazove stejny, i kdyz pojedou PHY ze stejneho centralniho oscilatoru), takze minimalne to bude chtit jeste CPLD mezi ty 4 phy/rj45, aby se odbocilo spravne co je potreba.
Nastesti to jde zapojit 1:1 jako repeater (pokud se to zkonfiguruje pres ono mdio), a ty TTL MII signaly uprostred si muze tazatel napichnout na logicky analyzator, uplne by na to stacilo to co pouzivam ja (FX3 devkit, 16b@100MHz).
-
No vida - díky @RDa máme kompletní obrázek :-)
To by mě zajímalo, jestli by se totéž dalo provést na některé gigabitové variantě MII, resp. nakolik by to bylo složité. Třeba SGMII jede po symetrických párech a je třeba dodržet impedanční přizpůsobení = hůř se to odbočuje. Kdo je vlastně zodpovědný za auto-negotiation? PHY, pokud se nemýlím? Takže autoneg se netýká MII (resp. dá se přes MDIO vypnout/zapnout a zjistit výsledek).
No když se tu zábava tak hezky rozjela, dám schválně do placu ten svůj primitvní analogový bastl-odposlech na stovku. Spíš pro pobavení. Viz přílohy. Jak už jsem psal, chybí tomu signálové trafo do odposlechových výstupů, a navíc koukám (vzpomínám si) že mi tam kus cesty jednoho páru nevycházel, tak jsem to nastavil kabelem (SATA twinaxem) ;-) Taky nějaké napájecí větévky šly drátem vzduchem... prostě bastl na dvouvrstvé desce. Ale svou roli to splnilo, jako technology demonstrator to funguje. Omlouvám se za nevzhledné schéma, nebylo to určeno k publikaci. Dodal bych i zdrojáky (Eagle) ale vážně je to zralé na kompletní předělávku.
-
No vida - díky @RDa máme kompletní obrázek :-)
To by mě zajímalo, jestli by se totéž dalo provést na některé gigabitové variantě MII, resp. nakolik by to bylo složité. Třeba SGMII jede po symetrických párech a je třeba dodržet impedanční přizpůsobení = hůř se to odbočuje.
GMII/RGMII jsou 125MHz jako SDR (x8) nebo DDR (x4,250MT/s) rozhrani, takze to jde udelat rychlejsim paralelnim analyzatorem.
SGMII (1.25Gb/s) - tohle je uz podobny problemu k tapnuti PCIe linky - v podstate existuji 2 moznosti - dat 1:2 fanout buffer do cesty (pokud ta vec toleruje zpozdeni), nebo pouzit high-speed diferencialni buffer s velkou vstupni impedanci, treba i jeste pres dalsi rezistory, aby na diff paru nebyl znatelnej stub - viz napr. Agilent E2947A.
Elektronika, pokud ji nedate zbytecne prisna omezeni (hlavne to byva cena, pocet vrstev, specialni desky - chlazeni - filtry), vlastne nema hranice :)
-
Zkuste prozkoumat tohle, jsou tam i obrazky s HW upravami
https://github.com/libc0607/Realtek_switch_hacking
Cinstinou nevladnu, nicmene jak koukam na ty dumpy firmware mgmt switchu mne napadlo, netusite nekdo u realteku jak to je uvnitr s temi lowcost switch IC ? Tipnul bych si, ze tam bude integrovany nejaky microcontroller, ze to nemaji cele pomoci automatu.
-
Zkuste prozkoumat tohle, jsou tam i obrazky s HW upravami
https://github.com/libc0607/Realtek_switch_hacking
Cinstinou nevladnu, nicmene jak koukam na ty dumpy firmware mgmt switchu mne napadlo, netusite nekdo u realteku jak to je uvnitr s temi lowcost switch IC ? Tipnul bych si, ze tam bude integrovany nejaky microcontroller, ze to nemaji cele pomoci automatu.
Co si matně vybavuju, a teď jsem se namátkou mrknul (viz odkazy níže), tak ty low-endové matice žádné MCU jádro neobsahují. Umí běhat buď autonomně (hloupý switch), nebo spřažené s externím CPU/MCU (managed).
Odhadem i v režimu "hloupý switch" to chce aspoň maličkou sériovou konfigurační EEPROM.
Management by teoreticky snad šel zařídit i bez vlastního L2/L3 rozhraní (pouze přes MDIO nebo I2C) ale reálně to tak nebývá, reálně management CPU mívá interní propoj do switchovací matice pomocí MII - kde switch se tváří jako MII PHY, zároveň ale přes MDIO budou patrně vidět všechna jednotlivá PHY per port pokud se nepletu. Potažmo tento interní propoj může být VLAN-tagovaný tzn. sloužit jako trunk pro routování mezi VLANami apod. V jednom datasheetu jsem zahlédl, že switchovací matice umí pomocí custom tagu předat CPU informaci, skrz který vnější L2 port paket přišel...
Jinak MII rozhraní na switchovací matici (čipu) bývá možno použít také "v roli MAC" a připojit na něj externí PHY (transceiver) = implementovat další externí port, třeba optický uplink apod.
http://realtek.info/pdf/rtl8306sd%28m%29_datasheet_1.1.pdf
http://realtek.info/pdf/RTL8318P_1-1.pdf
https://www.marvell.com/content/dam/marvell/en/public-collateral/switching/marvell-switching-link-street-88e618x-product-brief-2005-04.pdf
-
Nekde jsem cetl, ze v nekterych hloupych switch IC od Realteku uvnitr nejaky procesor je. Nejsem si jist zda to byla zpravicka ze Realtek koupil nejakou technologii nebo to byl patent. A je to celkem davno.
A samozrejme to cele muze byt i uplne jinak. Ale predstavte si, ze mate switch s nejakym primitivnim procesorem, ktery muze hrabnout do bufferu ... ;-)
-
Tak jeste jednou dekuji vsem za podporu (i tu "moralni").
Nicmene neverte tomu, ze switch s mirror funkci opravdu mirroruje vsechna data (uplne vsechna). Dokonce ani ten hloupy ne. Aby paket prosel, musi byt na L2 validni (ve vsech ohledech, nejen ty co cloveka napadlou na prvni pohled, tj delka nebo crc, ale take 802.1q hlavicka napriklad).
Problem je nakonec vyresen. Nakonec se ukazalo, ze problem byl ciste v SW, kde kombinaci 2 paketu vznikl prasopes. Takze v tomto pripade honba za prizrakem.
Jinak perlicka ke switchum, kterou vetsina lidi nezna. Switch je uvnitr celkem tupe zarizeni. Prijme paket, koukne do smerovaci tabulky a posle kam patri. Jenze se se zkomplikuje kdyz prijdou na rady VLANy. Predstavte si, ze mam 16 port managovatelny switch, ktery je VLAN rozdeleny na 1/2 jako 8+8 portu. Nechceme zadne komplikace s tagovanim paketu (802.1q) ani jine. Proste 1 fyzicky swich rozeleny na 2 uplne oddelene site. A mezi ty dve site vlozim router. Bude to fungovat? No prekvapive nebude. Protoze ty 2 VLAN jsou sice oddelene, ale switch ma jedinou smerovaci tabulku. A pri preposlani routerem se MAC adresa odesilatele nemusi menit. Takze switch vidi jednu MAC na 2 portech, a nevite kam paket nasmeruje. Muzete zkusit. Na tomto prikladu nepohori uplne vsechny switche, ale jen naprosta vetsina. S vyjimkou tech co do smerovaci tabulky pridavaji k MAC i informaci o VLAN (rarita ale existuji).
-
Tinak perlicka ke switchum, kterou vetsina lidi nezna. Switch je uvnitr celkem tupe zarizeni. Prijme paket, koukne do smerovaci tabulky a posle kam patri. Jenze se se zkomplikuje kdyz prijdou na rady VLANy. Predstavte si, ze mam 16 port managovatelny switch, ktery je VLAN rozdeleny na 1/2 jako 8+8 portu. Nechceme zadne komplikace s tagovanim paketu (802.1q) ani jine. Proste 1 fyzicky swich rozeleny na 2 uplne oddelene site. A mezi ty dve site vlozim router. Bude to fungovat? No prekvapive nebude. Protoze ty 2 VLAN jsou sice oddelene, ale switch ma jedinou smerovaci tabulku. A pri preposlani routerem se MAC adresa odesilatele nemusi menit. Takze switch vidi jednu MAC na 2 portech, a nevite kam paket nasmeruje. Muzete zkusit. Na tomto prikladu nepohori uplne vsechny switche, ale jen naprosta vetsina. S vyjimkou tech co do smerovaci tabulky pridavaji k MAC i informaci o VLAN (rarita ale existuji).
Pravděpododobně jsem něco nepochopil, na takový problém jsem nikdy nenarazil - dělám se zařízeními Cisco.
Switch je přece L2 zařízení, pracuje s rámci, ne s pakety, a klíčová je u něj tabulka MAC adres (přiřazuje MAC adresu k portu a ten je zase v nějaké VLAN); switch směrovací tabulku vůbec nemusí mít.
Pokud ve switchi vytvoříte více VLAN a chcete je "propojit", je třeba to udělat na L3, např. z každé VLAN vytáhnout jeden port a připojit jej do routeru, ten tudíž musí mít tolik portů, kolik máte VLAN, plus další do vnějšího světa. Není to elegantní řešení, ale funguje úplně normálně; lepší je router-on-a-stick, kdy se ze switche vytáhne trunk (v něm se rámce samozřejmě tagují), stačí tedy jen jeden port pro všechny VLAN.
Nebo jste myslil přístup k samotnému switchi? Cisco to řeší tak, že ke každé VLAN vytvoří fiktivní rozhraní, na kterém se nastaví IP adresa podle potřeby. Funguje to.
-
Per-VLAN FDB jako opatření proti duplicitním MAC adresám ve více VLANách je finta možná nepříliš známá, dokud se nedostanete do situace, kdy je přesně tohle Váš problém :-) Nedávno jsme o tom tady na rootu akademicky podebatovali (https://forum.root.cz/index.php?topic=22382.15)... a popravdě nevím, jak se ke shodným MAC adresám na dvou různých IP/Eth rozhraních bude chovat ARP v nějakém Linuxu - nechci a priori tvrdit, že zrovna pro ARP a jeho tabulku to představuje problém, dost možná nikoli. BTW doporučuji terminologicky rozlišovat switch na druhé vrstvě a jeho CAM=FDB tabulku vs. router na třetí vrstvě a jeho ARP tabulku pro překlad IP adres na adresy druhé vrstvy. Heh dovedu si představit, že v "L3 switchi" (router on a stick trčící z VLANového switche) bude problém nikoli v ARPu, ale spíše ve druhé vrstvě, pokud CAM=FDB tabulka není per VLAN, takže shodné MAC adresy ve dvou různých VLANách ve FDB kolidují, čímž si navzájem podrážejí nohy... což lze pod dojmem chování IP a vyšších vrstev na první pohled dezinterpretovat jako zádrhel v ARPu :-)
-
Pravděpododobně jsem něco nepochopil, na takový problém jsem nikdy nenarazil - dělám se zařízeními Cisco.
Switch je přece L2 zařízení, pracuje s rámci, ne s pakety, a klíčová je u něj tabulka MAC adres (přiřazuje MAC adresu k portu a ten je zase v nějaké VLAN); ....
Jenze ten problem je prave na L2 a Cisco switchu se tyka taky. Zkuste si to precist znovu. Problem je prave ve tom, ze priradi MAC adresu k portu. Jenze ne 2 ruznych portech mu chodi pakety se stejnou zdrojovou MAC. Jednou primo, podruhe pres L3 router.
Mimochodem stejny problem se da udelat i bez L3 routeru. Staci 2 switche. Prvni dostane tagovane pakety 2 siti, rozdeli do 2 kabelu a ty se zapoji bez tagovani do jednoho switche a 2 ruznych VLAN. To je stejny problem jen tezsi na predstavivost. Takto zapojene switch vypadaji nesmyslne, ale je dost zarizeni, ktere se tvari ze maji uvnitr 2 rozhrani pro 2 site, ale uvnitr nepriznany switch, o kterem clovek bezne nevi.
-
Jenze ten problem je prave na L2 a Cisco switchu se tyka taky. Zkuste si to precist znovu. Problem je prave ve tom, ze priradi MAC adresu k portu. Jenze ne 2 ruznych portech mu chodi pakety se stejnou zdrojovou MAC. Jednou primo, podruhe pres L3 router.
Pořád se v tom ztrácím :-(. Pokud jde paket přes router, jsme na L3, a tento paket (správněji rámec) vysílá příslušné síťové rozhraní routeru, L2 adresa odesilatele v daném rámci bude tudíž adresou onoho rozhraní. Ve Vašem předešlém příspěvku jste ale napsal "A pri preposlani routerem se MAC adresa odesilatele nemusi menit." - proč by tak tomu mělo být? Ledaže by se ve směrovačí zapnulo něco jako proxy ARP, použila nedomyšlená konfigurace apod.
Ještě technická poznámka, switch nevidí tutéž MAC adresu současně na více rozhraních, ale vždy jen na jednom, na tom, odkud se mu ozvala naposledy; viz všelijaké útoky proti switchům (bez ochrany).
Mimochodem stejny problem se da udelat i bez L3 routeru. Staci 2 switche. Prvni dostane tagovane pakety 2 siti, rozdeli do 2 kabelu a ty se zapoji bez tagovani do jednoho switche a 2 ruznych VLAN. To je stejny problem jen tezsi na predstavivost.
Zapojení si představit dokážu snadno, ale problém pořád nevidím ;-). Zkusím si to odexperimentovat.
-
Ještě technická poznámka, switch nevidí tutéž MAC adresu současně na více rozhraních, ale vždy jen na jednom, na tom, odkud se mu ozvala naposledy; viz všelijaké útoky proti switchům (bez ochrany).
A teď si představte, že tam třeba jedou dvě TCP spojení, dva stroje downloadují. Sice žijí ve dvou různých VLAN, ale provoz prochází jediným switchem. Střídají se: jeden klient pošle serveru ACK, druhý pošle serveru ACK, server prvnímu pošle kus payloadu a bác: MAC adresa ve switchi (L2 FDB) zůstala naučená směrem k druhému klientovi, ale ten je ve druhé VLAN, takže v první VLAN dojde k zahození paketu... dokud se první klient znovu neozve "haló, já jsem pořád tady"... a má chvilku šanci dostat nějakou tu retransmisi, pokud se mezitím neozve druhý klient...
No a tohle si dělají navzájem.
Chová se to trochu podobně, jako kolidující IP adresy, akorát při dropnutí paketu na L2 není šance, že by se aspoň vracely odesilateli ICMP unreachables (když dorazí paket na neotevřený port) apod.
Správně - duplicitní MAC adresa je podstatou potenciálního DOS útoku.
-
Správně - duplicitní MAC adresa je podstatou potenciálního DOS útoku.
Pokud vam jde o bezpecnost / SLA, tak snad mate na koncovych portech sve infrastruktury nastaveny seznam povolencyh MAC, ne? Tudiz jedna se tam dostane, druha uz nikoliv.
-
Pořád se v tom ztrácím :-(. Pokud jde paket přes router, jsme na L3, a tento paket (správněji rámec) vysílá příslušné síťové rozhraní routeru, L2 adresa odesilatele v daném rámci bude tudíž adresou onoho rozhraní.
Prave ze ne. Kdyz ramec projde L3 routerem, tak IP adresa zdroje je stale ta puvodni (NAT nepocitam, to je jasne), ale MAC adresa zdroje nutne nemusi byt nahrazena tou adresou rozhrani L3 routeru. Prijemce MAC adresu nekoho v jine siti nezajima.
A aby to nebylo tak prehledny, tak nektere switche dokazi zmenit MAC adresu paketu i na L2
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/41263-catmac-41263.html#topic1
-
Správně - duplicitní MAC adresa je podstatou potenciálního DOS útoku.
Pokud vam jde o bezpecnost / SLA, tak snad mate na koncovych portech sve infrastruktury nastaveny seznam povolencyh MAC, ne? Tudiz jedna se tam dostane, druha uz nikoliv.
To ano. Pokud ovšem nemáte nějaký legitimní provoz, který používá pár "well known" unicastových MAC adres, které jsou potažmo shodné v každé další L2 síti. Jsem schopen ve svém archivu dohledat zmínky o historickém průmyslovém protokolu "ABB Masterbus 300", ale pokud vím tak nebyl sám.