Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Sítě / Re:jaktože wlan extender má svůj dns záznam
« Poslední příspěvek od František Ryšánek kdy Dnes v 19:13:10 »
Ohledně DNS záhady:
1) výrobci těchto krabiček (extenderů) mají vcelku svobodu, co si kdo naprasí do firmwaru
2) možná se zkuste mrknout, co dělá Bonjour / ZeroConf / uPnP a hlavně mDNS. Něco z toho se Vás může týkat.
Hint: APčka tohle často umí.
Na straně klienta: v operačním systému je knihovna, která zkouší přeložit jména pomocí mDNS. Tahle knihovna či plugin se zavěsí do "systémového všeobecného jmenného resolveru" vedle standardního DNS, lokálních překladů z /etc/hosts apod. Ten client-side zastřešující resolver se v Linuxu tuším jmenuje libnss.

Ohledně wifi extenderu v tříadresním režimu díky za zajímavé téma. Dost hlavolam. Něco jako Mikrotik station pseudo-bridge s překladem MAC adres, akorát v režimu vzduch-vzduch. Nebo by extender musel sledovat, který klient je schopen odpovědět sám za sebe, a pokud od něj nevidí ack, tak forwardnout/zopakovat původní "dotaz" od AP, a pokud jemu už klient odpoví, tak forwardnout zpátky APčku se src rádiovou MAC adresou klienta... nebo tak nějak, divočina.

Čtyřadresní backhaul je oproti tomu relativně jasnej (jako po kabelu) - ale to zas musí podporovat taky hlavní APčko, na které se ten extender pověsí, ten čtyřadresní spoj by musel asi jet jiným ESSIDem, než který slouží tříadresním čistým klientům... není to jenom otázka "zapnu extender a jedu, a je jedno, jestli o mně AP ví že jsem extender".

Klíčová slova: WDS a 802.11s
2
Nová témata / Re:Jumbo frames v kombinaci s VLAN
« Poslední příspěvek od RDa kdy Dnes v 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
3
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 :-)
4
Nová témata / Re:Jumbo frames v kombinaci s VLAN
« Poslední příspěvek od RDa kdy Dnes v 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)
5
Nová témata / Re:Jumbo frames v kombinaci s VLAN
« Poslední příspěvek od czipis kdy Dnes v 18:33:51 »
nastaveni MTU 9000 na eth0 projde?
6
Sítě / Re:souběžný posílání souboru na všechny ethernetové porty multicastem
« Poslední příspěvek od RDa kdy Dnes v 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 :D

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).
7
Nová témata / Jumbo frames v kombinaci s VLAN
« Poslední příspěvek od RDa kdy Dnes v 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.
8
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.   ;D .. 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í?
9
Sítě / jaktože wlan extender má svůj dns záznam
« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy Dnes v 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   8) 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é.
10
Vývoj / Re:Bind socketu na konkrétní síťovou kartu v C
« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy Dnes v 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)
Stran: [1] 2 3 ... 10