Optimized Link State Routing Protocol (OLSR) Jaroslav Henner, Martin Grames Abstrakt: Optimized Link State Routing protokol je protokol optimalizovaný pro použití v mobilních Ad-hoc sítích. Tento článek zevrubně popisuje protokol samotný, jeho vlastnosti, jeho implementace a reakci na výpadek uzlu v síti. Také je zde zmíněna problematika testování Ad-hoc wifi sítí a podpora karet v Linuxu. Klíčová slova: OLSR, OLSRd, OOLSR, NS-OLSR, routování, směrování, síť, linkstate, proactive, proaktivní, MANET, Ad-hoc. 1 Úvod.............................................................................................................................2 1.1 Optimized Link State Routing protokol,.................................................................2 1.1.1 Pakety OLSR...................................................................................................2 1.1.2 Hello zprávy....................................................................................................3 1.1.3 TC zprávy........................................................................................................3 1.1.4 MPR uzly.........................................................................................................3 1.1.5 HNA zprávy.....................................................................................................3 1.1.6 MID zprávy.....................................................................................................3 1.1.7 Rozdíly OLSR a OSPF....................................................................................4 2 Modelová situace............................................................................................................4 2 Způsob konfigurace......................................................................................................4 2.1 olsr.org OLSR daemon............................................................................................5 2.1.1 ETX.................................................................................................................6 2.1 OOLSR a NOAOLSR.............................................................................................6 2.2 NRL OLSR.............................................................................................................6 2.1 QOLSR...................................................................................................................6 3 Konfigurace....................................................................................................................7 3.1 Olsr.org olsrd...........................................................................................................7 4 Výsledky.......................................................................................................................10 4.1 olsr.org OLSR daemon..........................................................................................10 5 Závěr.............................................................................................................................14 6 Seznam použité literatury.............................................................................................15 7 Příloha...........................................................................................................................15 7.1 Makefile................................................................................................................15
květen 2009
1/18
1 Úvod. Mobile Ad-hoc Networks, dále MANET, jsou sítě, jejichž uzly tvoří mobilní zařízení, propojené takzvaně Ad-hoc, tedy bez předchozího hlubšího plánování. Tento druh sítě může najít své uplatnění v oblastech, kde není vybudována komunikační infrastruktura, nebo kde je tato infrastruktura zničená. Aby bylo možné sítích MANET komunikovat i přes několik, distribuovaně zvolených, prostředníků, každý uzel by měl být schopen pracovat jako směrovač pro ostatní uzly v síti – být pro ně opakovačem. Routy – směrovací informace, jsou udržovány pomocí směrovacího protokolu, jehož návrh je složitý problém, beremeli v potaz možnost, že se topologie sítě může velmi rychle měnit. Routy mohou být udržovány buď reaktivně, což znamená, že jsou sestaveny „na požádání“, tedy až když jsou potřeba. Druhým přístupem je přístup proaktivní, kdy se protokol snaží dynamicky udržovat informace o úplné topologii sítě. Třetím pří- Ilustrace 1: stupem jsou hybridní protokoly, které spojují přednost předchozích přístupů. Topologie MANETu. Sítě MANET tak mohou, díky distribuovanosti opakovačů poskytovat vyšší Aby každý uzel mohl odolnost oproti infrastrukturním sítím, protože na rozdíl od infrastrukturních sítí, kde jsou kritickými body zařízení Access point, které jsou staticky zvoleny při ná- komunikovat s vrhu sítě, v sítích MANET je kritickým bodem každý opakovač, který ale po vý- kterýmkoliv jiným uzlem v MANETu, je padku může rychle nahradit kterákoliv jiná vhodná stanice. Budeme-li chtít postavit takovou síť nad zařízeními WiFi – IEEE 802.11[abg], potřeba, aby některé budeme se muset vypořádat s problémem, že tyto standardy nijak nezajišťují komu- uzly fungovaly jako nikaci pomocí prostředníků. Zprávy tedy nemohou být doručeny stanicím, které opakovače. nejsou v dosahu radiového signálu vysílače. Použitím směrování na síťové vrstvě je možné dosáhnout toho, že některé uzly, které jsou ještě v dosahu vysílače mohou zprávu pro příliš vzdálený uzel zopakovat, čímž se tato zpráva postupně dostane až na místo určení. Za zmínku určitě stojí to, že v oblasti WiFi je vyvíjen standard IEEE 802.11s pro takovéto druhy komunikace. Již dnes mají některá zařízení tento standard implementován.
1.1 Optimized Link State Routing protokol, OLSR je jeden z link-state protokolů pro směrování paketů pro sítě MANET. Každý uzel provozující OLSR má informaci o kompletní a aktuální topologii sítě. Routovací tabulky jsou plněny routami zjištěnými Dijkstrovým algoritmem a to ještě před vznikem požadavku odeslat paket takovou routou, což z OLSR dělá tzv. proaktivní protokol. Na routovací protokoly v sítích MANET jsou kladeny jiné nároky, než na protokoly v metalických sítích. Je to například proto, že v sítích MANET, mluvíme-li o WiFi, na rozdíl od metalických sítí není zajištěna detekce výpadku fyzické linky a dvě stanice na stejné síti linkové vrstvy se v průběhu času můžou navzájem odmlčet vlivem počasí, pohybem v terénu, nebo změnou prostředí. Kvalita linky nemusí být symetrická, to znamená, že trasa mezi dvěma uzly sítě může být jedním směrem kvalitnější, než ve druhém směru. Tyto vlivy působí nepříznivě na protokoly, jako je OSPF. Podrobněji se srovnáním OLSR a OSPF budeme zabývat v sekci 1.1.7.
1.1.1 Pakety OLSR Všechny zprávy OLSR protokolu jsou zabaleny do OLSR paketu (anglicky „packet“, souvislá část zprávy, která putuje sítí). V jednom OLSR paketu může být obsaženo více zpráv různého typu. Pro každou zprávu jsou v paketu mimo jiné zapsány informace: Message type. Typ zprávy – tedy jde-li o zprávu Hello, TC, MID, HNA, nebo jinou zprávu. VTime. Určuje jak dlouho po přijetí zprávy má příjemce informaci v ní obsaženou považovat za platnou. Originator address. IP adresa původce zprávy. Je nutno upozornit, že tato adresa nesmí být měněna při přeposílání zprávy. Time to live. Maximální počet hopů, přes které zpráva může být přeposlána. Tedy, pokud uzel obdrží zprávu s TTL1 , nesmí ji přeposlat. Hop count. Počet přeposlání zprávy. Poprvé vyslaná zpráva má mít hop count 1. S každým přeposláním se inkrementuje.
květen 2009
2/18
Sequence number. Číslo vygenerované zprávy. Každá nová zpráva má sequence number o 1 vyšší, než předchozí zpráva. Toto číslo je používáno pro zajištění toho, aby konkrétní zpráva nebyla přeposlána konkrétním opakovačem více, než jedenkrát.
1.1.2 Hello zprávy. Každý uzel provozující OLSR o sobě svým sousedům dává vědět pomocí zasílání HELLO zpráv zabalených do UDP paketu, který je vyslán jako broadcast nebo jako multicast. Hello zprávy slouží k detekci sousedů, zjištění stavu či kvality spojení a volbě MPR uzlů (viz kapitola 1.1.4). Hello pakety nesmí být přeposílány, taže by se od svého zdroje neměly dostat dále, než k přímým sousedům (1-hop sousedům). Každá Hello zpráva obsahuje • HTime. Informace o tom, jak často uzel vysílá Hello zprávy, což může být využito pro zjišťování „fuzzy“ kvality linky (viz. 2.1.1). • Willingness. Jak hodně je odesílající uzel ochoten stát se MPR uzlem. Například uzly s nízkým stavem baterie, nebo například vysokým zatížením CPU mohou tímto parametrem ovlivnit volící proces tak, aby šetřily své zdroje. • Dále Hello pakety obsahují informace o linkách mezi odesilatelem a jeho sousedy, adresách sousedů a jejich stavu.
1.1.3 TC zprávy. Každý uzel provozující OLSR se o topologii sítě dozvídá pomocí Topology Control zpráv. TC zprávy jsou vytvářeny pouze uzly MPR a jsou záplavově šířeny do sítě také pouze přes MPR. Obsahují IP adresu autora TC zprávy a adresy uzlů. Ostatní uzly je nesmění přeposílat, aby se síť nezahltila. Pokud se použije Fisheye algoritmus, maximální topologická vzdálenost šíření TC zpráv od zdroje je ovlivňována pomocí jejich Time To Live parametru. Uzly, které jsou blízko místa změny v síti se o této změně mohou dozvědět dříve, než vzdálené uzly, což může mít pozitivní dopady na stabilitu a sítě. TC zprávy jsou obdobou LS zpráv protokolu OSPF.
1.1.4 MPR uzly. Každý uzel provozující OLSR si zvolí několik svých sousedů, kteří budou přeposílat zaplavovací zprávy vyslané tímto voličem. Uzlům, které zvolili jiný uzel jako svůj MPR se říká MPR selektoři (MPRS). MPR uzly vysílají zprávy Topology Controll (TC) o stavu dostupnosti svých voličů. TC zprávy jsou tedy šířeny sítí pouze uzly zvolenými jako MPR. Tím se graf topologie zjednodušuje – z grafu se odstraní ty spoje, které díky předání zodpovědnosti na zvolený uzel nejsou potřeba.
1.1.5 HNA zprávy. Uzly mohou mít k sobě připojeny sítě, kde OLSR není používáno, nebo kam se nemají pakety OLSR šířit. Tyto sítě jsou oznamovány pomocí Host and Network Association zpráv. Pomocí HNA zpráv je tedy možno šířit informace o výchozích bránách (default route).
Ilustrace 2: MANET, kde černé uzly jsou MPR pro prostřední uzel, který má parametr MprCoverage=1 na levém obrázku a MprCoverage=2 na pravém. [1]
1.1.6 MID zprávy. Některé uzly mohou být do MANETu připojeny více, než jedním síťovým rozhraním. To se může hodit například v případě, kdy je potřeba propojit několik segmentů OLSR sítě pomocí Ilustrace 3: Síť připojená k Internetu pomocí uzlu segmentu metalické sítě. Některé uzly mohou GW. [2] fungovat jako bridge, mezi metalickým a bezdrákvěten 2009
3/18
tovým segmentem MANETu. To, že jeden uzel je v síti dosažitelný skrze dvě síťová rozhraní je třeba ostatním OLSR uzlům nějak sdělit, aby s tím mohly počítat.
1.1.7 Rozdíly OLSR a OSPF. Stejně jako OSPF je i OLSR směrovací protokol typu Link State. Na multiaccess sítích se k omezení velkého režijního provozu na síti používá u OSPF pověřený směrovač - designated router. K tomuto účelu slouží v OLSR uzly multipoint relays (MPR), které vysílají TC zprávy o svých sousedech. Zprávy o stavu linek jsou tedy generovány pouze uzly zvolenými jako MPR, čímž je výrazně zredukován předávaný počet zpráv informujících o topologii sítě, poněvadž bylo-li by použito OSPF a vypadl-li by jeden uzel z broadcast domény, byla by zpráva o tomto stavu rozeslána mezi všechny ostatní uzly. S tímto problémem souvisí nastavení parametru TcRedundancy, který je popsaný dále v konfiguraci. I v OLSR jsou periodicky posílány Hello pakety ke zjištění stavu linky, ovšem zde je nastaven o mnoho kratší interval – na LAN síti se nepředpokládají časté výpadky linek. Na metalickém vedení u OSPF proto stačí posílat Hello každých 10 s a spojení může být prohlášeno za nefunkční až po uplynutí 40 s od přijetí posledního Hello. U OLSR je posíláno Hello co dvě vteřiny a již 6 s od naposledy přijatého Hello paketu je spoj vyřazen. Dalším rozdílem jsou přidané HNA a MID zprávy popsané výše. Díky HNA zprávám můžeme například připojit svou OLSR síť k OSPF, kdy uzel připojený jiným rozhraním do OSPF bude periodicky generovat HNA zprávy s IP prefixy OSPF sítě. OSPF zase může importovat routy z naší sítě přes LSA zprávy typu 5 a 7.
2 Modelová situace Našim cílem bylo nalézt implementace OLSR protokolu a ověřit jejich funkčnost. K dispozici jsme měli hardware: Typ uzlu
Počet uzlů Síťové rozhraní
Ovladač a verze
Desktop
8
Atheros AR5212/5213
ath_pci 0.9.4
Laptop Dell
4
Intel 4965AG
iwl4965 1.2.0
Laptop ASUS 1
Intel PRO/Wireless 2200BG ipw2200 1.2.2kmprq
Tabulka 1: Použitý hardware a ovladače Bohužel, při každém pokusu o použití rozhraní Atheros přepnutého do módu Ad-hoc v Linuxu systém zkolaboval – „kernel panic“. Nebylo tak možno připojit tyto uzly do MANETu. Ověřovali jsme funkčnost sítě homogenní – na všech uzlech sítě běží stejná implementace OLSR protokolu. Sledovali jsme, jestli se uzly dozví o svých sousedech a jak se síť chová při výpadku uzlu. Poté jsme na jednom z uzlů spustili jinou implementaci OLSR protokolu a zjišťovali, jak se takto vytvořená heterogenní síť chová.
2 Způsob konfigurace. Nejprve jsme všechny uzly konfigurovali manuálně. Někdy se nepodařilo některé laptopy přimět k tomu, aby se připojili do stejné Ad-hoc sítě. Po přepnutí karty do Ad-hoc režimu, nastavení ESSID a kanálu se karta nepřidala do stejné buňky – hodnota Cell ve výpisu iwconfigu byla jiná, než na ostatních laptopech. Nepomáhalo ani ruční zadání adresy Cell. Někdy pomohlo „odpojit“ modul síťové karty od jádra pomocí rmmod a znovu ho přidat a znovu nakonfigurovat síť.
květen 2009
4/18
Jméno projektu
URL projektu
Testovaná verze
OLSR.org olsrd
http://OLSR.org/
olsrd 0.5.4
oolsr
http://hipercom.inria.fr/OOLSR/
oolsr-0.99.15.tar.gz
noaolsr
http://hipercom.inria.fr/noa-olsr/
noaolsr-0.91-oolsr-0.99.15.tar.gz
nrlolsr
http://cs.itd.nrl.navy.mil/work/olsr/ nrlolsrdv7.8.1.tgz
qolyester
http://qolsr.lri.fr/
qolyester-20090302.tar.bz2
Tabulka 2: Testované implementace OLSR Pro snadnější konfiguraci většího počtu uzlů byl vytvořen Makefile, který mnoho kroků konfigurace automatizuje. Tento pomocný nástroj má sebe-aktualizační schopnost – v hlavičce skriptu lze nastavit adresa, ze které se má přes SCP protokol stahovat novější verze skriptu, což aktualizaci skriptu na cílových uzlech automatizuje. To je velmi výhodné v případě, kdy potřebujeme způsob konfigurace uzlů upravit. Skript umožňuje přepnout rozhraní do Ad-hoc režimu (v případě rozhraní Atheros je potřeba z jádra odpojit modul ovladače a připojit znovu, s jinými parametry), nastavit ESSID, na síťovém rozhraní nastavit ip adresu a stáhnout zkompilovat implementace protokolů. Zautomatizování konfigurace přináší mimo rychlosti i tu výhodu, že konfigurace je jednoduše zopakovatelná, bez možnosti vzniku chyby způsobené lidským faktorem. Při používání Makefile se zatím nikdy nestalo, že by se nepodařilo karty připojit do stejné buňky, což se při ručním psaní příkazů stalo dvakrát, příčinu jsme nezjistili. Pro bližší popis způsobu konfigurace prosím nahlédněte do Makefile v příloze.
2.1 olsr.org OLSR daemon. 1. Po nakonfigurování karet jsme nakonfigurovali IP stack. Použili jsme rozsah IPv4 adres 10.x.x.x. Je nutno dát pozor, aby byla dobře nastavena ip adresa broadcastů, jinak bude olsrd špatně fungovat – bude vidět ostatních stanice a bude znát jejich topologii, ale ostatní stanice nebudou vidět ji, protože démon nebude odesílat Hello zprávy. Ifconfig nastavuje broadcast implicitně, ale pokud konfigurujeme pomocí nástrojů Iproute2 (program ip), je nutno explicitně broadcast nakonfigurovat. Spolu s ip adresou je to možné provést pomocí příkazu ip a a 10.0.0.1/8 b + dev wlan0. 2. Aby stanice přeposílaly pakety podle routovací tabulky, je třeba zapnout ip forwarding takto: echo 1 > /proc/sys/net/ipv4/ip_forward
nebo trvale nastavit v /etc/sysctl.conf: net.ipv4.ip_forward = 1
3. Konfiguraci démonu olsrd (/etc/olsrd/olsrd.conf) jsme použili takovou, jaká je v Linuxové distribuci Gentoo. Použili jsme stejnou konfiguraci na všech strojích. 4. Na jednom stroji ASUS jsme použili plugin olsrd_dot_draw, kterým jsme zobrazovali aktuální topologii sítě. Do konfiguračního souboru jsme museli přidat LoadPlugin "olsrd_dot_draw.so.0.3" { PlParam "port" "2004" PlParam "accept" "10.0.0.1" }
Tím jsme zajistili, že tento plugin bude naslouchat na portu 2004 a bude akceptovat spojení jdoucí z adresy 10.0.0.1. Tento plugin produkuje zdrojový text diagramu topologie, který je možno vykreslit pomocí nástroje olsr-topology-view.pl, který pro vykreslování grafu používá Graphviz. Tyto nástroje lze sehnat na následujících adresách:
květen 2009
5/18
olsr-toplogy-view.pl http://www.vias.org/wirelessnetw/wndw_05_06_07.html Graphviz
http://www.graphviz.org/
Tabulka 3: Nástroje pro vykreslení topologie.
2.1.1 ETX. Olsr.org olsrd umožňuje počítání Dijkstrova algorimu s metrikou linek ETX. ETX znamená Expected Transmission Count, což je průměrný počet vysílání, která je nutné provézt, než bude zpráva bezchybně přijata svým adresátem. Je to jedna z vhodných metrik pro hodnocení kvality linky. Lze ji určit pomocí vzorce
ETX =
1 , kde d f znamená pravděpodobnost, že zpráva bude doručena adresátovi, d r znamená pravd f ⋅d r
děpodobnost, že odesilateli zprávy bude doručeno potvrzení přijetí zprávy. Jsme-li uzlem v síti a máme-li odhadnout pravděpodobnost d r , můžeme využít sekvenčních čísel v Hello zprávách, které nám pravidelně přicházejí od sousedního uzlu. Pro odhad d f je ale třeba znát d r našeho souseda. To se můžeme dozvědět tak, že nám ho soused jednoduše pošle. Olsr.org olsrd k tomu používá upravené Hello zprávy, což však způsobuje nekompatibilitu s protokolem popsaným v RFC[3][4][5].
2.1 OOLSR a NOAOLSR jsou velmi podobné projekty. Jelikož poslední verze zdrojových kódů obou dvou projektů – oolsr-0.99.15 a noaolsr-0.91 obsahují chyby, kvůli které je není možné bez problému zkompilovat, nezabývali jsme se jimi nijak více. Je však pravděpodobné, že při použití staršího g++, než g++-4.1.2 by byly zdrojové kódy kompilovatelné. Tato chyba nevznikla použitým kernelem Linuxu, protože chyba je v syntaxi programu. To lze vyvozovat z první hlášky o chybě, kterou g++ při kompilaci vypíše: ../include/tuple.h:233: error: declaration of ‘~BasicTupleSet
>’ as member of ‘BasicTupleSet’
2.2 NRL OLSR. Zdrojový kód NRL OLSR šel zkompilovat, ale před kompilací je nutno nainstalovat libpcap-dev. Démon NRL OLSR obsahuje chyby pravděpodobně někde v kódu vyhodnocování parametrů příkazové řádky, které se projevují pády v důsledku chyby segmentace (segfault). Tato implementace implicitně používá multicast adresu 224.0.0.57 pro rozesílání OLSR zpráv. Bohužel, olsr.org olsrd z nějakého důvodu ignoruje zprávy z této adresy – nenalezne žádné sousedy a to i při nastavení volby „Ip4Broadcast 224.0.0.57“. Druhou možností je spuštěním démonu NRL OLSR s volbou z příkazového řádku „-b“, za níž následuje adresa, která bude použita pro vysílání zpráv Hello, TC, … Tím můžeme démon přinutit k tomu, aby neposílal zprávy na multicast adresu, ale posílal je na broadcast adresu sítě. Sousedé používající Olsr.org olsrd, stejně tak jako obdobně nastavení sousedé s NRL OLSR takto vysílající uzel vidí a všichni spolu dokáží komunikovat a tím pádem jsme vytvořili jednu implementačně-heterogenní síť. Kromě volby adresy, na kterou budou zprávy vysílány jsme používali implicitní konfiguraci, tedy v síti, kde 10.0.0.255 byla broadcast adresa jsme démon spouštěli pomocí „nrlolsrd -i eth1 -b 10.0.0.255“, bez žádných dalších voleb.
2.1 QOLSR. Tato implementace vyžaduje na rozhraní použití masky IPv4 adres s maskou /32, nebo IPv6 adres s maskou /128. Ostatní implementace OLSR ale pravděpodobně neočekávají možnost použití takové masky podsítě, z čehož vznikla následující situace. Na všech uzlech jsme použili IPv4 adresy s maskou /32. OLSR.org olsrd do routovací tabulky nepřidával potřebné routy pro 1-hop sousedy, takže těmto sousedům nebylo možno posílat zprávy. Uzlům vzdálenějším, než jeden hop však zprávy posílat šlo, protože pro ně OLSR.org olsrd routy přidal. Routovací tabulka uzlu s květen 2009
6/18
OLSR.org olsrd s adresou 10.0.0.1, který měl v bezprostředním dosahu uzly 10.0.0.2 a .3 a uzly s ip adresami 10.0.0.4 a .5 měl vzdálené více, než jeden hop vypadala asi takto. 10.0.0.4 via 10.0.0.2 dev eth1 10.0.0.5 via 10.0.0.2 dev eth1 127.0.0.0/8 dev lo scope link
To jsme vyřešili přidáním routy to routovací tabulky (dále jen r.t.) pomocí příkazu ip r a 10.0.0.0/24 dev eth1. Pro uzly OLSR sítě jsme používali adresy jen z tohoto rozsahu. Před diskuzí možných situací, které můžou nastat, zaveďme nový pojem: Adresát je vysílačem dosažitelný v síti právě tehdy, když je 1-hop sousedem vysílače, nebo když je dosažitelný některým 1-hop sousedem vysílače. Pokud uzel (v našem případě 10.0.0.1) chce komunikovat s některým uzlem, vytvoří zprávu a můžou nastat nastat následující situace. Uzel, který se chystá tuto zprávu vysílat je pro nás vysílač. • Vhodná /32 routa není přítomna v r.t. a adresát je v síti nedosažitelný. Pak je použita routa 10.0.0.0/24 na ARP dotaz vyslaný vysílačem neodpoví žádný stroj a je oznámeno „Destination Host Unreachable“ • Vhodná /32 routa není přítomna v r.t. a adresát je v síti nedosažitelný. Pak je použita routa 10.0.0.0/24. Tím jsme zajistili přeposlání pouze pro zprávy, kde je adresát 1-hop sousedem. To ovšem stačí, protože je-li adresát v síti dosažitelný, a není 1-hop sousedem vysílače, pak musí být být dosažitelný pomocí některého 1-hop souseda vysílače a pokud je síť v ustáleném stavu, je pro něj v routovací tabulce vhodná /32 routa, což je spor – není to situace o které mluvíme. Je to následující situace: • Vhodná /32 routa je přítomna a adresát je v síti dosažitelný. Pak je tato routa použita, zpráva je odeslána uzlu o jeden hop blíže k cíli, kde bude podrobena stejnému zkoumání, jakoby tento přijímající uzel byl jejím vysílačem. Tím je zajištěno přeposílání zpráv. • Vhodná /32 routa je přítomna v r.t. a adresát je v síti nedosažitelný. Pak jde o přechodový jev neustálené sítě, kdy uzel zmizel ze sítě a OLSR protokol ještě neodstranil routu z r.t. Použití QOLSR a Olsrd v jedné síti tedy je možné i pokud má platit, že zprávy mohou být doručeny kterémukoliv uzlu v síti.
3 Konfigurace. 3.1 Olsr.org olsrd. Při našich testech byla použita následující konfigurace, nacházející se v souboru /etc/olsrd.conf: DebugLevel
1
# IP version to use (4 or 6) IpVersion 4 # Clear the screen each time the internal state changes ClearScreen yes # HNA IPv4 routes # syntax: netaddr netmask Hna4 { # Internet gateway: 0.0.0.0 0.0.0.0 } # # # #
Should olsrd keep on running even if there are no interfaces available? This is a good idea for a PCMCIA/USB hotswap environment. "yes" OR "no"
květen 2009
7/18
AllowNoInt
yes
# The fixed willingness to use(0-7) #Willingness 4
Při výpočtu, zda má být uzel nastaven jako MPR se bere v úvahu hodnota Willingness. Za normálních okolností se počítá dle aktuálního stavu baterie či zda je notebook připojen k elektrické síti. V konfiguračním souboru ji však můžeme nastavit ručně, přičemž při hodnotě 0 nebude uzel nikdy nastaven jako MPR, při hodnotě 7 bude MPR vždy. # Allow processes like the GUI front-end # to connect to the daemon. IpcConnect { # Determines how many simultaneously # IPC connections that will be allowed # Setting this to 0 disables IPC MaxConnections 1 # By default only 127.0.0.1 is allowed # to connect. Here allowed hosts can # be added Host 127.0.0.1 } # Wether to use hysteresis or not # Hysteresis adds more robustness to the # link sensing but delays neighbor registration. # Used by default. 'yes' or 'no' UseHysteresis no
Hystereze poskytuje stabilní spojení odolné proti velké ztrátě nebo přechodné konektivitě mezi uzly za cenu většího zpoždění mezi vytvořením spoje. Tzn. pokud připojím nový uzel, tak ho ostatní v síti neuvidí hned, ale až za delší časový interval, kdy se spoj jeví jako stabilní. Pak se teprve dá vědět ostatním sousedům o novém uzlu sítě. # Link quality level # 0 = do not use link quality # 1 = use link quality for MPR selection # 2 = use link quality for MPR selection and routing # Defaults to 0 LinkQualityLevel 2
Kvalitu spoje je možné spočítat z periodicky posílaných HELLO zpráv(ve výchozím nastavení každé 2 vteřiny). Např. pokud pošleme 10 HELLO zpráv a z toho se 3 zprávy ztratí, dostaneme kvalitu linky 70 %. [4][5] LinkQualityDijkstraLimit 0 5.0 # Interval to poll network interfaces for configuration # changes. Defaults to 2.5 seconds NicChgsPollInt 3.0 # TC redundancy # Specifies how much neighbor info should # be sent in TC messages # Possible values are: květen 2009
8/18
# 0 - only send MPR selectors # 1 - send MPR selectors and MPRs # 2 - send all neighbors # # defaults to 0 TcRedundancy 0
Nastavení zpráv TC (Topology Control), které obsahují informace o topologii. Mohu posílat tyto zprávy s informacemi pouze o MPRS nebo o MPRS + MPR nebo mohu do zprávy podat informace o všech sousedech. # MPR coverage # Specifies how many MPRs a node should # try select to reach every 2 hop neighbor # # Can be set to any integer >0 # # defaults to 1 MprCoverage 2
Nastavení kolik MPR si budu volit k dosažení každého svého „2-hop“ (vzdáleného dva „skoky“) souseda. Lépe to vysvětlí Ilustrace 2. # Interfaces and their rules Interface "wlan0" { # Olsrd can autodetect changes in NIC # configurations(IP address changes etc.). # This is Enabled by default and the interval # to poll for changes on is defined by # NicChgsPollInt. # This polling can be disabled pr. NIC by setting # AutoDetectChanges to no. AutoDetectChanges yes # # # # #
IPv4 broadcast address to use. The one usefull example would be 255.255.255.255 If not defined the broadcastaddress every card is configured with is used Ip4Broadcast 255.255.255.255
# Hello interval in seconds(float) # HelloInterval 2.0 # HELLO validity time # HelloValidityTime 6.0 # TC interval in seconds(float) # TcInterval 5.0 # TC validity time # TcValidityTime 15.0 # MID interval in seconds(float) # MidInterval 5.0 # MID validity time # MidValidityTime 15.0 květen 2009
9/18
# HNA interval in seconds(float) # HnaInterval 5.0 # HNA validity time # HnaValidityTime 15.0 # # # # # # # # # # # #
When multiple links exist between hosts the weight of interface is used to determine the link to use. Normally the weight is automatically calculated by olsrd based on the characteristics of the interface, but here you can specify a fixed value. Olsrd will choose links with the lowest value. Note: Interface weight is used only when LinkQualityLevel is 0. For any other value of LinkQualityLevel, the interface ETX value is used instead. Weight 0
}
4 Výsledky. 4.1 olsr.org OLSR daemon • • • • • • • • •
Ve výpisech níže jsou použity tyto zkratky: hyst – hystereze LQ - Link Quality – kvalita spoje počítaná uzlem generující výpis. NLQ - Neighbor Link Quality – kvalita spoje dle našich sousedů – posílaná v Hello zprávách. ETX - Expected Transmission Count = 1 / (NLQ x LQ) SYM – spojení se sousedem je symetrické MPR – tento soused je náš MPR MPRS – pro tohoto souseda jsem já jeho MPR will – hodnota willingness tohoto souseda TLQ - Total Link Quality = LQ1 * LQ2 * ... * Lqn
V síti byly stanice s adresami 10.0.0.1, 10.0.0.2, 10.0.0.4 a 10.0.0.5. Grafy a textové informace z olsrd jsou pořízeny ze stanice 10.0.0.1. *** olsr.org - 0.5.4 (2009-04-08 15:42:05 on gentlespring) *** --- 18:04:40.25 ---------------------------------------------------- LINKS IP address hyst LQ lost total NLQ ETX 10.0.0.5 0.000 1.000 0 12 0.000 0.00 10.0.0.4 0.000 0.833 2 12 0.247 4.86 10.0.0.2 0.000 0.667 4 12 0.416 3.61 --- 18:04:40.25 ------------------------------------------------ NEIGHBORS IP address 10.0.0.2 10.0.0.4 10.0.0.5
LQ 0.667 0.833 1.000
NLQ 0.416 0.247 0.000
SYM YES YES NO
MPR YES NO NO
MPRS NO NO NO
will 3 3 3
--- 18:04:40.02255229 ----------------------- TWO-HOP NEIGHBORS květen 2009
10/18
IP addr (2-hop) 10.0.0.2 10.0.0.4 10.0.0.5
IP addr (1-hop) 10.0.0.5 10.0.0.4 10.0.0.5 10.0.0.2 10.0.0.2 10.0.0.4
TLQ 0.000 0.206 0.000 0.277 0.277 0.188
--- 18:04:40.25 ------------------------------------------------- TOPOLOGY Source IP addr 10.0.0.1 10.0.0.1 10.0.0.2 10.0.0.2 10.0.0.2 10.0.0.4 10.0.0.4 10.0.0.4 10.0.0.5 10.0.0.5 10.0.0.5
Dest IP addr 10.0.0.2 10.0.0.4 10.0.0.1 10.0.0.4 10.0.0.5 10.0.0.1 10.0.0.2 10.0.0.5 10.0.0.1 10.0.0.2 10.0.0.4
LQ 0.416 0.247 0.663 1.000 1.000 0.663 1.000 1.000 0.910 1.000 1.000
ILQ 0.667 0.833 0.329 1.000 1.000 0.165 1.000 0.914 0.663 0.914 1.000
ETX 3.61 4.86 4.58 1.00 1.00 9.16 1.00 1.09 1.66 1.09 1.00
Ping ze stanice 10.0.0.1 Vypadal takto: 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64
bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes
from from from from from from from from from from from from from from from from from from from from from from from
10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5:
icmp_seq=78 icmp_seq=79 icmp_seq=80 icmp_seq=81 icmp_seq=81 icmp_seq=82 icmp_seq=83 icmp_seq=84 icmp_seq=84 icmp_seq=86 icmp_seq=87 icmp_seq=88 icmp_seq=89 icmp_seq=90 icmp_seq=91 icmp_seq=92 icmp_seq=93 icmp_seq=94 icmp_seq=94 icmp_seq=95 icmp_seq=96 icmp_seq=97 icmp_seq=98
ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64
time=3.26 ms time=4.61 ms time=3.10 ms time=4.60 ms time=161 ms (DUP!) time=4.06 ms time=4.63 ms time=3.99 ms time=25.2 ms (DUP!) time=5.68 ms time=6.80 ms time=3.90 ms time=4.20 ms time=4.39 ms time=3.23 ms time=3.23 ms time=3.92 ms time=17.7 ms time=50.6 ms (DUP!) time=3.12 ms time=3.01 ms time=4.04 ms time=3.75 ms
Následující výpis znázorňuje situaci, kdy se stroj s IP adresou 10.0.0.1 dostal mimo dosah doslechu stroje 10.0.0.4 – stroj 10.0.0.4 již nedostával žádné Hello zprávy od stroje 10.0.0.1, i když evidentně stroj 10.0.0.1 ještě stále slyšel Hello zprávy stroje 10.0.0.4. Je to patrné ve výpisu v sekci LINKS, kde je vidět, že LQ=0,75, ale NLQ = 0,00 v řádku pro IP adresu 10.0.0.4. Linka mezi nimi je tedy jednosměrná takže nesymetrická. Dále je možno si všimnout, že uzel 10.0.0.4 je stále v dosahu uzlů 10.0.0.2 a 10.0.0.5, které jsou 1-hop vzdálenými sousedy uzlu generujícím výpis. Je to patrno v části TWO HOP NEIGHBORS. Přes tito sousedé
květen 2009
11/18
tedy mohou sloužit jako opakovače zpráv vysílaných či přeposílaných uzlem 10.0.0.1, které jsou adresovány uzlu 10.0.0.4. *** olsr.org - 0.5.4 (2009-04-08 15:42:05 on gentlespring) *** --- 18:19:42.83 ---------------------------------------------------- LINKS IP address 10.0.0.2 10.0.0.5 10.0.0.4
hyst 0.000 0.000 0.000
LQ 0.583 0.750 0.750
lost 5 3 3
total 12 12 12
NLQ 0.663 0.749 0.000
ETX 2.59 1.78 0.00
--- 18:19:42.83 ------------------------------------------------ NEIGHBORS IP address 10.0.0.2 10.0.0.4 10.0.0.5
LQ 0.583 0.750 0.750
NLQ 0.663 0.000 0.749
SYM YES NO YES
MPR YES NO YES
MPRS NO NO NO
will 3 3 1
--- 18:19:42.02838394 ----------------------- TWO-HOP NEIGHBORS IP addr (2-hop) 10.0.0.2 10.0.0.4 10.0.0.5
IP addr (1-hop) 10.0.0.4 10.0.0.5 10.0.0.5 10.0.0.2 10.0.0.4 10.0.0.2
TLQ 0.000 0.562 0.513 0.353 0.000 0.387
--- 18:19:42.83 ------------------------------------------------- TOPOLOGY Source IP addr 10.0.0.1 10.0.0.1 10.0.0.2 10.0.0.2 10.0.0.2 10.0.0.4 10.0.0.4 10.0.0.5 10.0.0.5 10.0.0.5
Dest IP addr 10.0.0.2 10.0.0.5 10.0.0.1 10.0.0.4 10.0.0.5 10.0.0.2 10.0.0.5 10.0.0.1 10.0.0.2 10.0.0.4
LQ 0.663 0.749 0.416 0.910 0.910 0.910 0.910 0.831 1.000 1.000
ILQ 0.583 0.750 0.663 1.000 0.831 1.000 1.000 0.749 1.000 0.914
ETX 2.59 1.78 3.63 1.10 1.32 1.10 1.10 1.61 1.00 1.09
Ilustrace 4 zobrazujíce stejnou situaci, která je zachycena v předchozím výpisu. Graf není přesně ze stejného okamžiku, proto jsou hodnoty ETX v něm mírně odlišné.
květen 2009
12/18
Ilustrace 4: Topologie sítě z pohledu uzlu 10.0.0.1. Elipsy znační uzly, obdélníky značí uzly, které jsou pro 10.0.0.1 MPR. Výpis ping v této situaci obsahuje jen málo duplicit – asi 1 duplicitní na 25 přijatých paketů. Později ping vykazoval mnohem více duplicitních paketů. To bývá způsobeno výskytem smyčky v topologii sítě. Příčinu jsme však nezjistili. Takto vypadal výpis olsrd: *** olsr.org - 0.5.4 (2009-04-08 15:42:05 on gentlespring) *** --- 18:21:57.16 ---------------------------------------------------- LINKS IP address 10.0.0.2 10.0.0.5 10.0.0.4
hyst 0.000 0.000 0.000
LQ 0.833 0.500 1.000
lost 2 6 0
total 12 12 12
NLQ 0.663 0.000 0.000
ETX 1.81 0.00 0.00
--- 18:21:57.16 ------------------------------------------------ NEIGHBORS IP address 10.0.0.2 10.0.0.4 10.0.0.5
LQ 0.833 1.000 0.500
NLQ 0.663 0.000 0.000
SYM YES NO NO
MPR YES NO NO
MPRS NO NO NO
will 3 3 1
--- 18:21:57.02168059 ----------------------- TWO-HOP NEIGHBORS IP addr (2-hop) 10.0.0.2 10.0.0.5 10.0.0.4 10.0.0.5 10.0.0.5 10.0.0.2
IP addr (1-hop) 10.0.0.4 0.000 10.0.0.2 0.000 10.0.0.4 0.552
TLQ 0.000 0.552 0.000
--- 18:21:57.16 ------------------------------------------------- TOPOLOGY Source IP addr 10.0.0.1 květen 2009
Dest IP addr 10.0.0.2
LQ 0.580
ILQ 0.833
ETX 2.07 13/18
10.0.0.2 10.0.0.2 10.0.0.2 10.0.0.4 10.0.0.4 10.0.0.5 10.0.0.5 10.0.0.5
10.0.0.1 10.0.0.4 10.0.0.5 10.0.0.2 10.0.0.5 10.0.0.1 10.0.0.2 10.0.0.4
0.831 1.000 1.000 0.910 1.000 0.831 1.000 1.000
0.580 1.000 1.000 0.914 1.000 0.165 1.000 1.000
2.07 1.00 1.00 1.20 1.00 7.30 1.00 1.00
A takto vypadal výpis ping: 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64
bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes
from from from from from from from from from from from from from from from from from from from from from from from from from from from
10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5: 10.0.0.5:
icmp_seq=275 icmp_seq=275 icmp_seq=276 icmp_seq=277 icmp_seq=278 icmp_seq=278 icmp_seq=279 icmp_seq=280 icmp_seq=280 icmp_seq=281 icmp_seq=281 icmp_seq=282 icmp_seq=282 icmp_seq=282 icmp_seq=283 icmp_seq=283 icmp_seq=284 icmp_seq=285 icmp_seq=285 icmp_seq=286 icmp_seq=286 icmp_seq=287 icmp_seq=288 icmp_seq=289 icmp_seq=290 icmp_seq=290 icmp_seq=291
ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64 ttl=64
time=2.92 ms time=69.9 ms (DUP!) time=5.69 ms time=126 ms time=4.99 ms time=43.1 ms (DUP!) time=3.42 ms time=3.50 ms time=85.0 ms (DUP!) time=3.79 ms time=124 ms (DUP!) time=3.85 ms time=47.2 ms (DUP!) time=144 ms (DUP!) time=3.13 ms time=59.8 ms (DUP!) time=6.60 ms time=3.33 ms time=116 ms (DUP!) time=3.34 ms time=34.6 ms (DUP!) time=3.22 ms time=4.25 ms time=116 ms time=132 ms time=237 ms (DUP!) time=157 ms
Během měření se uzly, mezi kterými běžel ping mezi sebou vzdálily tak, že musely komunikovat přes některého prostředníka. I přesto statistika Pingu mezi těmito uzly nevykazuje příliš mnoho ztracených paketů. --- 10.0.0.5 ping statistics --363 packets transmitted, 344 received, +67 duplicates, 5% packet loss, time 362362ms
5 Závěr Zjistili jsme, že z testovaných implementací OLSR protokolu jsou použitelné implementace Olsr.org, nrlolsr. Existují však problémy s komunikací mezi implementacemi – v heterogenní síti. Existují pluginy do OLSRd, které umožňují šíření multicastů, nebo jen mDNS, plugin pro vykreslení topologie sítě a ještě mnoho dalších. Další práce by se mohly zaměřovat na změření a porovnání režie OLSR a OSPF, při takové konfiguraci uzlů, která by umožňovala jejich velkou migraci a tedy časté změny topologie bez výpadků spojení. Dále také na otestování podpory směrování Ipv6 a multicastů.
květen 2009
14/18
6 Seznam použité literatury 1: Lars Strand, Linux Optimized Link State Routing Protocol (OLSR) IPv6 HOWTO, 2004, http://tldp.org/HOWTO/OLSR-IPv6-HOWTO/olsrlinux.html 2: Andreas Tønnesen, Impementing andextending theOptimized LinkState RoutingProtocol, 2004, http://www.olsr.org/docs/report_html/node54.html 3: Thomas Heide Clausen, Philippe Jacquet, Optimized Link State Routing Protocol (OLSR), 2003, http://www.ietf.org/rfc/rfc3626.txt 4: unknown, , 2004, http://www.olsr.org/docs/README-Link-Quality.html 5: Douglas S. J. De Couto Daniel Aguayo John Bicket Robert Morris, A High-Throughput Path Metric for Multi-Hop Wireless Routing, , http://pdos.csail.mit.edu/grid/
7 Příloha 7.1 Makefile # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
Tento Makefile vznikl, aby automatizoval konfiguraci stojů v MANETu. Copyleft @ Jaroslav Henner == Schopnosti. == * sebe-aktualizace přes scp, z vyhrazeného, pojmenovaného stroje * vytvořit ssh klíč a přidat ho do souboru ~/.ssh/authorized_keys na "hlavním" stroji * detekce rozhraní IEEE 802.11 pomocí HAL * konfigurace zařízení - přepnutí do Ad-hoc, essid, ... * konfigurace ip stacku * konfigurace dns * stáhnout, konfigurovat, zkompilovat implementace == Autoaktualizace Makefile. == Jeden ze strojů v manetu vyhradíme, říkejme mu QUEEN. Z QUEEN se bude pomocí scp stahovat případná nová verze konfiguračního Makefile. V hlavičce skriptu lze nastavit adresa, ze které se má přes scp protokol stahovat novější verze skriptu, což aktualizaci skriptu na cílových uzlech automatizuje. To je velmi výhodné v případě, kdy potřebujeme způsob konfigurace uzlů upravit. == Multicast DNS, == se hodí v případě, kdy hodláme měnit IP adresy (i zvláště v případě testování IPv4 i IPv6) v síti často a přitom nechceme, zřizovat DNS. Což JE situace, ve které se nacházíme -- testování routing protokolů pro MANET. V mnoha distribucích je avahi-daemon instalován a poté spouštěn automaticky po bootu stroje, takže by neměl být problém mDNS použít. Navíc, pokud bychom byli schopni směrovat multicast zprávy po MANETu, získáme tím schopnost resolvovat ip adresu pro všechny stroje v MANETu nutnosti dedikovat jeden stroj jako DNS. mDNS se velmi hodí pro použití v MANETu. Použijeme-li avahi-daemon, můžeme jako doménové jméno QUEEN používat "queenhostname.local", kde queenhostname je hostname počítače queen. Jsou-li stroje vzájemně v dosahu signálu a je-l v souboru /etc/nsswitch.conf na ne-QUEEN strojích řádek: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 pak by měly tyto ne-queen stroje měly být schopny správně resolvovat IP adresu a měly bychom obdržet odpověď na ping queenhostname.local Avahi-daemon by měl běžet na všech strojích, kde požadujeme funkčnost mDNS -- jak QUEEN, tak ne-QUEEN. Pro více informací vizte zeroconf, avahi, nebo [http://0pointer.de/lennart/projects/nss-mdns/]
== Příklad postupu konfigurace zařízení. ==
květen 2009
15/18
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
Nakopírovat Makefile do nějakého adresáře přístupného přes ssh na stroj QUEEN. === Bezheslová aktualizace Makefile === Skript umožňuje vytvořit ssh klíč a skopírovat ho do authorized_keys na QUEEN, čímž umožníme další bezheslový, přístup k souborům na QUEEN. make post_ssh_key Tento krok není nezbytný, ale může nám usnadnit kroky, kdy je potřeba stáhnout nějaké soubory z QUEEN stroje. === Nastavení parametů WiFi === je nutno přepnout rozhraní do Ad-hoc režimu (v případě rozhraní Atheros je potřeba z jádra odpojit modul ovladače a připojit znovu, s jinými parametry), nastavit kanál a ESSID. make devconf === nastavit ip stack === make ipconf === zapnout forwarding === make router === přidat dns do /etc/resolv.conf === make dnsconf === stáhnout a zkompilovat implementace protokolů. === make olsrd make oolsr make nrlolsr make qolsr
QUEEN_NAME=nb1.local IPV=4 # directory, where .ssh/ can be found (Talking about queen slave machines). USERDIR=~root UDI=$(shell hal-find-by-capability --capability net.80211) DEV=$(shell hal-get-property --udi=$(UDI) --key="net.interface") # Interface config ESSID=notebook CHANNEL=5 TXPOWER=10 #INET_ADDR=10.0.0.1 #MSK=24 #INET6_ADDR=:: # Read address from file addr # echo 10.0.0.X > addr will be enough INET_ADDR=$(shell cat addr) MSK=32 BCST=BCST=255.255.255.255 BCST=+ # Use zeroconf-detected nameserver #NAMESRVER= # Use static nameserver NAMESRVER=123.456.789.111 SNAT_TO=123.456.789.222 MKFPATH=Makefile OLSRD_REMOTE_CONF=~guest/olsrd.conf OLSRD_LOCAL_CONF=/etc/olsrd.conf
květen 2009
16/18
OOLSR_SRC=oolsr-0.99.15 OOLSR_PACK=$(OOLSR_SRC).tar.gz OOLSR_WEB=http://hipercom.inria.fr/OOLSR/$(OOLSR_PACK) NRLOLSR_SRC=nrlolsr NRLOLSR_PACK=$(NRLOLSR_SRC)dv7.8.1.tgz NRLOLSR_WEB=http://downloads.pf.itd.nrl.navy.mil/olsr/$(NRLOLSR_PACK) QOLSR_SRC=qolyester-20090302 QOLSR_PACK=$(QOLSR_SRC).tar.bz2 QOLSR_WEB=http://qolsr.lri.fr/code/$(QOLSR_PACK) IP=/sbin/ip IWCONFIG=/sbin/iwconfig IPTABLES=/sbin/iptables INET = $(if ($(IPV),4), inet, inet6) all: devconf ipconf router atheros_hack: $(IP) l set $(DEV) down -modprobe -r ath_pci -modprobe ath_pci autocreate=adhoc sleep 1 devconf: atheros_hack # $(IP) l set $(DEV) down # $(IWCONFIG) $(DEV) txpower off $(IWCONFIG) $(DEV) mode ad-hoc sleep 1 $(IWCONFIG) $(DEV) channel $(CHANNEL) sleep 1 $(IWCONFIG) $(DEV) essid $(ESSID) sleep 1 -$(IWCONFIG) $(DEV) txpower $(TXPOWER) ipconf: $(IP) a flush dev $(DEV) ifdef INET_ADDR $(IP) a a $(INET_ADDR)/$(MSK) b $(BCST) dev $(DEV) endif ifdef INET6_ADDR $(IP) -f inet6 a a $(INET6_ADDR)/$(MSK6) dev $(DEV) endif $(IP) l set $(DEV) up dnsconf: ifdef NAMESRVER echo "search vsb.cz" > /etc/resolv.conf echo "nameserver $(NAMESRVER)" >> /etc/resolv.conf else avahi-dnsconfd -r endif router: ifeq ($(IPV), 4) sysctl -w net.ipv4.ip_forward=1 else sysctl -w net.ipv6.ip_forward=1 endif no_router: ifeq ($(IPV), 4) sysctl -w net.ipv4.ip_forward=0 else sysctl -w net.ipv6.ip_forward=0 endif # Create SSH identity, if needed.
květen 2009
17/18
$(USERDIR)/.ssh/id_rsa.pub: ssh-keygen -t rsa # Make queen know this user. # Will allow secure passwordless login to remote host. post_ssh_key: $(USERDIR)/.ssh/id_rsa.pub cat $(USERDIR)/.ssh/id_rsa.pub | \ ssh guest@$(QUEEN_NAME) "cat >> ~guest/.ssh/authorized_keys" getmake: scp guest@$(QUEEN_NAME):$(MKFPATH) . masquerade: router modprobe ipt_MASQUERADE $(IPTABLES) -F; $(IPTABLES) -t nat -F; $(IPTABLES) -t mangle -F $(IPTABLES) -t nat -A POSTROUTING -o eth0 -j SNAT --to $(SNAT_TO) olsrd: apt-get install olsrd olsrd_getconf: ssh guest@$(QUEEN_NAME) "cat $(OLSRD_REMOTE_CONF)" | \ sed 's/__DEV__/$(DEV)/g' > $(OLSRD_LOCAL_CONF)
$(OOLSR_PACK): wget $(OOLSR_WEB) oolsr_unpack: $(OOLSR_PACK) tar xf $< oolsr_patch: oolsr_unpack scp guest@$(QUEEN_NAME):tuple.patch $(OOLSR_SRC)/include/ # cd $(OOLSR_SRC)/include && patch < tuple.patch oolsr: oolsr_patch cd $(OOLSR_SRC)/src \ && cp Makefile.private.template Makefile.private \ && make
$(NRLOLSR_PACK): -apt-get install libpcap-dev wget $(NRLOLSR_WEB) nrlolsr: $(NRLOLSR_PACK) tar xf $< cd $(NRLOLSR_SRC)/unix \ && make -f Makefile.linux $(QOLSR_PACK): wget $(QOLSR_WEB) qolsr: $(QOLSR_PACK) tar xf $< cd $(QOLSR_SRC) \ && ./configure --prefix=/usr/local cd $(QOLSR_SRC) \ && make
květen 2009
18/18
