Paketförstörare Implementerad på XESS XSV800 labbkort

Transkript

1 aketförstörare Implementerad på XESS XSV800 labbkort rojektrapport i kursen SMD106 av Markus Finér ( ) Urban Classon ( )

2 Abstrakt När man tar fram och utvecklar nya kommunikationsprotokoll är det nödvändigt att testa hur känsliga dessa är för fel som lätt kan uppstå till exempel vid kommunikation i trådlösa nätverk. Det är normalt väldigt svårt att skapa fel på bit-nivå i ett Ethernet paket, normalt så slänger mottagaren bort dessa paket då de kommer fram eftersom CRC inte stämmer på paketet. Vår paketförstörare tar emot ett paket som den mönstermatchar mot en bitfil som bestämmer var man ska introducera felen, vi räknar därefter om checksumman på alla paket så att mottagaren sedan kan ta emot dessa utan problem. Man kan även sätta valfri destination adress på paketen. Vår paketförstörare ska kunna kopplas in mellan två datorer som en svart låda och arbeta helt transparent.

3 Innehållsförteckning 1. Inledning 4 2. Teoretisk bakgrund 2.1 Ethernet paket CRC algoritmen Vår konstruktion 3.1 Översikt aketförstöraren 9 4. Analys av vår paketförstörare och arbetet Sammanfattning Källförteckning Appendix A 13-14

4 Inledning Vårt projekt har gått ut på att göra en paketförstörare som ska kunna införa fel på bitnivå i ett ethernetpaket. Målet är att kunna testa hur nya protokoll beter sig när man inför fel i kommunikationsflödet. Målsättningen kan till exempel vara att försöka korrigera paketen eller helt enkelt släppa genom dem och låta någon applikation ta hand om dem. Om det som överförs är exempelvis en video eller ljudström kan man ofta tolerera en viss mängd fel utan at detta försämrar kvaliteten orimligt mycket. Vi har koncentrerat oss på det vanliga ethernetprotokollet men det går utan allt för stora ändringar att göra om vår paketförstörare så att den funkar med andra protokoll som till exempel det väldigt vanliga IEEE b som används i de flesta trådlösa ethernetnät. Vår paketförstörare mönstermatchar paketen mot en bitfil och inför fel på bit X i det data som skickas om bit X i bitfilen är en etta. Vår bitfil kan vara maximalt bytes stor, när man gått genom hela bitfilen börjar man från början på densamma. Ett problem som ganska snart dök upp var det faktum att XSV labkortet bara har en ethernetport. Vi måste alltså ta emot och skicka data på samma port. Den smidigaste och mest transparenta lösningen på detta skulle ha varit att använda en switch med stöd för Vlan så att man kunde sätta sändare och paketförstörare på ett Vlan och mottagaren på ett annat Vlan. Dock fanns det inte tillgång till en sådan switch under projektet så vi fick hitta en annan lösning vilket blev att lägga till en falsk macaddress för mottagaren i arptabellen på sändardatorn. I och med detta var det nu möjligt att skicka felfritt data till mottagaren som dock har fel macaddress och alltså inte tas emot av mottagaren. Detta paket tas dock emot av vår paketförstörare vilken lägger till önskade fel i paketet, ändrar till rätt macaddress och räknar om checksumman för hela paketet I denna rapport går vi genom de teoretiska grunderna bakom ethernetprotokollet. Vi redovisar en detaljerad beskrivning av vårt arbete med schematiska bilder och beskrivningar på de olika komponenterna i designen.

5 Kapitel 2 - Teoretisk bakgrund 2.1 Ethernet paket Ethernet är ett paketbaserat protokoll, i detta projekt bryter vi oss in i paketen och behandlar dem på bitnivå för att kunna införa fel i vilken som helst av de olika delarna av paketet. I figur 1 nedan ser ni hur ett ethernetpaket är uppbyggt. Lägg noga märke till i vilken ordning de olika delarna skickas. Nedan följer en mer ingående beskrivning av de olika delarna. Figur 1: Ett ethernetpaket med sändordningen för de olika fälten reamble Varje enhet i ett ethernetnätverk har sin egen oscillator, dessa går vanligen i 2,5Mhz (10Mbit) eller 25Mhz (100Mbit). reamble inleder ethernetpaketet och dess uppgift är att synkronisera klockorna på sändare och mottagare så att man sedan ska kunna skicka data synkront mellan dessa. reamble består av 62 bitar med alternerande ettor och nollor som sedan avslutas med två ettor, De två sista ettorna signalerar att preamblen är slut och att destinationaddressfältet börjar. När paketet når mottagaren filtrerar mottagarens MAC bort preamblen som inte skickas vidare. Destination adress (DA) Detta fält innehåller destinationsadressen för paketet. Om den mottagande datorn upptäcker att innehållet i DA överensstämmer med den adress som noden i fråga har så tas paketet emot. En destinationsadress är 48 bitar lång, även denna skickas normalt rakt genom vår paketförstörare om man inte vill införa fel. Som man kan se i figur 1 så är bitordningen omvänd, DA består av två olika delar. Första delen som börjar på minst signifikant bit och tar upp första halvan (24-bitar) är vad som kallas Organizational Unique Identifier eller OUI. Detta är en 24-bitars identifierare som talar om vem som tillverkat enheten, varje tillverkare får sin egen OUI från IEEE. Nästa fält är också 24-bitar och här anges en identiteskod som tillverkaren har hittat på och som är olika mellan olika enheter. Varje enhet i ett nätverk få på detta sätt en unik adress kallad MAC-adress, denna lagras på varje nätverkskort i ett ROM.

6 Source adress (SA) Detta fält innehåller adressen på den MAC som skickade paketet i fråga. Uppbyggnaden är identisk med det den tidigare nämnda DA. Type Detta fält anger vilken typ paketet är, det kan till exempel vara 0x0800 som är I (Internet protocol). Fältet är 16 bitar och även detta fält skickar vi rakt genom vår paketförstörare om vi inte inför något fel i det. Bitordningen är omvänd Data Detta fält innehåller den data, payloaden, som man vill skicka i sitt paket. Storleken är minst 46 bytes och maximalt 1500 bytes. recis som med föregående fält skickas detta rakt genom vår paketförstörare om vi inte vill införa något fel. Bitordningen är omvänd Frame Check Sequence (FCS) Detta fält är 32 bitar långt och innehåller en beräknad CRC (Cyclic Redundancy Check) för hela paketet. När man räknar fram CRC använder man sig av DA, SA, type och data. Vi går in lite djupare på CRC i kapitel 2.2 då detta är den beståndsdelen i pakten där vi faktiskt gjort lite större förändringar. Checksumman räknas fram av sändaren och när den når mottagaren så gör denna en kontroll och visar det sig då att checksumman inte stämmer mot innehållet så slänger mottagaren bort det felaktiga paketet. 2.2 Cyclic Redundancy Check (CRC) algoritm Meningen med att använda en feldetekteringsteknik såsom CRC är att mottagaren ska kunna avgöra om meddelandet har blivit förändrat på vägen. Detta är extra viktigt när man till exempel skickar data över trådlösa länkar där man kan få väldigt kraftiga störningar. För att göra detta räknar sändaren fram en checksumma med själva meddelandet som indata till en given funktion. När sedan mottagaren får meddelandet kan denna lätt kontrollera om samma checksumma fås om funktionen ytligare en gång körs med meddelandet som indata. Vi har inte gjort någon större utredning om hur själva CRC-32 algoritmen fungerar på ett matematiskt plan men här är i alla fall en kort grundläggande beskrivning. Algoritmen behandlar bitströmmarna som binära polynom. Sändaren genererar en FCS utifrån det paket som ska skickas. FCS som läggs till paketet genereras så att hela paketet med CRC är jämnt delbart med ett fördefinierat polynom som kallas CRC-32 polynomet. Så här ser CRC-32 polynomet ut: x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x Man kan använda många olika polynom, längre polynom ger givetvis bättre säkerhet men ger också längre restvärden. Här är några enkla formler för att beskriva hur CRC fungerar. M aket utan FCS, längden är m bitar F Den framräknade FCS som ska läggas till M, längden är n bitar T aketet med FCS, längden är m+n bitar Det fördefinierade CRC polynomet, längden är n+1 bitar Grundidén bakom CRC-algoritmen är att den FCS man genererar ska göra att T/ blir noll. T = M * x n + F

7 Ovan har vi skiftat n bitar till vänster och lagt F till T. Vi vill att det paket vi ska sända, alltså T, ska vara jämt delbart med det fördefinierade CRC polynomet. För att lösa detta måste vi hitta en lämpligt FCS (F) för varje paket utan FCS (M). Om vi delar M * x n med får vi: M * x n = Q + R Man får Q som är en jämn kvot och R som är en rest, dvs. vår FCS som vi var ute efter! (F=R) T = M * x n + R Slutligen ett litet bevis på att ett paket med denna FCS gör att T alltid är jämt delbart med : T = n M * x + R = M * x n + R = Q + R + R R + R = Q + Eftersom två lika binära tal adderade med varandra (R+R) alltid ger noll (1+1=0 samt 0+0=0) Så får vi att följande gäller T = Q 2.3 Implementation av CRC algoritm i hårdvara Det är nödvändigt att CRC algoritmen utförs väldigt snabbt så att man inte får någon onödig latens där man får sitta och vänta. Algoritmen går att implementera väldigt effektivt i hårdvara, här är ett exempel på hur man väldigt enkelt och effektivt löser det. I detta exempel visar vi hur hårdvaran ser ut till CRC polynomet ( x) = x + x + x + 1. Figur 2: Ett exempel på en enkel hårdvaruimplementation av CRC algoritmen Några saker man måste tänka på när man använder CRC-32 i ett ethernetpaket: CRC-32 initieras till FFFFFFFF Det slutgiltiga 32-bitars resultatet ska inverteras, sedan ska alla bitarna reflekteras.

8 Kapitel 3 - Vår konstruktion 3.1 Översikt Till att lösa uppgiften att förstöra paket använder vi ett utvecklingskort från XESS, XSV-800. Hjärtat i detta är en Virtex FGA som sitter på ett kort som har alla möjliga I/O portar. Figur 3: En schematisk skiss över XESS XSV-800 utvecklingskort. För att lösa uppgiften använder vi oss av parallellporten för att programmera kortets FGA. Filen som innehåller bitmönster för felgenerering och ny destination adress förs sen över via serieporten. aketen plockas givetvis in via nätverksinterfacet. För att programmera kortets FGA använder vi XSLOAD. Filen med bitmönster och destination adress skickas över med valfritt terminalprogram. I denna fil motsvarar en nolla att en bit i ett paket släpps genom som den är och en etta att biten inverteras. Denna fil blir väldigt stor då den vanligen innehåller väldigt många nollor. Man använder därför ett program för att komprimera bitfilen så den får plats i den bytes som finns tillgängligt. Hur paketen hanteras behandlas i kapitel 3.2. Själva testbänken består av en sändardator och en mottagardator som är kopplade till en switch, på switchens uplink sitter vår XSV-100 inkopplad. å sändaren måste man editera arptabellen och ange en falsk MAC adress för mottagaren, vi har använt oss av adressen 11:22.33:44:55:66. När man då skickar data till mottagaren så kommer denna inte att ta emot dessa paket eftersom destinationsadressen inte stämmer. Däremot tar vår paketförstörare emot paketen och ändrar destination adress till den man angett i filen med destination adress och felmönster. Detta går även att göra i applikationslagret genom att ändra i drivrutinerna till mottagrens nätverkskort så att denna tar emot paket med fel DA. Vi har dock inte provat denna lösning då sättet vi valt att lösa det på känns mer transparent och generellt.

9 3.2 aketförstöraren Nu ska vi försöka beskriva mer detaljerat hur vår paketförstörare är uppbyggd. Receiver FIFO CRC Remover Destination changer Frame corrupter Control logic 2,5Mhz Control logic 20Mhz Interface to block RAM Transmitter FIFO CRC calculator Figur 4: En schematisk skiss över vår paketförstörare Recieve FIFO tar in data från ethernet interfacet som har en klockdomän som går i 2,5Mhz i ett 10Mbits nätverk. Själva processen är klockad i 20Mhz och nästa steg är att ta bort CRC från paketet i vår CRC remover som helt enkelt tar bort de sista 32 bitarna i av det paket som skickas genom. Nästa steg är att skicka paket till vår destination changer där vi ändrar på destination adress till den som angetts i den filen man skickar till kortet. Detta bör vara mottagarens verkliga MAC adress för att det skickade paketen ska komma fram. Nästa steg är att skicka bitströmmen till vår frame corrupter som mönstermatchar det data som kommer in till den mot bitfilen i minnet. En nolla i bitfilen släpper genom en bit i paketet utan förändring men en etta i bitfilen inför ett fel och inverterar en bit i paketet. Nästa steg i processen är att räkna fram en ny kontrollsumma i vår CRC calculator och lägga det till slutet på vårt nya paket. Därefter skickas paketet ut på vårt ethernet interface igen via transmitter FIFO.

10 Kapitel 4 Analys av vår paketförstörare och arbetet Vi upplevde ganska tidigt att det var en stor nackdel att exprimentkortet inte hade två ethernet interface. Vi bollade länge med problemet hur detta skulle lösas och det råd vi fick var att använda en switch med stöd för vlan som på så sätt kunde segmentera nätverket mellan mottagare, sändare och paketförstörare så att man skulle kunna styra trafiken där mellan. Detta hade varit en väldigt transparent lösning men tyvärr fanns det ingen vlan switch att tillgå. Efter att ha funderat, diskuterat och läst på lite granna kom vi fram till att lösning skulle få bli att manuellt editera arptabellen på sändardatorn på detta sätt kan man skicka paket till mottagaren med en falsk destination som rättas till i paketförstöraren och sen skickas ut. Kravspecen för projektet har varit lite lös och ett problem för oss har varit att vi till en början saknade någon djupare kunskap i hur ethernet fungerar i ett större perspektiv vilket man dock snabbt fått lära sig. I det stora hela har dock arbetet gått bra och vi tror och hoppas att resultatet ska vara användbart. Om vi ska försöka se några begränsningar och möjliga saker att förbättra i vår paketförstörare så blir det följande saker som man skulle kunna förbättra: Justera fördröjningen av paketen genom paketförstöraren, lämpligt intervall är 0-50ms. Man kan antingen lägga denna buffert i själva FGA n, vilket då troligen kräver en större FGA men minnet blir väldigt snabbt. Alternativet är att det SRAM som finns på kortet, vilket är det mest realistiska. Minnet på kortet är dock relativt långsamt och minsta fördröjning skulle uppskattningsvis hamna runt 5ms. Skulle paketförstöraren används i verkligheten skulle det bästa sättet att göra detta vara via en Vlan switch. Man skulle då behöva lägga in stöd för att sätta Vlan taggar på alla paket. Man slipper även ändra på destinationadress och allt skulle funka smidigare. Absolut smidigast skulle det givetvis vara att ha en bättre anpassad hårdvara med minst två Ethernet interface så man kan ta in data på ett och skicka ut på det andra. Då skulle designen kunna fungera som en helt transparent blackbox.

11 Kapitel 5 Sammanfattning Sammanfattningsvis måste vi säga att detta har varit ett väldigt intressant arbete. Det stora problemet var från början att specifikationerna för projektet var väldigt lösa. Ansvaret för handledning har även det varit väldigt oklart då det hamnat nånstans mellan datakom och datateknik. Ingen på datateknik har haft koll på hur vi ska lösa alla problem som uppstått då det bara finns ett ethernet interface och även alla andra problem runt själva ethernet har varit svårt att få hjälp med. Önskemål och nya saker som måste finns med har hela tiden kommit fram från datakom vilket kan medföra stora problem när en design redan är påbörjad. Oklarheterna runt hur själva testbänken med sändare och mottager skulle se ut gjorde att den första designen vi gjorde fick skrotas nästan helt och hållet. Vi hade stora problem med att få XSV kortets SRAM minne att fungera tillfredställande. I nästa design kan vi nog bara skylla på oss själva då vi gjorde för mycket utan att felsöka och fick en ett antal fel som samverkade vilket gjorde felsökningen väldigt svår och tidsödande. Den tredje och slutgiltiga designen gjorde som man bör göra, väldigt modulär med byggblock som först testades nog var för sig innan som användes i designen där vi även gjorde testbänkar efter varje tillagd modul. Desigen fungerar och fyller den ursprungliga projektspecifikationen och även en del av de features vi fått förslag på under projektets gång. Någon variabel fördröjning av paketen har vi inte lyckats med pga problem med XSV kortets SRAM minne. Som tidigare nämnts blir inte heller användandet av paketförstöraren helt transparent för användaren men detta är den bästa möjliga lösning vi kommit fram till.

12 Källförteckning Smith, Michael John Sebastian (2001), Application-Specific Integrated Circuits, 9th printing, Addison-Wesley, ISBN Mark Zwolinski (2000), Digital System Design and VHDL, University of Southampton, ISBN Lecture slides and lab M from SMD098, 2001,

13 Appendix A Användarmanual för aketförstöraren Inledning aketförstöraren arbetar transparent med att införa fel i paketen på bitnivå. aketet kommer in, fel genereras och CRC-32 räknas om på det nya paketet. Implementationen är gjord på ett XESS XCV800 labbkort. Felen som ska införas representeras av en bit-fil, där en 1:a visar att ett fel ska införas. Filen som innehåller fel överförs via serieporten, med 8 bitars ord och bauds hastighet. Bitfilen För att spara minne har vi valt att komprimera bit-filen. Algoritmen är enkel och en fil med många fel kommer att resultera i en stor bit-fil. rogram som komprimerar filerna finns bifogat i zip-filen med alla filer och heter comp Minnet i FGAn är 9 bitar brett, 8 bitar för data och en bit för att berätta om det är fel som ska genereras eller inte. Ska inget fel genereras kommer den första biten (MSB) vara 0 och följande 8 bitar visar hur många bytes som ska passera utan att fel genereras. Ska däremot fel genereras kommer MSB att vara 1 och följande data är felet som ska bli. För att konvertera filen med bitfel (.cmp) används först programmet xxd (som finns installerat i jota-labbet) enligt följande: # xxd ps [infil] > [utfil] När detta är gjort används den resulterande utfilen som infil till comp och en ny utfil genereras: #./comp [infil] > [utfil] Den resulterande filen är en ASCII-hexfil som ska konverteras till en binärfil. Detta göres enklast genom att klippa in hela resultatet i ett program som heter winhex. Eftersom vår paketförstörare även ändrar destinationsadress till det mottagande nätverkskortet ska mottagarens MAC-adress sparas som de första 12 byten i bitfilen. En MAC-adress är bara 6 byte lång, men eftersom minnet är 9 bitar brett kommer MSB på varje rad vara LSB från följande byte i bitfilen, vilket innebär att man måste lägga en 0-byte mellan varje byte i MACadressen. Om interfacet har MAC-adressen 12:34:56:78:90:12 ska de första 12 byten i bitfilen vara: Lägg märke till ordningen i nibblarna och glöm inte den avslutande 0-byten. Konfigurera XCV800 brädet En FGA består av programmerbar logik och kommer inte ihåg designen mellan strömavbrott. Detta innebär att varje gång man slår på strömmen måste man ladda om designfilen. Denna heter top.bit och finns bifogad i zip-filen.

14 För att ladda över bitfilen gör man följande: Starta programmet GXLOAD, en tom ruta kommer att dyka upp (flera om den senaste versionen körs). Ta bitfilen och drag-and-drop ner i den tomma rutan (FGA/CLD rutan i senaste versionen). Filen kommer då att laddas över på en gång. Kom ihåg att strömmen måste vara på när man göra detta. När programmet berättar att brädan är konfigurerad så kan man avsluta GXLOAD. Ladda över filen med bit-fel För att ladda över filen behövs ett program som kan skicka data över serieporten. Vi rekommenderar att terracom används då det är detta program som använts under utvecklingen och som vi vet fungerar. När du startat programmet, dubbelkolla så att inställningarna för serieporten är följande: Hastighet: baud aritet: Ingen Stopbits: 1 Byte-längd: 8 För att skicka filen går du till File -> Transfer file I dialogrutan som dyker upp väljer man sin fil och skickar den. Glöm inte att det är en binär fil som man skickar, så den rutan måste vara förkryssad. Starta om, eller byta bitfil För att starta om paketförstöraren från början av felfilen trycker man på Sw2 (nummer två av de små knapparna i ena hörnet av xess-brädet). När man vill ladda en ny bitfil måste man först trycka på Sw1, sedan ladda över bitfilen. Var noga med att det inte kommer några paket till brädet medan du ladda filen, detta skulle ändra adresspekaren och göra så att filen kommer in i minnet på FGAn på fel sätt. Kört fast? Om problem skulle uppstå, eller om det finns frågor om designen, tveka inte att höra av er till marfin-@student.luth.se eller urbcla-6@student.luth.se vi svarar i mån av tid. Lycka till!