Fórum Root.cz
Hlavní témata => Bazar => Téma založeno: rndint 23. 07. 2023, 12:40:36
-
Ahoj,
prodam nevyuzity/zcela funkcni prevodnik (sitova karta):
Parametry:
- USB-C (USB3)
- SFP sachta
- Gigabit (FTTD)
- Hlinikove chassis
- Chipset Realtek RTL8213B
- Spotreba 5W
Prodavam bez SFP, pouze prevodnik a USB-C kabel. Cena 400,- + doprava (zasilkovna)
kontakt: rndint (zavinac) proton.me
Vic info:
https://www.aliexpress.com/item/1005005046474059.html (https://www.aliexpress.com/item/1005005046474059.html)
-
Mám zájem, pošlu SZ/email...
Tady ve fóru do záznamu technický přípodotek: RTL8213 vypadá jako media-konvertor čip (10/100/1000 Base-T na 100/1000 Base-X), tzn. otázkou mi zůstává, čím je tvořeno USB rozhraní. Tipnu si RTL8153 ?
-
Prodano
-
Tyjo... funguje :-)
Dmesg:
[ 41.996405] usb 1-1: new high-speed USB device number 3 using xhci_hcd
[ 42.145483] usb 1-1: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=31.00
[ 42.145565] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 42.145633] usb 1-1: Product: USB 10/100/1000 LAN
[ 42.145679] usb 1-1: Manufacturer: Realtek
[ 42.145720] usb 1-1: SerialNumber: 000000000000
[ 42.270710] usbcore: registered new interface driver r8152
[ 42.290140] usbcore: registered new interface driver cdc_ether
[ 42.400885] usb 1-1: reset high-speed USB device number 3 using xhci_hcd
[ 42.553903] r8152 1-1:1.0 (unnamed net_device) (uninitialized): Invalid ether addr 00:00:00:00:00:00
[ 42.554030] r8152 1-1:1.0 (unnamed net_device) (uninitialized): Random ether addr 8a:30:70:d0:7c:9c
[ 42.621061] r8152 1-1:1.0: load rtl8153b-2 v1 10/23/19 successfully
[ 42.653489] r8152 1-1:1.0 eth2: v1.11.11
Užiju to i na gigabit ale pořizoval jsme to zejména kvůli stovce. Vrazil jsem do toho první stovkový transceiver, co mi přišel pod ruku, a prostě funguje :-) Data tečou. Na fotce v příloze je USB/SFP dongle linknutý proti rozebranému mediakonvertoru jiného výrobce.
Takhle vypadá pár zaklínadel v ethtoolu:
#ethtool -T eth2
Time stamping parameters for eth2:
Capabilities:
software-receive
software-system-clock
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none
#ethtool -m eth2
Cannot get module EEPROM information: Operation not supported
#ethtool eth2
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Port: MII
PHYAD: 32
Transceiver: internal
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00007fff (32767)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
Link detected: yes
Podle toho, jak lže ohledně navázané rychlosti a stavu linku, zdá se, že je skutečně uvnitř kromě RTL8153 USB NIC čipu ještě bridgující media-konvertor RTL8213. Přístup k SPD EEPROM transceiveru se nekoná - což mě nepřekvapuje z několika důvodů. Jednak, protože ta věc je multirate, bude tam MCUčko (buď uvnitř RTL8213 nebo samostatné), které si s transceiverem popovídá přes I2C a nastaví příslušně PHY. Druhak nejspíš metalický RTL8153 nemá standardní I2C port, kde by kernelový driver očekával přístup k SFP transceiveru.
Takže tak. Pro mě osobně je tento kousek hardwaru poměrně užitečný hlavně na výjezdech. Duplexní optický odposlech pomocí pasivního tapu (splitteru) a noťasu se stal realitou. Teda až seženu druhý kus :-)
-
Ono to chyti link z toho pasivniho tapu? (me se optika nespojila kdyz tam dam jenom vlakno jednym smerem.. ale treba je to v nejakem navazujicim stavu, kde se to nebere moc vazne?)
-
Ono to chyti link z toho pasivniho tapu? (me se optika nespojila kdyz tam dam jenom vlakno jednym smerem.. ale treba je to v nejakem navazujicim stavu, kde se to nebere moc vazne?)
No... pro potřeby simplexního odposlechu normální nativní síťovce stačí říct "pojedeš touhle rychlostí natvrdo" a ona se chytí, přinejmenším na gigové optice nebo stovkové metalice. Trochu jste mě ale pane nahlodal, jestli to bude chodit i tady skrz ten USB dongle, kde je PHY spravováno vlastně autonomně jakýmsi velmi hloupým bridgem. Takže jsem se kousnul, vytáhl jsem tap(splitter), jeden další box co umí stovku (switch) a tu topologii jsem otestoval.
Nakonec jsem odklidil ze záběru nejhorší pracovní bordel a pořídil foto. Všimněte si, že do duplexního SFP transceiveru v USB donglu vede jediné vlákno, link svítí (tato LEDka na donglu nekecá) a na rozmazaném displeji v pozadí roluje tcpdump.
Podobný test mě zakrátko čeká ještě s PCI-e síťovkou AT-2914SP (podobná "architektura"), ale to už je v tomto vlákně OT...
Obecně mám u síťovek s přirostlým bridgem trochu nepříjemný pocit, že pro potřeby odposlechu mi bridge může požírat některé režijní frejmy (LACP, LLDP a přátele) tzn. to budu muset ještě otestovat. Na gigu není problém provést srovnávací test těchto hybridů s nativní 1000Base-X síťovkou i210. Taky mi bridge bude mrvit časování a tím i pořadí paketů v duplexním záznamu - zamačkl jsem slzu, hlavně že uvidím aspoň něco.