BRIDGE u karty

[Dan Lukes]

Cizek Milan napsal/wrote, On 01/09/06 19:12:
>> 2. Nebo karte reknes, ze mezi stanicema prehazovat nema, a pak je dava 
>> systemu, at si s nima poradi on.

> jasne ja myslim ze tomu nejak rozumim. Ale co se stava s pakety, které by se
> normalne bridgovali na urovni hw karty, pokud je tento bridge vypnuty.
> Myslim, ze se asi postoupi do kernelu, který pak nevi (?) co s nima a posle
> je na default GW?

	Ja nyslim,ze "normalni" kernel nikoliv. Zaprve neni duvod, aby byl 
paket preposlan na "default route" - jeho cilova adresa bude patrne 
nalezet siti, ktera je nahozena na one bezdratove karte a toto smerovani 
bude mit pred "default route" jiste prednost.

	Jenze, paket nebude patrne odeslan ani zpet do teto karty. Paket  ma 
cilovou IP adresu v te siti, ze ktere prisel a tak jadro predpoklada, ze 
cilova stanice paket obdrzela take - tedy - pokdu cilova MAC neni jeho 
karty. Pokud je, pak predpoklada chybu v nastaveni routingu, paket 
preposle a zdroji posle ICMP redirect.

	Takove je "normalni" chovani routingu. Nevim, jestli v souvislosti s 
timto rezimem lze toto chovani nejak modifikovat a jak, nebo zda se 
proste a obycejne pocita, ze prislusny program, ktery bude bridging 
zajistovat si ziskani paketu musi zajistit jinak (bpf, ipfilter hook 
nebo tak neco).

> myslenku opakovane kernelu sdelit, ze pakety ze site 10.0.1.0 ma vratit zpet
> na tu kartu. Tak jsem to myslel, i když je to zrejme blbost.

	Ne, takhle jednoduse to skoro spis nepujde.

>> 1. Pokud v tomto rezimu AP posila na vsechny ARP pozadavky samo sebe, 
>> pak stanice posilaji packety na vedlejsi stanice s MAC AP a AP v tvem 
>> pripade posle ICMP redirect, protoze to v ramci jedne site se routing 
>> nedela (to je chyba v nastaveni site).

	Proxy ARP je teoreticka moznost jak to delat. Jenze "normalni" proxy 
ARP funguje pouze pro situace kdy se prichozi ARP dotaz tyka IP adresy, 
ktera je na JINEM interface, nez ze ktereho dotaz prichazi (kdyby ta IP 
byla na stejnem, byl by problem, ze zarizeni by nejspis odpovedelo samo 
a druha, ruzna, odpoved PROXY by vytvarela nedeterministicky stav site).

	Je samozrejme mozne, ze "proxy arp" funkce je zabudovana primo v 
ovladaci one WiFi - ale "standardni kod jadra" se takto, ma dojem, nechova.

>> 2. Nebo prijde packet pro vedlejsi stanici s MAC te stanice a pak se 
>> to ani nezpracuje, pokud system nebezi v promiskuitnim modu (a to 
>> bezne neni).

	No, v zasade by ovladac mohl od karty takovy paket ziskat a jadru 
predat i kdyz z hlediska systemu by promiskuitni mod nebyl pozadovan 
(choval by se jako by karta stale byla v promiskuitnim modu - tak se AP 
WiFi chova "normalne" porad), ale system ho skutecne pomerne zahy zahodi.

> Popravde tady se prilis nechytam v pojmech (neumim si predstavit jak to tam
> lita). Nicmene jsem si myslel, ze pokud vypnu bridge na karte, tak by to
> mohl zachranit bridge na urovni systemu (jak pises).

	Nejsem si jist. Ani bridge neposila dosle pakety do vsech interfacu, 
ktere se bridgeovani ucastni - prepisila ho do vsech KROME TOHO, ze 
ktereho paket prisel.

	Priznam se, ze nemam zadne zkusenosti s provozovani "kernel-level AP". 
Zda se mi ale, ze jsou pouze dve moznosti, jak by to mohlo fungovat.

1. Kernelovy routing nebo bridge musi byt nejakym postupem (nastavenim) 
modifikovan aby byl schopen pozadovanou ulohu plnit.

2. Pozadovanou funkcionalitu zajistuje nejaky user-level program, ktery 
se jen vhodnym zpusobem napoji na jadro (bpf nebo hook jadra).

	Zdalo se mi, ze text manualove stranky naznacuje, ze resenim je druhy 
postup. Detaily ale musi poradit nekdo, kdo to tak provozuje.

					Dan



-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz