Poslední příspěvky

31

Sítě / Re:Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od RDa kdy 15. 11. 2024, 18:50:37 »

Ta dvoji by sla takto:

Kód: [Vybrat]

# vconfig add lan 15
Added VLAN with VID == 15 to IF -:lan:-
# vconfig add lan 90
Added VLAN with VID == 90 to IF -:lan:-
# ifconfig lan mtu 9000
# ifconfig lan.15 mtu 1500
# ifconfig lan.90 mtu 9000
# ifconfig lan.15 up
# ifconfig lan.90 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
lan.15: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lan.90: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000


32

Sítě / Re:souběžný posílání souboru na všechny ethernetové porty multicastem

« Poslední příspěvek od František Ryšánek kdy 15. 11. 2024, 18:49:15 »

Mně to taky připadá jako téma na hezké programování v C(++) a BSD sockets API.
Kladu si otázku: co řešíte za specifický problém?

Potřebujete distribuovat nějaké soubory, a těch dat je příliš mnoho, než aby to 1Gb linka na straně serveru zvládla přenést všem klientům, ale pokud se to bude multicastovat, tak se to vejde/stihne?
Klienti potřebují vždy všichni tentýž soubor ve stejném čase? Je v tom případě potřeba, aby si o něj sami říkali? Nemůže mít server informaci, který soubor budou klienti potřebovat, a prostě ho "odvysílá" o své vůli? Musí server čekat, až budou všichni klienti připraveni, a tedy čekat až všichni projeví zájem?

Našel jsem jednu aplikaci, kde něco velmi podobného funguje. Cílový business model je "digital signage" = zobrazování reklamy na obrazovkách v síti, kde u každé obrazovky je malý lokální počítač s vlastní úložnou kapacitou. A říkají k tomu, že se jedná o "push delivery" souborů na klientské stroje (přehrávače).

Pokud by měl server dělat retransmise, pokud byť jediný klient signalizuje, že data nedostal, může se snadno smazat úspora, která z multicastingu plyne. Pokud se počet retransmisí neomezí, může to dopadnout volně v intencích toho co lze vidět na CANbusu při nějaké poruše fyzické vrstvy: jeden uzel stále dokola vysílá tutéž zprávu, ale všechny ostatní datové toky se zastaví :-) Princip toho jevu je podstatně odlišný, ale to deja-vu je silné :-)

Když mluvíte o multicastingu, plánujete "přihlašování k odběru" pomocí IGMP ? (Pokude ne, bavíme se efektivně o broadcastingu...)

Vypadá to na zábavné téma k analýze, ale chtělo by to trochu víc vstupních informací, aby stálo za to nad tím dumat :-)

33

Sítě / Re:Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od RDa kdy 15. 11. 2024, 18:48:34 »

nastaveni MTU 9000 na eth0 projde?

Ano, projde to timto stylem i separatne:

Kód: [Vybrat]

# vconfig add lan 123
# ifconfig lan mtu 9000
# ifconfig lan.123 mtu 1500
# ifconfig lan.123 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
lan.123: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Ale na kyzeny opacny stav (vlan s vyssi MTU) ne:

Kód: [Vybrat]

# vconfig add lan 123
# ifconfig lan mtu 9000
# ifconfig lan.123 mtu 9000
# ifconfig lan mtu 1500
# ifconfig lan.123 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lan.123: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Ta VLAN ma omezeny MTU na hodnotu ktera je aplikovana na nativni rozhrani.

Mozna tedy je sance, ze by zarizeni v dvoji siti meli pouze tagovane vlany, tj. obe dve nad fyzickym rozhranim, ktere by se pak uz dale nepouzivalo - a pak by tohle vyzadovalo bud manazovany switch nebo router s nastavenim te 1500 vlany jako dalsiho lan segmentu + nutnost mezi tim routovat. Pochybuji ze by byl dobry napad spojovat do bridge sit, ktera je fyzicke rozhrani a jedna tagovana vlan z nej, na tom routru.

Pridavam dalsi pozadavky/predstavy:
 - v 1500 siti se musi dorozumet vsichni se vsema a maj pristup na internet, jede tam dhcp
 - v 9000 siti neni pristup ven na internet, jen mezi specifickyma zarizenimi (a muzou mit staticke ip)

34

Sítě / Re:Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od czipis kdy 15. 11. 2024, 18:33:51 »

nastaveni MTU 9000 na eth0 projde?

35

Sítě / Re:souběžný posílání souboru na všechny ethernetové porty multicastem

« Poslední příspěvek od RDa kdy 15. 11. 2024, 18:21:33 »

Tak si neco takoveho napis, ze to bude distribuovat obsah v plovoucim okne a dokud vsichni prijemci nepotvrdi dokad ten obsah maji, tak se okno nebude posouvat a bude to delat retransmise.

Alternativne muzes pouzit namisto multicastu daisy-chain, ze kazdy klient vyjma posledniho bude jakoby proxy. To by slo zhackovat snad velice rychle skrze nejaky http proxy s lokalni cache... na 1..N-1 nastavis proxy, a na N-tem udelas wget

Rychlostne by to melo mit stejne parametry jako multicast, jen to bude mit vyssi spotrebu (protoze kazdy port ve switchi naplno vyuzije oba smery, vyjma prvniho a posledniho).

36

Sítě / Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od RDa kdy 15. 11. 2024, 17:51:42 »

Snažím se (zatím v linuxu) nastavit sdílenou síťovku skrze VLAN do dvou sítí na různé MTU a nejde to.

Představa cílového stavu je:
eth0 s MTU 1500, subnet hlavni
eth0.10 s MTU 9000, subnet jiny

Při nastavení MTU pro rozhraní s VLAN (eth0.10) se vrací s jakoukoliv hodnotou:

Kód: [Vybrat]

SIOCSIFMTU: Numerical result out of range
Při nastavení MTU pro netagovanou síť (eth0) se tato hodnota projevuje o obou rozhraní (eth0, eth0.10)

Existuje nějaké řešení ?

Lze omezit na linuxu a macu MTU na vrstvě IP podsítě ?

Situace je: klasická domácí síť s hromadou různorodých zařízení má několik zařízení, mezi kterými chci provozovat ty jumbo frames (řekněme několik pracovních stanice a NAS), bez toho, abych musel tahat duplicitní kabeláž. Představa byla nasadit tagovanou VLAN, kde může tento jumbo provoz probíhat. A ejhle.. nejde to. WTF.

37

Sítě / Souběžné posílání souboru multicastem

« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy 15. 11. 2024, 17:41:26 »

Tuhle otázku si asi nějací lidí kladli,  tak bych se divil, kdyby neexistovalo řešení. Možná tak funguje bittorenent, nebo windows update cache v lokální síti.

Mám do switche (1Gbps x5) připojeno 1 zařízení, ze kterého chci z zařízení UNO rychlostí 1Gbps přemístit soubor do zbylých čtyřech zařízení, a každé bude příjmat souběžně čtyřykrát 1Gbps.    .. problém co :
(luxus jako 10Gbit switch  by sice šlo, ale je to řešení na sílu a to jsem neprozradil, že zdrojový seeder má taky 1Gbps)

Dá se tohle nějak zařídit.? Asi bude nevyhnutelný linkový/síťový multicast a speciální konfigurace stacku zdrojového zařízení a asi to bude diktovat volbu vhodného transportního démona+ protokolu (samba, rsync, ftp, torrent ,, webdav ,wtf) A aso

A ideálně, aby na cílových počítačích mohl být libovolný OS, ale pochopitelně s tím speciálním klientem.

přestavuju si to tak, že na cílových počítačích dám: něco jako  : superftp > connect 239.239.239.250 :21 ; get  file.zip
jakmile to dopišu na prvním druhém třetím , klienti začnou čekat. Až to napíšu na posledním čtvrtém, tak na serveru dám  příkaz start a ono to začne posílat

Jde to nějak? (nevidím problém v směru od serveru k klientům (hromadně), ale jak klienti budou handlovat (zvlášť) ack, pokud bych uvažoval TCP, je to vůbec možné, takovýhle TCP kočkopes) nebo se bude muset spolehnout na bezACKový protokol? čili jak řešit zpětnou komunikaci a obejde se to bez ní?

38

Sítě / Wi-Fi extender má svůj DNS záznam

« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy 15. 11. 2024, 17:28:56 »

 Vrtá mi hlavou jedna věc, jak je možné ,že  po zapojení wifi extenderu , pokud jsem připojen přímo na něj , existuje, tedy dá se ze zařízeních resolvovat dns záznam typu config.me.local ? v  obou režimech : WDS i AP


Co jsem zpozoroval: vrátí se správná odpoveď (výchozí IP v nenakonfigurovaném stavu i aktuální odpovídající DHCP přiřazení) a vrací se

..Jenže tcpdump -v -e -n -t - i (jak na originálním routeru tak na smartphonu)mi odhalil zajímavou věc:
na telefonu: nic podezřelého : odpoveď dorazí ze stejné MAC adresy:
na AP: dotaz nedorazí (pouze jenom v případě, že jde o -t AAAA dotaz)

Znamená to ,že extender dokáže odchytávat traffic a reagovat na DNS?




1: A dál by mě zajímalo, pokud chci připojit wlan extender k stávájící wifině, musí daná wifi karta AP podporovat linkové rámce se čtyřmi  MAC adresami (tedy kromě SRC(SA),DST(DA),BSSID tam je čvrtá transmiter(TA) nebo receiver (RA))  ? (jde o něco jiného než MAC hlavičku  drátového ethernetu 2b  + 48bit src + 48bit dst)
Odpoveď od    je se mi zdá divná píše mi to, že to nutné není, ale že se tím dosáhne lepšího lepšího výkonu.... ale že to je dopouručené

2: A zadruhé, čekal jsem, že to bude fungovat (jednoduše a hloupě), že SSID + heslo + kanál bude stejné, jenže ono si tam mohu navolit v prvním kroku, kterou síť chci rozšířit (v jakémkoli bandu) a v druhém si mohu zvolit SSID + heslo
, obojí vlastní a dokonce  pro 2.4GHz i pro 5GHz. To je nějaká novota?
Na tom zařízení je nějaký linux 3.1 MIPS, dá sekonfigurovat, přes http, ssh je nepřístupné.

39

Vývoj / Re:Bind socketu na konkrétní síťovou kartu v C

« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy 15. 11. 2024, 17:25:36 »

takže server má tři síťové adresy?
Mělo by to jít, když místo IP adresy  originu uvedete síťové rozhraní originu , pak se použije daná adresa.
Ale nevím , zda to půjde v kódu. By mě zajímalo, jak to dělá curl.
Nicméně, pokud by to nešlo přepsat,  a opravdu bys musel použít IP adresy jako specifikátor originu, tak abys docílil výběru rozhraní, bys musel použít ip virtuální routovací tabulky ( *** ), přičemže v každé bude default routa přes jiné síťové rozraní ... default via. .192.168.1.5x dev ethY   + routa pro  místní sít, pochopil jsem, že vše je v jednom subnetu)a policy routing  (ip rule add from 192.168.1.5x lookup tabulkarozhrani3)

ale mám pocit, že to je rovnák na něco ohnutého



*** víte o způsobu jak přes příkaz ip * přidat virt. rout. tabulku jinak než echo mojetable >> /etc/iproute2/rt_tables?

(sice píšete že server je svatá kráva, že se nemůže sahat na konfiguraci)

40

Sítě / Re:Připojení ke SmartTV přes síť (ne bezdrátový displej)

« Poslední příspěvek od Marek Staněk kdy 15. 11. 2024, 16:38:07 »

něco podobného se tu nedávno řešilo, koupil jsem si na to bezdrátový HDMI extender (no, nakonec už jich bylo asi 6 nejen pro sebe)
https://www.banggood.com/pl/EDUP-Wireless-HDMI-Compatible-Transmitter-and-Receiver-1080P-at-60Hz-Extender-Long-Range-Video-Audio-Projection-Plug-and-Play-for-Desktop-PC-Computer-Projector-Monitor-p-2007453.html?akmClientCountry=CZ&cur_warehouse=CN&rmmds=accountnewuser

existují dokonce i verze, kde se vysílače dají kupovat samostatně, a po napárování k přijímači se to celé chová jako přepínač, tzn přijímač z těch napárovaných bere obraz a zvuk od toho, kdo zmáčknul puntík jako poslední.
proti třeba chromacastu nebo miracastu to má podstatně menší zpoždění a dá se na tom i hrát; rozdíl pak je, že tohle jde mimo síť a dosah je asi 60m v přímé viditelnosti, zatímco u chrome-/miracastu je prodleva cca 250+ms, ale dosáhne to tak daleko, kam dosahuje síťový segment.