Ze zadání jsem nepochopil, k čemu to celé má být. Kdybys to tam napsal, možná bychom přišli na to, že to jde udělat jednodušeji, než generovat vlastní custom packety.
V Mikrotiku neznám způsob, jak generovat vlastní packety.
Pokud to tam není dostupné ve formě nějakého jejich modulu (o kterém nevím, ale já nejsem Mikrotik expert a ani po tom netoužím), tak na to zapomeň a přejdi na technologii, která Ti takovéto věci dělat umožní. Což je Linux.
No celé je to o tom, že potřebujeme uskutečnit komunikaci mezi těmi zařízeními tak, aby bylo možno na základě těchto údajů řídit chování ostatních zařízení čili aby na podnět jednoho zařízení reagovala další zařízení např. spuštěním skriptu atd. Je to vlastně jako když v OSPF dochází k výměně registračních tabulek tak to samé pro nás jen místo registračních tabulek budou jiné informace, které zapříčiní registraci daného klienta na jiné zařízení s lepším signálem atd.
Co se týká linuxu tak OpenWRT se dá použít v metarouteru, tudíž by se toho dalo využít jen nevím jak moc se ty systémy mezi sebou ovlivňují respektive jak se ovlivňují.
donutí ho v access listu podle mac adresy tim že ho jedno APčko vykopne a druhý ne. Museji mít stejný SSID teda. No ale zajímao by mě jak poznáš že má na druhym lepší signál když je připojený pouze na první a proč vlastně chceš přepnout klienta na lepší signál... to tam měl bejt rovnou od začátku ne? Mě se zdá že řešíš kraviny.
To je z důvodu toho handoveru. Když máš např. noťas a přejdeš z místnosti do druhé nebo nějaký delší úsek jinam např. ve firmě tak samozřejmě tě první přístroj může držet na živu, ale ta konektivita bude velmi chabá. A proto chceme aby se to připojení přeneslo na další zařízení i když na tom stávajícím je ještě živé.
I když to co říkáš není špatné ale v případě, že je konektivita na ostatní zařízení nulová a to zařízení by ho odpojilo, pak by se ztratil úplně, ale dobrá úvaha.
PS: neřeším kraviny ale oni je vymýšlejí ve škole :-). Nicméně chcou zkusit zda by to bylo realizovatelné.
Myslim, ze to, o co se snazis je realizovatelne, ale jednoduche to nebude. Ve WiFi se roaming bezne resi na strane klienta. Ten dela periodicke skeny AP, ktere mu ochotne odpovidaji (probe request/response) nebo posloucha beacony a podle toho si meri signal. Dobre je to videt treba u atheros/madiwifi a jeho background scanning. Pokud bych chtel resit roaming, asi bych zacal hackovat drivery od klienta.
AP bezne nic nevi o klientech, kteri na nej nejsou pripojeni. Zadne peridicke skeny nedela a ani nemuze, protoze klient nema zadny odpovidaci mechanismus. Theoreticky, kdyby se na AP resene softwarove s hostapd a tudiz v monitor modu privesil jeste dalsi program, daly by se s dnesnimi modernimi kartami+ovladaci cist urovne signalu kazdeho prijateho paketu <na danem kanale, coz te omezi na WDS mode; nebo druhou kartou v channel hopping>, ovsem nevedel bys, ktere patri tvym klientum na jinem AP a ktere cizim, protoze po procedure asociace se klienti idenfitifkuji uz jenom MAC adresou (prosim potvrdit).
A vy tedy chcete, aby si AP vymenovala informace o pripojenych klientech, aby vedela, komu merit signal? Rekl bych, ze to bude ten nejmensi problem :-)
A i kdyby jste udelali mereni signalu pouze na strane AP, porad nevim, jak donutis klienta se spatnou implementaci roamingu prepnout se na jine AP, kdyz se mu proste nechce. Co kdyz ho odstrelis od jednoho, ale on bude trvat na tom, ze maji signal stejny a bude se snazit pripojovat zpatky?
__________________
Be smart, use TROSCs!
T.R.O.S.C. ... The Really Old yet Sufficient Computer
Děkuji moc za odpověď. A nebylo by možno ho přeregistrovat na jiné AP se stejným SSID? Aniž by to ten klient vlastně poznal? Já právě nevím jak to řešit na RouterOS, protože tam údajně nemožes nic, ale variantou je OpenWRT a dostat ho třeba na metarouter, aby pořád RouterOS byl jako hlavní systém a tam již by šlo implementovat Cčko a řešit to programováním. Potíž je jak na to a navíc s těma linuxovýma distribucema jsem nedělal takže by to dalo hodně práce.
Když se podíváš na to zadání, tak pro ně by bylo nejlepší řešit to přes ICMPv6 změnou těla zprávy. Což je samozřejmě na linuxu normálně naprogramovatelné, když víš jak má vypadat paket a na jakém portu běhá. Ale v ROS to asi nepůjde co?
Jak by to podle tebe bylo realizovatelné na ROS? Pokud ne viděl by si to na OpenWRT? Blbé je, že mě táhne teď čas. V semestrálce jsem dělal skript, který zaznamenával veškerá přenesená data za jednotku času pro každého klienta zvlášť. Tzn. vytvořil jsem soubor, který měl název "MAC adresu" daného klienta a každou vteřinu jsem počítal počet přenesených a odeslaných dat a ukládal je pro každého klienta zvlášť. A tyto informace chcou distribuovat, ale ne jako celé soubory, ale např. jednou za minutu odeslat průměr těch přenesených dat čili jenom 2 čísla.
Tohle co navrhujes je uplna blbost.
Handover klientu si na 802.11a/b/g/n resi klienti sami prave podle IAPP. Nejsem si na stoprocent jisty jestli pri zapnutem IAPP musi byt nastavene stejne kanaly. Na naproste vetsine AP stacilo nastavit stejny kanal a SSID a klientske stanice si vzdy vybirali AP s nejlepsim signalem.
Problem nastava pouze pokud se pri vetsim datovem toku nachazi klient/i nekde mezi AP, kde se pak diky CSMA rapidne snizuje propustnost.
To cos nacrtl v zadani na 100procent resil Alvarion Breezenet, takze bys mohl zacit prostudovanim manualu k AP10 a SA10. Na Mikrotiku by se tohle nechalo resit zpusobem, ze centralni autorita vydava seznam AP, ktery si klienti pravidelne aktualizuji a v pravidelnych intervalech si budou modifikovat access list (v pripade mikrotiku). Potom se muzou dat AP na jine kanaly a pouzivat i ruzna SSID. V podstate stejne jako je bunkova struktura v sitich mobilnich telefonu.
2 AP se stejnym SSID by nemela existovat. Ovsem, kdyby existovala, tak by se klient mohl asociovat k jednomu a pakety by od nej prijimala vsechna (kdyby jim clovek nejak rozbil zabezpeceni). Clovek by pak musel v softwaru osetrit, odkud by se pakety posilaly do site. Mel bys pak soft handover jako v CDMA2000. Muselo by to asi bezet vsechno na jednom kanale a zrejme nikdo nedokaze domyslet vsechny dusledky, pokud to nezkusi.
Co se Mikrotika tyce, s programovanim v nem nemam moc zkusenosti. Pokud kolega Dulik rika, ze nejde odeslat vlastni paket, veril bych mu.
Osobne bych asi vzal PC a ze vsech Mikrotiku ze site bych vycital statistiky pres SNMP nebo terminal a ridil to centralne. Pokud to ma byt distribuovane, tak asi metarouter, ale na to se ptej nekoho jineho, ja ho zivy nikdy nevidel.
__________________
Be smart, use TROSCs!
T.R.O.S.C. ... The Really Old yet Sufficient Computer
22.02.2011 v 11:28
