EXAMENSARBETE
2002:014 HIP
HÖGSKOLEINGENJÖRSPROGRAMMET DATATEKNIK
Institutionen i Skellefteå
2002: 014 HIP · ISSN: 1404 - 5494 · ISRN:LTU - HIP - EX -- 02/014 --SE
Cellular IP
Joel Fransson och Erik Ljungberg
Sammanfattning
Cellular IP är ett nytt nätverksprotokoll på ingång som är tänkt att lösa prestandaproblemen i Mobile IP. Influenser har tagits från hur mobiltelefonnäten är uppbyggda för att lösa
problemen med förflyttning mellan basstationer på ett smidigt sätt.
Detta examensarbete syftade till att bygga upp ett Cellular IP nätverk och utvärdera funktionalitet och prestanda i ett sådant nätverk. I uppgiften ingick att installera och om nödvändigt modifiera befintlig kod och att redovisa lämpliga mätningar. Rapporten innehåller dokumentation för installation och konfigurering av protokollet samt all nödvändig
programvara.
Examensarbetet utgör en god grund för fortsatt arbete inom området.
2
Förord
Denna rapport är resultatet av ett tiopoängs examensarbete utfört för ArchNet&Tech mellan oktober 2001 och januari 2002. Arbetet har utförts i Luleå universitets lokaler i Skellefteå.
Följande personer har underlättat arbetet och är därmed förtjänta av ett stort tack
Christer Åhlund, Luleå tekniska universitet, institutionen i Skellefteå Bengt-Arne Fjellner, Luleå tekniska universitet, institutionen i Skellefteå Jörgen Wiklund, Student, Luleå tekniska universitet, institutionen i Skellefteå Andreas Westin, Student, Luleå tekniska universitet, institutionen i Skellefteå Sanghyo Kim, EE department of Columbia University
Uminova Center, finasiellt stöd
Skellefteå 2002-04-26
Erik Ljungberg Joel Fransson
1 INTRODUKTION ...5
1.0 SYFTE...5
1.1 BAKGRUND...5
1.1.0 Mobile IP ...5
1.1.1 Cellular IP ...6
1.1.2 Cellular IP Routing...6
1.1.3 Hand Off ...7
2 FÖRSTUDIE AV WAVELANKORT OCH INSTÄLLNINGAR UNDER WINDOWS 2000...8
3 INSTALLATION ...9
3.1 INSTALLATION AV OCH INSTÄLLNINGAR I FREEBSD4.4STABLE...9
3.2 INSTALLATION AV CELLULAR IP PROGRAMPAKETET...9
3.2.1 Systemkrav ...10
3.2.2 Installation av Pcap...10
3.2.3 Installation av Cellular IP protokollet...10
3.2.4 Konfiguration av Cellular IP...11
3.2.5 Cipmobile.conf...11
3.2.6 Cipnode.conf...12
4 SYSTEMKONFIGURATIONER ...13
4.1SYSTEMKONFIGURATION FÖR MOBIL ENHET...13
4.2SYSTEMKONFIGURATION FÖR BASSTATIONERNA...14
4.3SYSTEMKONFIGURATION FÖR GATEWAY...14
5 ANVÄNDNING AV CELLULAR IP ...15
5.1 BASSTATIONERNA SAMT GATEWAY...15
5.2 MOBILA ENHETER...15
6 MODIFIERINGAR I KÄLLKODEN FÖR CELLULAR IP...17
7 TESTLABB ...18
7.1 TOPOLOGI...18
7.2 ROUTER KONFIGURATION...19
7.3 HÅRDVARUSPECIFIKATION...19
7.4 KONTROLLPROGRAM FÖR DEN MOBILA ENHETEN...21
8 FELSÖKNING ...23
8.1 PRINTIPTREE...23
8.2 FILEDEBUG...24
9 TEST ...25
9.1 STRESSTEST MED TCPSPRAY...25
9.2 TESTRESULTAT...25
9.3 TEORETISK JÄMFÖRELSE MELLAN MOBILE IP OCH CELLULAR IP...27
10 SLUTSATS ...29
10 SLUTSATS ...29
12 REFERENSER...30
BILAGA 2: CIPNODE.CONF (GATEWAY MODE)...32
BILAGA 3: CIPMOBILE.CONF ...33
BILAGA 4: AUTOSPRAY.C (STRESS TEST MED TCPSPRAY)...34
4
BILAGA 5: AUTOSPRAY.H...40
BILAGA 6: SENDER.C ...41
BILAGA 7: SENDER.H ...48
BILAGA 8: SPRAYER.C...49
BILAGA 9: PRINTIPTREE ...52
BILAGA 10: FILEDEBUG...54
BILAGA 11: CIPMOBILE.C (ÄNDRINGAR I FILEN) ...55
1 Introduktion
Handdatorer och andra mobila datorenheter är numera billigare, bättre och har snabbare uppkoppling vilket gör att fler och fler människor anser det värt att skaffa. Detta skapar behov av effektiva nätverksprotokoll för mobila enheter.
1.0 Syfte
Syftet med detta arbete är först och främst att sätta upp ett Cellular IP nätverk under en FreeBSD miljö. I detta ingår att installera hårdvara, drivrutiner och nödvändig programvara för Cellular IP i lämplig FreeBSD version. Lämpliga mätningar ska sedan göras på systemet.
1.1 Bakgrund
1.1.0 Mobile IP
Sedan tidigare finns ett protokoll kallat Mobile IP [3] som hanterar transparent mobilitet.
Protokollet löser problemet med var den mobila enheten befinner sig med hjälp av en så kallad Home Agent. Denna befinner sig på hemmanätverket och har en statisk IP-adress, Home Adress. När någon sedan skall kommunicera med den mobila enheten skickas en förfrågan till Home Address. Home Agenten skickar vidare inkommande paket till den mobila enhetens temporära IP-adress (Care of Address). Temporära adresser delas ut av en så kallad Foreign Agent. Då den mobila enheten rör sig mellan olika nätverksceller erhålles nya temporära IP-adresser. Vid varje cellbyte måste alltså en ny temporär adress fås av Foreign Agent som sedan registreras hos den mobila enhetens Home Agent.
I Fig.1 skall den externa enheten kommunicera med den mobila enheten. Kommunikationen inleds genom att den externa enheten skickar sin förfrågan till Home Agent där den mobila enhetens Home Address är. Home Agent vet sedan var den mobila enheten befinner sig genom dess Foreign Address. Därför vidarebordrar Home Agent alla paket till Foreign Agent
Mobil enhet Home Agent
Internet
Foreign agent Extern enhet
Fig 1 beskriver trafikflödet i ett Mobile IP nätverk.
6 som i sin tur skickar vidare till den mobila enheten. Den mobila enheten kan i sin tur skicka svar direkt till den externa enheten via Foreign Agent.
Svagheten med Mobile IP ligger först och främst mellan Foreign Agent och den Mobila enheten. Problemet här är att det blir väldigt mycket kommunikation då den mobila enheten rör sig mellan noder i samma nät (Hand Off) eftersom Home Agent måste meddelas om den nya positionen. Förutom detta hanterar protokollet inte inaktiva enheter på ett optimalt sätt utan kräver att även dom skall skicka positionsmeddelanden lika ofta som aktiva enheter.
1.1.1 Cellular IP
För att lösa dessa problem är ett nytt protokoll under utveckling som heter Cellular IP. Till skillnad mot Mobile IP är Cellular IP inriktat mot optimering i lokala trådlösa nätverk.
Cellular IP har ärvt mycket av mobiltelefonnätens filosofi för att uppnå optimal prestanda. Ett exempel på detta är hanteringen av inaktiva enheter. Så länge en mobil enhet inte är aktiv finns ingen anledning att belasta nätet med onödig information utan det räcker med att
Cellular IP:s gateway vet på ett ungefär var man befinner sig. Följaktligen sparas på detta sätt bandbredd i nätverket vilket leder till att fler användare kan utnyttja samma nätverksresurser.
Dessutom för det med sig fördelar för den mobila enheten då mindre kommunikation gör att batteritiden blir längre. Cellular IP är dock fortfarande baserat på IP protokollet och kan därför skalas från väldigt små till väldigt stora installationer.
1.1.2 Cellular IP Routing
Basstationerna fungerar som ett slags routrar då de skickar vidare inkommande trafik efter en uppbyggd tabell. För att minimera kontrollmeddelanden inom nätverket så använder
basstationerna vanliga datapaket från mobila enheter för att komma ihåg dess position. Vid varje basstation sparas tabellen och sedan läggs den aktuella basstationen till. Efter det skickas tabellen vidare för att memoreras i nästa basstation. När man inte har någon data att skicka skickas emellanåt tomma paket till gatewayen så att basstationerna har en aktuell routing cache [2]. Inkommande paket, s.k. downlink packages, använder sedan tabellen i basstationerna för att finna den sökta enheten. För att hitta den mobila enheten i exemplet nedan (figur 2) kommer gatewayen att skicka vidare den inkommande trafiken till den
basstation som ligger närmast enligt gatewayens routingtabell (1). Basstationen skickar sedan vidare paketen till den basstation som enligt dess tabell ligger närmast (2). Samma sak händer en gång till (3). Nu befinner sig paketen på den basstation som har den mobila enheten i sitt område och kommer att skickas till sin destination (4).
Foreign Agent Gateway
Basstation 1
2
3
Mobil enhet Inkommande
trafik
4
1.1.3 Hand Off
Cellular IP protokollet har även en bättre lösning på cellbyten (Soft Hand Off). Lösningen minskar kommunikationen med den mobila enhetens Home Agent då lokaliseringen av den mobila enheten sköts av Foreign Agent. Till skillnad från Mobile IP, där Home Agent känner till den mobila enhetens nuvarande IP address som kan ändras vid cellbytena, känner Home Agent vid Cellular IP bara till Foreign Agent vilken är densamma vid cellbyte. Resultatet blir att man slipper en positioneringsfördröjning mellan Home Agent och den mobila enheten.
I figur 3 nedan förflyttar sig den mobila enheten mellan två celler (A och B) samtidigt som den sänder data till en host utanför gatewayen. När den mobila enheten når den nya cellen B, skickar den mobila enheten automatiskt sina meddelande via B. Det första paketet som går via basstationerna dirigerar om alla nya inkommande paket till den nya cellen B. Nu kommer inkommande paket att både skickas till A och B under en tid som motsvaras av tiden för en så kallad Routing cache timeout. Under den här tiden kan den mobila enheten om den har stöd för att ta emot data på två logiska kanaler ta emot inkommande paket från A och B (Soft Hand Off). Har den inte stöd för det kan den missa några paket som skickas till A innan en
omdirigering har skett.
Foreign Agent Gateway
Basstation
Mobil enhet Inkommande
trafik
Fig 3 beskriver förflyttning av mobila enheten mellan celler
A
B
8
2 Förstudie av wavelankort och inställningar under Windows 2000
För att få en bättre förståelse av hur wavelankorten skall konfigureras installerades och gjordes först alla inställningar under Windows 2000. Anledningen till detta är att enkla program för inställningar och monitorering finns tillgängliga för denna plattform.
Programmen är ORINOCO Client Manager, ORINOCO Wireless Network Settings och ORINOCO Access Point Manager. För mer information om dessa produkter se [1].
Under förstudien fanns även tillgång till en basstation (access point) så första målet efter installationen blev att försöka få Internetaccess via wavelankortet. Detta visade sig vara mer komplicerat än beräknat då basstationen verkade vara onåbar via wavelan. Den första teorin var att firmware för wavlankorten i de stationära datorerna och basstationen var olika, därför uppgraderades båda till senaste versionen som fanns tillgänglig på www.wavelan.com vid tidpunkten (oktober 2001). Då detta inte hjälpte undersöktes basstationens inställningar närmare. Till detta används ORINOCO Access Point Manager som kontaktar basstationen via det fasta nätverket. Problemet visade sig vara att basstationens accesslista enbart innehöll sin egen MAC-adress vilket förståeligt nog stoppar all trafik. Varför basstationen var inställd så är oklart.
Tester med peer-to-peer inställningar gjordes också under förstudien. Ett sådant nätverk bygger på att datorerna kommunicerar med varandra direkt. Inställningarna som krävs för att få detta att fungera är relativt simpla och lättförståliga och orsakade inga problem. För att specificera wavelaninställningar används ORINOCO Client Manager och ORINOCO Wireless Network Settings.
3 Installation
3.1 Installation av och inställningar i FreeBSD 4.4 Stable Installationen av FreeBSD på de stationära datorerna skapade tidigt problem då installationsprogrammet inte verkade fungera utan allt stannade redan under uppstart.
Anledningen till detta visade sig vara våra pccard-läsare. FreeBSD hade inte i versionen som användes stöd för de kort (Noname pcikort) som standard. Dessa kort byttes helt enkelt ut mot en annan typ av kort (ORINOCO isa) och sedan hade installationsprogrammet inga problem att starta. Nu fungerade istället inte uppstart av kortet utan det blev problem med IRQ tilldelning. Lösningen till problemet var att ändra i datorns bios inställningar. Då
parallellporten som använder sig av IRQ 7 inte behövdes, inaktiverades parrallellporten. IRQ 7 reserverades sen för ISA kort. Nu fungerade pccardläsaren då den tilldelades IRQ 7 vilket också ledde till att installationen av systemet kunde startas via wavelankortet. Beslutet att installera via wavelankortet berodde på att ganska lite erfarenhet av FreeBSD fanns vid tidpunkten, därför verkade det mest logiskt att låta installationen lösa problemet med
drivrutiner. IRQ problemet hade i vilket fall kvarstått och kanske orsakat ännu mera problem senare om installation av systemet via andra nätverksmedium.
Installation på den bärbara datorn var betydligt enklare och orsakade inga problem. Detta beror med allra största säkerhet på att pccardläsare är integrerade betydligt bättre på bärbara datorer.
För att göra inställningar för wavelandrivrutinen under FreeBSD används ett program som heter wicontrol med syntaxen:
wicontrol –i interfacenamn –x värde där i står för interface, interfacenamn namnet på det interface man vill göra ändringar på, -x är vad man vill ändra på t.ex. –p (port), värde för –x t.ex. 3 för peer-to-peer då man valt –p.
Exempel: wicontrol –i fxp0 –p 3 Ställer in peer-to-peer mode för fxp0.
För en mer ingående beskrivning av wicontrol se manualsidan (man wicontrol).
För att göra mera allmänna inställningar för kärnan används kommandot sysctl som både kan hämta och sätta inställningar i kärnan. Då detta kommando är väldigt komplext hänvisas till manualsidorna under FreeBSD för mer information. För att visa sysctls manual skrivs man sysctl i lämplig terminal.
3.2 Installation av Cellular IP programpaketet
För information om nerladdning av programpaketet Cellular IP se [2]. Paketet kommer i form av en fil packad med tar och gzip. Denna fil innehåller i sin tur programvaran till Cellular IP samt pcap. Båda dessa kommer i form av ickekompilerade källkodsfiler skrivna i
programspråket c (c och h filer). Pcap används av FreeBSD för att kunna läsa och skriva inkommande och utgående paket som skickas via ett nätverksinterface. Detta är tvunget att användas eftersom Cellular IP fortfarande är på teststadiet och fungerar mer likt ett program som ligger och ”lyssnar” på nätverkstrafiken.
10 3.2.1 Systemkrav
För att installera och köra Cellular IP finns det vissa rekommenderade systemkrav, både mjuk och hårdvara. Hårdvarurekommendationerna för testlabbet är minst två stycken datorer med en klockfrekvens på minst 200 MHz (pentium eller bättre). Dessutom måste man ha en dator med samma hårdvarukrav för användning som gateway. Som mobil enhet användes en bärbar dator med vilken handoffs etc. testades. Basstationerna och den mobila enheten måste även vara utrustade med nätverkskort kompatibla med 802.11b standarden för trådlös
nätverksöverföring. Trådlösa kort av eller kompatibla med typen ORINOCO WaveLAN är att föredra då andra kort t.ex. Aironet inte stöds i funktioner för exempelvis signalstyrkemätning i Cellular IP. Operativsystemen som stöds är FreeBSD 3.2 och Linux 2.2.12 och 2.2.14. Den grafiska applikationen som körs på den mobila enheten kräver Tcl/tk 8.1.
3.2.2 Installation av Pcap
Enligt medföljande instruktioner börjas installationen med att bygga Pcap vilken man gör genom att i katalogen ./cip-1.0/etc/ exekvera ./configure. Configure kommer att undersöka systemet och generera en Makefile som passar för just den installationen. När en Makefile har blivit gjord så kompileras Pcap genom att skriva make. Innan man kompilerar skall dock rad 144 i filen pcap-bpf.c ändras från fd=open(device, O_WRONLY) till fd=open(device, O_RDWR). Därefter installeras pcap genom att skriva make install, make install-incl och make install-man.
Vid installationen av pcap dök det dock upp problem vid kompileringen. Variabeln
ether_hostton i filen nametoaddr.c var enligt kompilatorn redan definierad i systemet. Detta löstes genom att helt enkelt kommentera bort variabeln i den filen. Sanghyo Kim1 har senare verifierat att denna modifikation kan utföras utan risk för programmets funktionalitet. Vidare krävdes det också diverse program (elf och bison) utöver de som står i dokumentationen.
Dessa finns i FreeBSDs portsträd2 och installerades därför smärtfritt.
3.2.3 Installation av Cellular IP protokollet
Cellular IP behöver inte installeras likt Pcap utan det räcker med att kompilera källkoden genom att skriva make i katalogen ./cip-1.0/node/. Även här kan det dock behövas lite ändringar i filer innan kompileringen beroende på vilken hårdvara som skall användas samt om Mobile IP skall kombineras med Cellular IP eller inte. Finns tillgång till ett WaveLAN kort behövs det inte göras någon ändring då detta antas som standard. Ägare av ett Aironet kort behöver dock ändra rader där det står –DWICACHE till –DANCACHE i make filen. För test av interaktionen mellan Cellular IP med Mobile IP behövs endast det sista _ tas bort i Makefilen där det som standard står –DMOBILE_IP_.
1 Phd Columbia University http://www.comet.columbia.edu/~shkim2/
2 En samling makefiler som ingår i standardinstallationen av FreeBSD och som vid installation hämtas automatiskt ifrån ftp servrar.
Ett eget kontrollprogram behövde skrivas för den mobila enheten. Detta var nödvändigt för att tillhandahålla ett grafiskt gränssnitt mot Cellular IP då det medföljande fungerade dåligt.
Programmet kompileras enkelt genom att skriva gcc –pthread sender.c –o send.
3.2.4 Konfiguration av Cellular IP
Inställningar på basstationen, gatewayen eller den mobila enheten görs genom ändringar i konfigurationsfilerna för respektive enhet. Den mobila enheten använder sig av
cipmobile.conf filen medan basstationen och gatewayen båda använder sig av cipnode.conf filen. Dessa filer hittas i katalogen /cip-1.0/node/.
3.2.5 Cipmobile.conf
Cipmobile vilket är programmet som körs på den bärbara datorn använder cipmobile.conf, därför skall alla konfigurationer för den mobila enheten göras i denna fil. Följande
inställningar är möjliga att göra i filen (alla tidsangivelser anges i millisekunder):
• wireless interface
o Specificerar namnet på det trådlösa interfacet som den mobila enheten skall använda sig av. t.ex. wi0
• mobile’s IP address
o IP adressen för den mobila enheten. t.ex. 128.59.69.71
• air interface name
o Namnet på interfacet. t.ex.mobile-air.
• route-update-time
o Hur ofta routing updates skall skickas. t.ex. 100.
• paging-update-time
o Hur ofta page updates skall skickas. t.ex.10000.
• active-state-timeout
o Efter denna tid går den mobila enheten in i inaktivt läge. t.ex. 5000.
• Handoff
o Anger man 0 görs en handoff beroende på specificerad tidsintervall i Tcl/tk applikationen. Anger man 1 görs handoff beroende på signal styrkan på wavelaninterfacet.
Exempel på cipmobile.conf filen som användes i testlabbet finns i Bilaga 3.
12 3.2.6 Cipnode.conf
Den här filen används av cipnode och i den görs inställningar som har med basstationerna och gatewayen att göra. Följande inställningar är möjliga (tidsangivelser anges i millisekunder):
• GW
o Yes om datorn skall användas som en gateway. No om den skall användas som en basstation.
• IF YES, deafult router’s IP address
o Om man använder den som en gateway skall IP numret för routern skrivas in.
t.ex. 128.59.67.1
• IF NO, neighbor, uplink direction
o Om det är en basstation skall interface samt IP till datorn som ligger uppåt i nätet anges. t.ex. (wire, fxp0, 128.59.68.250)
• leaf neighbours
o Här skall underliggande datorer i nätverket anges. t.ex. för basstationerna (wireless, wi0) och för gatewayen (wire, fxp0, 128.59.68.249).
• paging cache
o Yes om paging skall användas, No om det inte skall användas.
• if yes then size
o Storleken på paging cache
• route-timeout
o Hur lång tid av inaktivitet det skall ta innan en nod tas bort ut routing tabellen.
t.ex. 3000.
• paging-timeout
o Hur lång tid av inaktivitet det skall ta innan en nod tas bort ur paging tabellen.
t.ex. 30000.
• max number of nodes in cache
o Specificerar hur många noder som skall sparas i tabellerna. t.ex. 100.
• GW IP address
o IP numret som gatewayen kör på. t.ex. 128.50.68.250.
Exempel på cipnode.conf filen som användes för basstationerna respektive gatewayen i testlabbet finns i Bilaga 1 och Bilaga 2.
4 Systemkonfigurationer
4.1 Systemkonfiguration för mobil enhet
För att slippa utföra en massa inställningar efter varje omstart av den mobila enheten har en körbar fil innehållande alla systeminställningskommandon skapats. Detta så kallade script innehåller kommandon för nätverksinställningar av två typer. Wicontrol för inställningar mot wavelankortets drivrutin och syctl för kommandon mot kärnan.
Scriptet innehåller följande kommandon:
• wicontrol –i wi0 –p 3
-p 3 ställer in ad-hoc läge vilket betyder att kommunikation är möjlig med samtliga wavelankort med denna inställning. Detta gäller inte nödvändigtvis för kort från olika leverantörer.
• wicontrol –i wi0 –c 0
-c 0 används för att inaktivera IBSS(simulering av accesspunkt). Enligt manualsidan för wicontrol fungerar det inte att sätta –c till 1. Möjligen behövs detta inte ens ställas in då det är inställt till 0 som standard.
• wicontrol –i wi0 –n ANY
-n ANY ställer in nätverksnamnet. ANY betyder att kortet kan välja vilket nät som helst att kommunicera med
• wicontrol –i wi0 –q ANY
-q ställer in namnet för IBSS. Antagligen är detta kommandot helt överflödigt
• wicontrol –i wi0 –s SynthMobil
-s ställer en bart in stationsnamnet. I detta fallet är det inställt till SynthMobil
• sysctl machdep.wi_cache_iponly=0
Enligt Cellular IP manualen gör detta kommando det möjligt för den mobila enheten att ta emot beaconsignaler från basstationerna. Basstationernas beaconsignalpaket är skrivna på ett sådant sätt att den mobila enheten inte känner av dem som vanliga IP- paket. Detta syns t.ex. med programmet tcpdump som tolkar dessa paket som IPX.
Enligt specifikationer i Cellular IP manualen skulle man skriva sysctl –w … men i FreeBSD 4.4 Stable är –w ”silently ignored”. Vad –w står för finns inte heller beskrivet i manualsidan för sysctl.
Vidare har även den mobila enhetens IP-adress skrivits in för hand i filen rc.conf som hittas i katalogen /root/etc/. Detta bör inte kombineras med inställningar för DHCP då IP-adressen blir korrupt då DHCP-protokollet försöker hitta DHCP-servern för uppdatering av IP- adressen.
Inställning av IP-adressen för wavelankortet i rc.conf ser ut på följande sätt:
ifconfig_wi0=”inet 128.59.69.71 netmask 255.255.255.0”
ifconfig_pccard=”inet 128.59.69.71 netmask 255.255.255.0”
Förmodligen krävs endast en av dessa rader .
14 4.2 Systemkonfiguration för basstationerna
Även för basstationen har inställningarna ”scriptats” för att göra det enklare att göra alla konfigurationer efter uppstart av systemet. Samtliga inställningar för wicontrol är identiska med de i den mobila enhetens script förutom stationsnamnen. Dessa är dock satta på precis samma sätt som i den mobila enheten så vidare förklaring om hur detta är gjort är överflödigt.
Övriga inställningar i scriptet på basstationerna är följande:
• sysctl –x net.inet.ip.forwarding=0
Detta kommando säger åt systemet att inte ”routa” IP-paket. Då all trafikkontroll ska ske via Cellular IP programvaran är inte routing i systemet önskvärt.
Likt konfigurationen för den mobila noden har även här IP-adresser skrivit in i rc.conf. I detta fallet ser det ut på följande sätt:
ifconfig_fxp0=”inet 128.59.68.251 netmask 255.255.255.0”
ifconfig_wi0=”inet 128.59.69.69 netmask 255.255.255.0”
ifconfig_pccard=”inet 128.59.69.69 netmask 255.255.255.0”
4.3 Systemkonfiguration för gateway
Konfigurationen för gatewayen är betydligt mer simpel då denna dator inte har något wavelankort. Uppsättningen av gatewayen är i stället konfigurerad med två stycken Fast Ethernet kort. Ett som är kopplad till basstationerna via en switch och ett som är direktkopplat till routern.
I rc.conf ser det ut på följande sätt
ifconfig_fxp0=”inet 128.59.68.250 netmask 255.255.255.0”
ifconfig_fxp1=”inet 128.59.67.2 netmask 255.255.255.0”
5 Användning av Cellular IP
Cellular IP i nuvarande version är uppdelat i två körbara program, cipnode och cipmobile, som används för det lokala Cellular IP nätverket.
5.1 Basstationerna samt Gateway
På basstationerna samt gatewayen startas cipnode. Detta program sköter sig, efter en lyckad konfigurering, mer eller mindre självt. Basstationerna börjar efter initiering skicka ut beacon meddelanden som är tänkta att snappas upp av närliggande mobila enheter.
5.2 Mobila enheter
De bärbara enheterna skall starta cip vilket är en Tcl/tk applikation som tillhandahåller ett GUI (Graphical User Interface) mot cipmobile. I GUI applikationen visas vilken basstation den mobila enheten använder sig av för närvarande. Det går också att styra handoffs. Detta görs genom att antingen trycka på Forced handoff (tvinga fram en handoff), SNR based handoff (handoff då signalen från basstationen är för svag) eller genom att skriva in en tids enhet för periodisk handoff (anges i millisekunder och innebär t.ex. två handoffs / sekund).
I testlabbet som användes fungerade dock inte den grafiska applikationen för den mobila enheten på ett satisfierande sätt. Programmet startade ibland inte, och startade det så
fungerade inte funktionerna för handoffs etc. Efter felsökning konstaterades att problemet låg i socketkommunikationen mellan GUI-applikationen och cipmobile. En möjlig orsak till detta kan vara att Tcl/tk version 8.1 inte kördes på FreeBSD installationerna då denna version inte kunde hittas. Versionerna 8.0, 8.2 och 8.3 testades däremot utan lyckat resultat.
Efter att ha undersökt vilken funktionalitet som önskades av gränssnittet mot cipmobile för testerna skrevs ett eget program för styrningen3 (send).
Programmet skrevs i C och är gjort för att användas i terminal fönstret. Det är dock menybaserat så ingen användarvänlighet har gått förlorad. Signaler används istället för sockets för att kommunicera med cipmobile. När send startas i ett terminal fönster så presenteras en meny:
0.0.0.0
1: Forced Handoff
2: Snr Based
3: Periodic Handoff
4: Quit
3 Se bilaga 6
16 5: Reset
6: Periodic with tcpspray
7: Scripted
De första siffrorna visar IP-numret på den basstation som den mobila enheten för närvarande är uppkopplad emot. IP-numret kommer även att uppdateras då en ny basstation väljs.
1: Gör en forced handoff och kommer att välja en ny basstation om det finns en sådan tillgänglig.
2: Om signalstyrkan på wavelan interfacet blir för låg kommer en handoff att göras.
3: Efter en 3:a har blivit vald så skall det skrivas in en tidsenhet i tiondels sekunder, detta anger hur ofta en handoff kommer att göras.
4: Programmet kommer att avslutas.
5: Används för att stänga av periodic handoff (sker även då annat val valts).
6: Används för att göra automatiserade mätningar med tcpspray med en peridosk handoff.
7: Ur funktion, tänkt att användas för framtida arbete.
En teknisk beskrivning av programmet finns i Kap 7.4.
6 Modifieringar i källkoden för Cellular IP
Källkoden fungerar säkert utmärkt om rätt version av FreeBSD används4. Men för det testlabb som användes och önskemål som fanns var det nödvändigt att göra vissa modifieringar i källkoden. Dessa modifikationer gjordes framförallt i cipmobile.c och cipmobile.h samt cipnode.c och cipnode.h. Alla filer där det skett ändringar finns som bilagor. I stora filer där bara viss ändring skett finns enbart ändringen med som bilaga.
Något som ställde till stora problem vid tidiga tester var att den mobila enheten inte hittade någon basstation på över fyra minuter. Det krävdes lång felsökning och till slut genomgång av all källkod innan felet upptäcktes. Av någon anledning så var i filen ./cip-1.0/etc/pcap-bpf.c (en del i Pcap) en variabel v tilldelad ett värde på 32768. Denna variabel styr hur många beaconmeddelanden som skall tas emot av den mobila enheten innan bearbetning sker. Read- funktionen mot socketen väntar nämligen på så många bytes innan den går vidare med exekveringen. Eftersom varje beaconmeddelande endast är 44 byte stort tar det 745 beaconmeddelanden med en basstation och 376 beaconmeddelanden med två basstationer innan den mobila enheten registrerar att den kommit nära en ny basstation. Efter ändringar av v till ett mycket lägre värde ökade plötsligt prestanda i testerna rejält.
I ./cip-1.0/node/cipmobile.c togs all kommunikation via sockets mellan cipmobile och Tcl/tk applikationen bort och ersattes med en tråd som kommunicerade med det egenskrivna programmet. Funktioner som lades till är:
void thread_handle_message()
Körs i en egen tråd. Funktionen anropar funktioner för att läsa av meddelanden.
void CheckForMessages()
Kollar efter meddelanden ifrån testprogrammet. Funktionen svarar även på meddelanden om det behövs.
void SendMessage(struct msgStruct *inStruct)
Skickar iväg ett meddelande till testprogrammet med informationen som kommer in i inStruct.
void SendBaseStationInfo()
Skickar information (IP-adress) om vilken basstation som används.
Dess funktioner finns i Bilaga 11.
4 CellularIP är utvecklat för äldre versioner av FreeBSD än 4.4-Stable som användes
18
7 Testlabb
7.1 TopologiSamtliga tester är utförda på en topologi enligt figur 4. Uppsättningen skiljer sig till viss del mot den som ritas upp i Cellular IP manualen5. Skillnaden är i första hand att testlabbet är uppdelat i 3 olika delar. I motsatts mot Cellular IP manualen har dessa olika delar tilldelats olika subnät, 69 för 1, 68 för 2 och 67 för 3. Anledningen till denna uppdelning är att basstationerna och gatewayen hade problem med trafik från samma subnät på de två
nätverkskorten samtidigt. För att se mer detaljerad beskrivning om hur, gateway, basstationer och den mobila noden är konfigurerade se Bilaga 1 för Basstationer, Bilaga 2 för Gateway och Bilaga 3 för den mobila enheten.
5 http://www.comet.columbia.edu/cellularip/manual.htm
128.59.69.72 128.59.69.69
128.59.69.71
128.59.68.251 128.59.68.249
128.59.68.250
128.59.67.2
128.59.67.1 Basstation Basstation
Gateway
Mobil Switch
Router
1 2 3
Fig 4. visar testlabbs topologin
7.2 Router konfiguration
För att kunna testa Celular IP protokollet kopplades en Cisco 2600 series router till gateway.
Till routern kopplades sedan en Windows NT dator, med en ftp server installerad, som
simulerar Internet. Routern konfigurerades alltså med två Ethernet-interface mot två olika nät.
Ett problem som uppstod var att den mobila enheten vid tester aldrig fick svar på skickade meddelanden till vare sig routern eller Internet-datorn. Debugutskrifter visade klart och tydligt att meddelanden nådde routern men aldrig kom därifrån. Lösningen på problemet var att konfigurera standard gateway för routern till IP numret för CellularIP-gatewayen. Detta innebär att all inkommande trafik till routern som inte skall till en enhet på ett intilliggande nät skickas till gatewayen. Kommandot som användes på routern var:
Router(config)#> router rip
Router(config-router)#> ip route 0.0.0.0 0.0.0.0 128.59.67.2
7.3 Hårdvaruspecifikation
För att testa funktionaliteten i Cellular IP kopplades ett testlabb6 upp. Följande hårdvara användes i testlabbet:
Basstationer:
• Pentium 2 300 MHz
• 128 MB RAM minne
• ORINOCO WaveLAN Silver 11 MBit
• Intel Pro 100 Mbit nätverkskort
• ORINOCO Pccard reader
• FreeBSD 4.4-STABLE Gateway:
• Pentium 2 300 MHz
• 128 MB RAM minne
• Intel Pro 100 MBit nätverskort
• FreeBSD 4.4-STABLE Mobil enhet:
• Pentium 2 300 MHz
• 128 MB RAM minne
• ORINOCO WaveLAN Silver 11 Mbit
• FreeBSD 4.4-STABLE Internet dator:
6 Se fig. 4 kap 7.1
20
• Pentium 2 300 MHz
• 128 MB RAM minne
• Intel Pro 100 MBit nätverkskort
• Windows NT 4 Router:
• Cisco 2600 series Switch:
• Netgear 100 Mbit
7.4 Kontrollprogram för den mobila enheten
Som tidigare nämnts fungerade Tcl/tk GUI applikationen som medföljde Cellular IP
programvaran mindre bra under den FreeBSD version som kördes i testsystem. Förmodligen finns problemet i socketkommunikationen mellan fönsterapplikationen och huvudprogrammet (cipmobile.c). Då tidigare kunskaper om sockets var mindre goda valde vi att programmera ett eget kontrollprogram baserat på IPC-meddelanden7 som betydligt mer erfarenhet fanns av.
För övrigt hade vi en hel del källkod färdig sedan tidigare så det ansågs vara mer tidsmässigt optimalt att göra ett nytt kontrollprogram. Tilläggas kan att denna modifikation gjort det möjligt att köra programmet i rent konsolläge vilket kan anses vara en förbättring.
Kontrollprogrammet använder sig av två trådar, ett huvudprogram som läser in data och skickar meddelanden och en tråd för mottagning av meddelanden. En enkel förklaring till programmets funktioner ges nedan. För fullständig kodlistning se Bilaga 6.
void main()
Main är huvudprogrammet som ser till att allting förutom globala variabler blir initierat på ett korrekt sätt. Huvudprogrammet har även till uppgift att hantera inmatning av tecken via konsolen och att starta upp tråden för mottagning av meddelanden. Funktionen för periodic handoff sköts även i main. När programmet avslutas ställs även originalinställningarna tillbaka för konsolen i denna funktion.
void menu()
Det enda den här funktionen utför är att rensa terminalen och skriva ut menyn. Funktionen anropar även printgwIP().
int sendMsg(int inType)
Funktionen sendMsg skickar meddelanden till programmet för den mobila enheten med typen inType.
void printgwIP()
Då gatewayens IP fås in som en integer krävs en funktion som konverterar till läsbart format.
Det finns redan en färdig funktion för detta men då två trådar använder denna variabel krävs även mutual exclusion i denna funktion. En separat funktion för detta är därför smidigt.
void recvMsg()
RecvMsg är en tråd vars enda uppgift är att ta emot meddelanden från programmet för den mobila enheten. Den enda meddelandetypen som kommer in till den här funktionen är uppdatering av gatewayen. När ett meddelande har tagits emot uppdateras även terminalen med ett anrop till menu()
void set_kbhit()
Stänger av återmatning av tecken till terminalen och ändrar andra lämpliga inställningar i konsolen.
void kbhit()
En funktion som känner av om ett tecken har matats in. Denna funktion tillhandahölls under kursen Processorienterad programmering som leddes av Datapolarna8.
7 Inter Process Communication, Meddelanden mellan processer i Unixmiljö.
8 http://www.datapolarna.se
22 int readch()
Läser in ett tecken om ett tecken finns i inmatat och returnerar dess ASCII-värde. Lämpligen används denna funktion i kombination med kbhit(). Denna funktion är även den
tillhandahållen av Datapolarna.
8 Felsökning
8.1 PrintIpTree Syfte
Problem upptäcktes tidigt med gatewayen då denna inte svarade på icmp-paket (ping). Första teorin var att routing cachen och/eller paging cachen var felaktiga. Dessa kan ses som
gatewayens och basstationernas routingtabell dvs. underlaget för hur dessa ska skicka in och utgående paket. För att kontrollera strukturen på trädet gjordes en enkel funktion för att visa relevanta data i trädets noder. Trädets struktur ser ut som visas i figuren nedan. Varje pil representerar vad pekaren i respektive objekt refererar vidare till.
Undersökta data i trädet
För att skriva ut relevanta data skapades en funktion PrintIpTree9 för att skriva ut en specifik nod i trädet. Funktionen anropas med en pekare till en nod i trädet. De data som är intresanta är ip i Iptree, mac för alla poster i linked_ifmac, name i interface samt wire, name, local_ip, lether_addr, ip och ether_addr i Link.
Resultat
Vid utskrift under körning visade sig alla data stämma så teorin om att trädet skulle vara felaktigt övergavs.
9 Se Bilaga 9 u_long ip
strcut linked_ifmac *lifmac struct Iptree *left
struct Iptree *right struct Iptree
struct interface *itf char mac[6]
struct timeval timer struct linked_ifmac *next struct linked ifmac
char *name int leaf_root pcap_t *pd char *pkt struct Link *link
struct interface struct Link u_short wire char *name u_long local_ip u_char lether_addr[6]
u_long ip
u char ether addr[6]
struct linked ifmac struct interface struct Link
struct Iptree
struct Iptree
struct linked ifmac struct interface struct Link
struct linked ifmac struct interface struct Link Fig 5. visar strukturen i för CellularIPs IP träd
24 8.2 FileDebug
Syfte
Eftersom tidigare test gav korrekta data fick nya vägar sökas för att finna problemet. För att få en bättre översyn över programmets gång utvecklades funktionen FileDebug vars enda syfte är att dumpa text till en fil. Genom att göra ett anrop till FileDebug-funktionen från alla andra funktioner i cipnode.c kunde en bra översyn av hur programmet fungerar redovisas. Denna informationen skulle även kunna utvinnas ur lämplig debugger t.ex gdb men då programmet fungerar dåligt i debugläge på grund av att det behöver processa mycket data under runtime ansågs FileDebug-funktionen som ett lämpligare alternativ. Fullständig kod för funktionen finns i Bilaga 10.
Genom att läsa textfilen FileDebug generade och samtidigt följa källkoden kunde felet med icmp-paketen hittas. Det visade sig att det inte var meningen att gatewayen skulle svara på anrop till sig själv utan endast vidarebefordra in eller utkommande data. För att kunna spänna upp ett fungerande nätverk med denna utgåva av programvaran krävs alltså ytterligare en dator bortom gatewayen. Dock sattes en router upp precis efter gatewayen då detta ger ett bättre och mer lätt konfigurerbart nät.
9 Test
Vid tidiga tester av Cellular IP protokollet användes kommandot ping för att smidigt skicka och ta emot data mellan olika datorer. Implementationen saknar funktionalitet för route- optimazation vilket ställer krav på ett större testlabb än endast en gateway, basstationer och mobil enhet. Routern samt ”Internetdatorn” hade istället kunnat ersättas med en extra mobil enhet vilken man skulle kunna testa emot. Som gatewayen fungerar i nuvarande
implementation kan den bara skicka vidare inkommande paket uppifrån nedåt i
nätverkskedjan. Detta innebär att det var tvunget att inkludera en router i nätverkstopologin för att kunna utföra tester på systemet.
Tester för att verifiera att handoff fungerar genomfördes genom att ladda ner en stor fil från en ftp server på ”Internetdatorn”. Mitt i nerladdningen gjordes sedan en eller flera handoffs, filen kontrollerades efter nerladdningen för att se om den överensstämde med originalet.
9.1 Stresstest med tcpspray
Målet med stresstesterna var att undersöka hur bandbredden förändras då man förflyttar sig mellan basstationer. Vid förflyttning mellan basstationer görs en handoff vilken borde innebära att bandbredden sjunker ju oftare man byter basstation.
För att utföra testerna användes ett program kallat tcpspray. Detta program för FreeBSD fungerar så att det skickar slumpmässig data till en annan dator. Mängden data som skickas och var paketen skall skickas kan specificeras av användaren vid programanropet. Mottagar- sidan sparar inte informationen som tagits emot utan kastar den automatisk. I och med detta möjliggörs att ett oändligt antal tester kan schemaläggas utan risk för att mottagaren får slut på hårddiskplats.
Programmet i grundutförande saknade dock viss funktionalitet som krävdes. Huvudsakligen önskades nedskrivning av resultat till fil eftersom mängden tester som gjordes var så pass stor.
Programkoden var dock öppen och detta tillägg gjordes enkelt.
Ett eget program, vilket användes för att automatisera tcpspray till att skicka stora mängder data upprepade gånger, skrevs även10. Detta program kallas autospray och anropas med ./autospray. Programmet är en vidare utveckling av sender11. Då programmet startas anges (alla tidsangivelser sker i tiondels sekunder): startperioden mellan varje handoff, stegen i tiondels sekunder som perioden skall räknas ner med och till sist antalet repetitioner på varje period.
9.2 Testresultat
Vid testerna testades två saker, hur bandbredden förändrades då tiden mellan handoffs minskade samt tiden det tog för att skicka en viss mängd data då tiden mellan handoffs
10 Se Bilaga 4
11 Se Bilaga 6, Kap 5.2, Kap 7.4
26 minskade. Två olika storlekar på data skickades, först 25MB data och sedan 30MB data. Vid varje handoffperiod skickades datat 10 gånger och ett medelvärde räknades ut.
Grafen nedan visar hur bandbredden påverkades då tiden mellan varje handoff minskade. Som väntat minskar bandbredden ju oftare man gör en handoff. Vid 12 sekunder mellan varje handoff låg bandbredden på 340 kb/sec vilken kan jämföras med 110 kb/sec som bandbredden var vid en sekund mellan varje handoff.
Bandbredd vid skickandet av 30 MB data
0 50 100 150 200 250 300 350 400
12,0 11,0
10,0 9,0 8,0 7,0 6,0 5,0 4,0 3,0 2,0 1,0
sekunder/handoff
kbytes/sekund
Fig. 6. Visar hur bandbredden påverkas av antalet sekunder/handoff
Den här grafen visar antalet sekunder det tog att skicka 30 MB data. Vid 12 sekunder mellan varje handoff tog det ungefär 95 sekunder att skicka datat. Detta kan man jämföra med 273 sekunder som det tog då det endast var en sekund mellan varje handoff.
Antal sekunder för att skicka 30 MB data
0 50 100 150 200 250 300
12,0 11,0
10,0 9,0 8,0 7,0 6,0 5,0 4,0 3,0 2,0 1,0
sekunder/handoff
sekunder
Fig. 7. Visar hur tiden för dataöverföring påverkas av antalet sekunder/handoff
Graferna som visar bandbredden och tiden för att skicka datat vid mätningen då 25MB data skickades ser i stor sett likadana ut och ger med andra ord samma resultat.
Resultat
Som väntat påverkades både tiden och bandbredden negativt av ju kortare tidsperioderna mellan handoffs blev. Anledningen till den försämrade prestandan är att kontrolldata måste skickas vid handoff. Då tiden mellan handoffs minskar används mer av tiden för sådana paket och lämnar alltså mindre utrymme för annat data. Förutom inverkan av kontrollpaket tappas fler paket bort och måste sändas om vid handoff.
9.3 Teoretisk jämförelse mellan Mobile IP och Cellular IP
För att undersöka hur mycket effektivare Cellular IP är i jämförelse med Mobile IP gjordes ett test med ping-meddelanden. Dessa ping-meddelanden simulerade ett meddelande till home agent som skulle ha behövts göras i Mobile IP vid en handoff. Ping kördes under Windows med följande argument: ping –n 50 www.columbia.edu.
Resultatet av testet blev följande:
Minimum = 141ms, Maximum = 201ms, Medel = 172ms
Tiden det tog för ping-meddelandet att komma tillbaks varierade mellan 141 ms och 201 ms vid det specifika testtillfället. Detta kan bero på t.ex. last, vilken väg paketet tog etc.
28 I Cellular IP hade endast kommunikation med en lokal agent behövts göras. Vid testtillfället tog det mindre än 10 ms att göra en ping mot den lokala gatewayen.
Man kan tänka sig ett scenario där en mängd data som skulle ha tagit 100 sekunder att skicka mellan två datorer utan handoffs. Hade man färdats så att man bytte basstation var femte sekund skulle resultatet bli:
Mobile IP:
20 (antalet handoffs) * 172 (antalet ms fördröjning vid en handoff) = 3440 ms = 3.44 s.
Cellular IP:
Fördröjningen är halva ping-tiden.
20 (antalet handoffs) * 2,5 (antalet ms fördröjning vid en handoff som är halva pingtiden) = 50 ms = 0.05 s.
Dvs. hade man använt sig av Mobile IP skulle det tagit 3.39 sekunder längre att skicka datat.
Observera att uträkningarna visar hur det skulle ha sett ut om inga som helst variationer i last etc. hade skett mellan Mobile IP:s home agent och den mobila enheten. Då antalet handoffs / sekund minskar, minskar även skillnaden mellan Mobile IP och Cellular IP.
10 Slutsats
Mycket av tiden under examensarbetet ägnades åt felsökning vilket resulterade i att endast det första delmålet uppnåddes. Resultatet av detta delmål blev en undersökning på hur
tidsperioden mellan handoffs påverkar bandbredd och tid för skickning av en viss mängd data.
Dessa data togs fram med hjälp av Cellular IP programvaran samt egenutvecklad
testprogramvara. För Mobile IP gjordes enbart en teoretiskt test. Testen och den teoretiska undersökningen visade att Cellular IP är överlägset gentemot Mobile IP då perioden mellan handoffs mellan basstationer i samma nät är låg. Anledningen till detta är att den mobila enheten som kör Mobile IP till skillnad mot Cellular IP måste meddela sin home agent vid varje handoff.
30
11 Framtida arbete
Något som skulle vara intressant att jobba vidare med inom Cellular IP området skulle vara att skriva en modul till kärnan som har funktionaliteten som endast stöds på applikationsnivå än så länge. Ett annat intressant område skulle vara att integrera RSVP i Cellular IP. Detta skulle vara bra för trådlös överföring i allmänhet. Vidare skulle det vara önskvärt med optimeringar av Cellular IP t.ex. stöd för route optimization.
12 Referenser
[1] ORINOCO, www.wavelan.com
[2] Cellular IP at Columbia University, http://comet.columbia.edu/cellularip/
[3] Charles E. Perkins, Sun Microsystems, http://computer.org/internet/v2n1/perkins.htm Mobile Networking Through Mobile IP.
Bilaga 1: Cipnode.conf
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% cipnode.conf
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
GW: NO % this will be used at run time not compile time
IF YES, default router's IP address:
IF NO, neighbor, uplink direction: (wire,fxp0,128.59.68.250) leaf neighbours(s): (wireless,wi0)
paging cache: YES if yes the size: 2
route-timeout: 3000 %in milliseconds paging-timeout: 30000 %in milliseconds max number of mobiles in cache: 100
max number of node interfaces: 10
GW IP address: 128.59.68.250
% A neighbor is defined by medium(wire/wireless), the interface name
% on which the neighbor can be reached and the neighbor IP address.
% In the case of a wireless interface the frequency and nwid should be defined.
32
Bilaga 2: Cipnode.conf (gateway mode)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% cipnode.conf
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
GW: YES % this will be used at run time not compile time
IF YES, default router's IP address: (wire, fxp1, 128.59.67.1) IF NO, neighbor, uplink direction:
leaf neighbours(s): (wire, fxp0, 128.59.68.249), (wire, fxp0, 128.59.68.251) % example
paging cache: YES
if yes then size: 1
route-timeout: 30000 %in milliseconds
paging-timeout: 60000 %in milliseconds var 30000 max number of mobiles in cache: 1 %var hundra
max number of node interfaces: 10
GW IP address: 128.59.68.250
% neighbor is defined by medium(wire/wireless), the interface name
% on which the neighbor can be reached and the neighbor IP address.
% In the case of a wireless interface the frequency and nwid should be defined.
Bilaga 3: Cipmobile.conf
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
wireless interface: wi0
mobile's IP address: 128.59.69.71 air interface name: mobile-air
route-update-time: 200 %in milliseconds paging-upate-time: 10000 %in milliseconds acitve-state-timeout: 2000 %in milliseconds handoff: 0 %automatic or based on SNR
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
34
Bilaga 4: autospray.c (stress test med tcpspray)
/****************************************************
* Simple test program for mobile node
* Written by Erik Ljungberg and Joel Fransson 2001 ****************************************************/
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/msg.h>
//#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdio.h>
#include <termios.h>
#include <pthread.h>
#include <string.h>
#include <stdlib.h>
#include "autospray.h"
// functions and globals // our functions
void menu();
void recvMsg();
void printgwIP();
void set_kbhit();
// fuctions once given to us by Datapolarna. Origin before that is unknown int kbhit();
int readch();
void FilePrint(char *inString);
// globals int gwIP=0;
int spray_switch = 1;
pthread_mutex_t *mutex;
// used by kbhit and readch static int peek = -1;
static struct termios orig, changed;
//***************************************************
// main()
// handels setup of thread, mutual exclusion // and use of termial input
//***************************************************
int main(void) {
pid_t child_pid;
struct msqid_ds dummy;
char ascii_digits[10];
char Buffer[100];
int flag=1;
int Count=0;
int ch=0, periodic_switch = 0, index = 0, period = 0, steps = 0, step_switch = 0, loops=0, current_loop=0;
pthread_t recvThread=0;
char buff[10];
// create mutual exclusion
mutex = (pthread_mutex_t*)malloc(sizeof(pthread_mutex_t));
//echo off set_kbhit();
if(mutex && (0 == pthread_create(&recvThread, 0, (void *)recvMsg, 0))) {
while(flag) {
// periodic_switch = 0;
// periodic handoff if(!step_switch) {
for(index = 0; index < 10; index++) ascii_digits[index] = '\0';
printf("Set period (ds)\n");
// echo on
tcsetattr(0, TCSANOW, &orig);
fflush(stdin);
scanf("%s", ascii_digits);
printf("%s (string)\n",ascii_digits);
period = atoi(ascii_digits);
printf("period:%d (int)\n",period);
fflush(stdout);
if(period > 0) {
period *= 100000;
printf("period:%d (int*100000)\n",period);
}
for(index = 0; index < 19; index++) ascii_digits[index] = '\0';
fflush(stdin);
printf("steps (ds)\n");
scanf("%s", ascii_digits);
steps = atoi(ascii_digits);
printf("Number of loops\n");
scanf("%s", ascii_digits);
loops = atoi(ascii_digits);
current_loop=loops;
step_switch = 1;
FilePrint("Testdata\n");
sprintf(Buffer, "Period: %d\n", period);
FilePrint(Buffer);
sprintf(Buffer, "Steps: %d\n", steps);
FilePrint(Buffer);
sprintf(Buffer, "Loops: %d\n\n\n", loops);
FilePrint(Buffer);
FilePrint("nr,period,bytes,tid,bytes/sec\n");
36
}
// scripted if(period > 0) {
if(spray_switch) {
Count++;
sprintf(Buffer, "%d,%d,", Count, period);
FilePrint(Buffer);
if(!periodic_switch) {
periodic_switch = 1;
// period *= 100000;
printf("period:%d \n",period);
} else {
current_loop--;
if(current_loop==0) {
period -= (steps*100000);
printf("ny period:%d\n",period);
current_loop=loops;
} }
myId = ftok("/", SPRAYER_MSG);
msgId = msgget(myId, 0666 | IPC_CREAT);
msgsnd(msgId, (void *)buff, sizeof(char)*10, IPC_NOWAIT);
spray_switch = 0;
}
if(period < 500000) {
flag=0;
printf("completed 1");
} } else {
step_switch = 0;
periodic_switch = 0;
flag=0;
printf("completed 2");
}
if(periodic_switch) {
printf("Sendmessage\n");
sendMsg(1);
usleep(period);
} else
usleep(2000);
}
pthread_detach(recvThread);
} else
printf("Unable to create thread or mutual exclusion failed!!\n");
// restore echoing in terminal tcsetattr(0, TCSANOW, &orig);
printf("bye bye\n");
return 1;
}
//***************************************************
// sendMsg()
// handles outgoing messages ( -> cipmobile )
//***************************************************
int sendMsg(int inType) {
int msgFlag = 0;
struct msgStruct Sender;
myId = ftok("/", SENDER_MSG);
msgId = msgget(myId, 0666 | IPC_CREAT);
// set type of message Sender.msgType = inType;
// send message
while((msgFlag = msgsnd(msgId, (void *)&Sender, sizeof(struct msgStruct), IPC_NOWAIT)) == -1)
{
// wait a while if message could not be transmitted usleep(1000);
}
// no point returning this but...
return msgFlag;
}
//***************************************************
// recvMsg()
// handles incomming messages ( <- cipmobile ) and // updates menu in terminal
//***************************************************
void recvMsg() {
char buff[200];
struct msgStruct *RecvStruct;
int msgFlag = 0;
key_t mytId = ftok("/", CELLULAR_MSG);
int msgtId = msgget(mytId, 0666 | IPC_CREAT);
RecvStruct = (struct msgStruct *)buff;
while(1) {
msgFlag = msgrcv(msgtId, (void *)RecvStruct, sizeof(struct msgStruct), 0, IPC_NOWAIT);
38
if(msgFlag != -1) {
pthread_mutex_lock(mutex);
if(RecvStruct->msgType != FROM_SPRAY) {
gwIP = (RecvStruct->gwIP);
} else {
spray_switch = 1;
printf("msg recieved, spray complete\n");
}
pthread_mutex_unlock(mutex);
// menu();
}
usleep(1000);
} }
//***************************************************
// printgwIP()
// prints current gateway
//***************************************************
void printgwIP() {
struct in_addr t_addr;
pthread_mutex_lock(mutex);
t_addr.s_addr = gwIP;
printf("%s", inet_ntoa(t_addr));
pthread_mutex_unlock(mutex);
}
//***************************************************
// kbhit()
// checks if any key is pressed
//***************************************************
int kbhit() {
char ch;
int nread;
if(peek != -1) return 1;
changed.c_cc[VMIN]=0;
tcsetattr(0, TCSANOW, &changed);
nread = read(0, &ch, 1);
changed.c_cc[VMIN]=1;
tcsetattr(0, TCSANOW, &changed);
if(nread == 1) {
peek = ch;
return 1;
}
return 0;
}
//***************************************************
// readch()
// reads a character if any
//***************************************************
int readch() {
char ch;
if (peek != -1) {
ch = peek;
peek = -1;
return ch;
}
read(0, &ch, 1);
return ch;
}
//***************************************************
// set_kbhit()
// turns of terminal echo etc....
//***************************************************
void set_kbhit() {
tcgetattr(0, &orig);
changed = orig;
changed.c_lflag &= ~ICANON;
changed.c_lflag &= ~ECHO;
changed.c_lflag &= ~ISIG;
changed.c_cc[VMIN] = 1;
changed.c_cc[VTIME] = 0;
tcsetattr(0, TCSANOW, &changed);
}
void FilePrint(char *inString) {
FILE *outfile;
if(inString != NULL) {
if(outfile = fopen("/root/tcpspray/testdata.txt", "a")) {
fwrite(inString, 1, strlen(inString), outfile);
fclose(outfile);
} } }
