Registrován: 25.11.2002
Příspěvků: 59

To, co popisujes, je prave proxy ARP, tj. (1). Prinutit iptables, aby Ti smerovaly ARP pakety pres netlink do userspace programu neni uplne easy, protoze pravidla v iptables jsou zalozena na IP hlavickach a ARP pakety tedy kalsifikovat neumi. Jedine, co by asi pres iptables slo, by bylo do toho userspace programu dostat vsechny pakety mimo IP paketu... Asi by bylo jednodussi upravit kod proxy ARP v jadre, jak jsem to popsal v (1).

(4) Jeste mne napadnul jeden HACK: pridat dalsi hodnotu do ap_bridge_packets:

0 - vsechny pakety se posilaji primo do jadra (to uz existuje)
1 - pakety s cilovou MAC shodnou s wifikartou se posilaji do jadra, pakety s jinou MAC se preposilaji zpatky do vzduchu, broadcast pakety se duplikuji do jadra a do eteru (to uz existuje)
2 - unicast pakety se posilaji pouze do jadra bez ohledu na MAC adresu, broadcast pakety se duplikuji do jadra i do vzduchu

Vsechno je to dano typem media, kterym je vzduch pri pouziti AP. Je to "zvlastni" medium, protoze vlastne umi boradcasty pouze od AP ke klientum, obracene ne, ostatni vlastnosti ma jako ethernet (tj. je sdilene, vysilat muze pouze jedna stanice). Toto medium s jednim AP a N klienty se chova podobne jako linux router s N interfacema, na nichz je spusten spolecny bridge. Mozna, ze by se podpora dala napsat do casti jadra resici bridge.

Jinak je to vlastne cele vyborny napad. Osobne si myslim, ze QoS neni zrovna ten nejlepsi duvod pro implementaci takove veci, protoze komunikace mezi klinety nema zadnou definovanou kapacitu (celkova propustnost klesa s poctem aktivnich stanic), takze se to QoS neda nastavit rozumne. Ale jina, velmi pekna aplikace teto techniky, je napr. firewalling konkretnich klientu. Pokud by se to resilo obecne (tj. jadro by nejak umelo ovladat i ty broadcasty, ne dalsi hodnotou ap_bridge_packets), tak bys mohl na AP vyrobit klientovi firewall, ktery by jej odstinil podle prani od zbytku site...

Registrován: 12.09.2002
Příspěvků: 71

Registrován: 25.11.2002
Příspěvků: 59

Registrován: 12.09.2002
Příspěvků: 71

Registrován: 12.09.2002
Příspěvků: 71

Registrován: 25.11.2002
Příspěvků: 59

Registrován: 12.09.2002
Příspěvků: 71

Registrován: 12.09.2002
Příspěvků: 71

Registrován: 25.02.2003
Příspěvků: 24

Par problemu ktery nastaly pri implementaci:
tcpdump -l -t -e -n -i wlan0 -p arp 2
mi vypisuje : tcpdump: parse error

egrep, ktery pouzivam (2.4.2) nezna ani jeden z parametru uvedenych ve skritpu

Jak casto mam skript volat a nebylo by lepsi vypinani bridge ve wlan dat nekam jinam ... nevidim duvod proc to porad vypinat snad se to nikde nezapina

budu potrebovat ebtables? na arp odpovida ten skript a zbytek doufam obslouzi jadro. nebo se pletu?

Registrován: 25.02.2003
Příspěvků: 24

Ted mne napadlo, ze vlastne tcpdump nikdy neskonci takze ten skriptik bezi porad ... takze by se mel asi jenom pustit na pozadi ... sakra ja sem ale trubka.

pak sem zkousel se kouknou do manualovejch stranek k tcpdumpu a naprosto nechapu k cemu je tam ta dvojka na konci za tim arp by snad mohlo bejt jenom: net nebo host a k tomu nejaka informace, ale takhle samostatne?

Registrován: 12.09.2002
Příspěvků: 71

Registrován: 11.06.2002
Příspěvků: 1267

__________________

Registrován: 27.03.2003
Příspěvků: 7

Je to sice dost narocne na spravu, ale pak se nemusi na HostAPu nic prekopavat. Klientum napevno nastavit ARP tabulkku vsech stroju v bunce, vcetne APcka. Doufam, ze to jde i ve widlich. Pak nebude treba resit znovuposlani ARP broadcastu do vzduchu, nebot zadne nebudou.

__________________

Registrován: 27.06.2002
Příspěvků: 73

Zdravicko,
chtel bych se zeptat, jestli to nekomu timto zpusobem chodi.
Ja sem to vyzkousel na dvou reouterech (Debian 3.1 a Fedora Core 1) a ani na jednom to nefunguje.
Ani nevim, kde hledat chybu - chova se to tak, ze pokud pustim ten fake_arp_responder, nejde pingat mezi klientama asociavanejma na AP.

__________________