Adatkapcsolati réteg szolgálatai

Adatkapcsolati réteg szolgálatai

Összeállította:

dr. Katona László adjunktus Irányítástechnika és Informatika Tanszék

BME Számítógéphálózatok jegyzet. Csak belső használatra. Minden jog fenn tartva. Copyright 2000, BME Irányítástechnika és Informatika Tanszék

Adatkapcsolati réteg

1. 1.1.

23

ÁLTALÁNOS SZÁMÍTÓGÉPHÁLÓZATI ALAPISMERETEK

Az OSI hivatkozási modell

A hálózat összekapcsolt csomópontok (node-ok) rendszere, melyben a csomópontok egymásnak különbözô céllal adatokat, információkat küldenek. A Nemzetközi Szabványügyi Hivatal (ISO) definiált egy hivatkozási modellt (Open Systems Interconnection Reference Model, OSI), amely a csomópontok közötti kommunikáció folyamatát írja le. Az OSI modellben hét réteget definiáltak. Minden egyes réteg szolgáltatásokat biztosít a felette levô magasabb szintû réteg felé. A fizikai réteg feladata közvetlenül az adatátviteli közeg kezelése, az átvitel tényleges megvalósítása. Az adatkapcsolati réteg egyrészt a közeghozzáféréssel foglalkozik (Ethernet, token-bus, token-ring), másrészt a felette levô hálózati réteg számára biztosítja egy adatcsomagnak két csomópont közötti megbízható, hibamentes átvitelét. A hálózati réteg feladata a csomagoknak a forrás csomóponttól a cél csomópontig való eljuttatása. Egy csomag az útja során több csomópontot is érinthet, mire eléri a cél csomópontot. Amíg az adatkapcsolati réteg csak egy vonal két vége közötti adatcsomag átvitelét végzi, addig a hálózati réteg két végpont közötti (end-to-end) átvitellel foglalkozik.

2. 2.1.

SPECIÁLIS HÁLÓZATI ISMERETEK

A hivatkozási modell rétegei és NetWare megfelelôi

OSI model Application Presentation Session Transport Network Data link Physical

Sequenced Packet Exchange (SPX) 802.x Protocols

NetWare Layers Application specific DOS NetWare Requester (NCP)

NetBIOS

Internetwork Packet Exhange (IPX) Open Link Other Network Interface Protocols


24

2.2.


Az adatkapcsolati réteg

Az adatkapcsolati réteg feladata, hogy a zajos vonalakat átviteli hibáktól mentes kommunikációs csatornákká alakítsa át a hálózati réteg számára. Ennek érdekében az adatokat keretekké tördeli, amelyeket annyiszor küld el, amennyiszer csak szükséges ahhoz, hogy hibátlanul megérkezzenek a vevôhöz. A gyors adókhoz képest lassú vevôk adattal való elárasztását forgalomszabályozással (pl. forgóablakos protokoll) küszöböli ki. Az IEEE 802 LAN szabványokban az adatkapcsolati réteget két szintre (alrétegre) bontották. Az alsó szint a közeghozzáférési alréteg (Media Access Control, MAC), melynek három változata van: CSMA/CD (802.3), token bus (802.4), token ring (802.5). A felsô szint, a 802.2-es adatkapcsolati protokoll (Logical Link Control, LLC) mindhárom alsó szintre közös. Az IEEE 802.3 szabvány a DIX Ethernet szabványra épül, ezért (bár nem egészen helyesen) a legtöbb CSMA/CD alpon mûködô hálózatot Ethernet hálózatnak nevezik.

2.2.1. Ethernet keretformátumok a NetWare hálózatokban Az Ethernet alapú NetWare v3.x hálózatokban négyféle keretformátumot használnak: • Ethernet 802.3 (802.3 Raw) • Ethernet II • Ethernet 802.2 • Ethernet SNAP (Subnetwork Access Protocol) Az adatkapcsolati réteg felett levô magasabb szintû protokollok nem mindegyike tudja az összes keretformátumot használni, ezért a használt keretformátumot azok függvényében kell beállítani. Az egyes felsôbb protokollok a következô keretformátumokat tudják kezelni: Protokoll IPX/SPX IPX/SPX, TCP/IP, Apple Talk Phase I IPX/SPX, FTAM IPX/SPX, TCP/IP, Apple Talk Phase II

Keretformátum Ethernet 802.3 Ethernet II Ethernet 802.2 Ethernet SNAP

(A munkaállomásokon ODI (Open Data Link Interface) driver esetén a használt keretformátumot a NET.CFG file-ban kell beállítani.)

2.2.2. A keretformátumok ismertetése Az Ethernet alapú hálózatokon minden egyes keret a keretformátumtól függetlenül egy 8 byte hosszúságú elôhanggal (preamble) kezdôdik. Ez a vevô állomás szinkronizációjához szükséges és nem tekintik a keret részének. BME Számítógéphálózatok jegyzet. Csak belső használatra. Minden jog fenn tartva. Copyright 2000, BME Irányítástechnika és Informatika Tanszék


25

Az elôhang 7 byte-ban 10101010 értéket tartalmaz, majd a nyolcadik byte-ban (Start Frame Delimiter) az utolsó két bit 1-es (10101011). Ez jelzi a keret kezdetét. Szintén a keretformátumtól függetlenül minden Ethernet keret egy Frame Check Sequence (FCS) nevû négy byte hosszúságú ellenôrzô mezôvel fejezôdik be. Ez tartalmazza az elôhangot kivéve a keret teljes tartalmára számított CRC értéket. 2.2.2.1.

Ethernet 802.3

Egészen a NetWare V3.11 rendszerig, beleértve azt is, ez a keretformátum volt a NetWare rendszerek default formátuma. Ezt a keretformátumot egyébként csak a NetWare IPX/SPX protokollja használja. DestinationAddress SourceAddress FrameLength Data

802.3 Header FF

FF

Protocol Header (IPX only)

Information

Destination Address A cél csomópont hardware címe. A 0xffffffffffff broadcast (üzenetszórás) címet jelent. Source Address A forrás csomópont hardware címe. A mezônek 0xffffffffffff (broadcast) értéke nem lehet. Length Két byte hosszúságú mezô, és a keret adatbyte-jainak (a magasabb szintû réteg adatai) számát tartalmazza. Ennek az értéknek 46 és 1500 között kell lennie. Data Az Ethernet 802.3 keretformátumot csak a NetWare IPX/SPX protokollja használja, így a keret adattartalma IPX csomag. Az érvényes legkisebb Ethernet keret hossza 64 byte, ezért legalább 46 byte adatnak kell itt lennie. Ha az IPX csomag 46 bytenál rövidebb, ki kell égészíteni 46 byte-ra. Egy Ethernet 802.3 keret teljes hossza: Destination Address: Source Address: Length: Data:

6 byte 6 byte 2 byte 46-1500 byte


26


FCS: 4 byte _____________________________ Minimális keret méret: 64 byte Maximális keret méret: 1518 byte 2.2.2.2. Ethernet 802.2 Az Ethernet 802.2 keretformátum a 802.3 bôvített változata. Tartalmazza az adatkapcsolati réteg logikai szintjéhez (LLC) tartozó mezôket is. DestinationAddress SourceAddress FrameLength DSAP SSAP Control Byte 1 Control Byte 2 Data

802.3 Header

802.2 Header


Information

A 802.2 keretformátumban a 802.3 formátumhoz képest három új mezô van. Az azonos mezôk jelentését itt nem részletezzük újra, csak az új mezôkét. Destination Service Access Point (DSAP) A cél adatkapcsolati rétege logikai szintjének szolgálat elérési pontját jelzi. NetWare IPX/SPX csomagok esetén értéke mindig 0xE0. Source Service Access Point (SSAP) A forrás adatkapcsolati rétege logikai szintjének szolgálat elérési pontját jelzi. NetWare IPX/SPX csomagok esetén értéke mindig 0xE0. Control Field Hossza a felsôbb protokolltól függôen egy vagy két byte. NetWare IPX/SPX csomagok esetén egy darab control byte van, és annak értéke mindig 0x03. Ez azt jelenti, hogy az LLC szint összeköttetés nélküli szolgálatot biztosít. Az Ethernet 802.2 keretek hossza is 64 és 1518 byte között lehet. A DSAP, SSAP és Control byte a 802.3 keret szerint annak adatterületén helyezkedik el.


Adatkapcsolati réteg 2.2.2.3.

27

Ethernet SNAP

Az Ethernet SNAP keretformátum a 802.2 formátumból származik.

DestinationAddress SourceAddress FrameLength DSAP SSAP Control ProtocolIndentification Data

802.3 Header AA AA

SNAP Header

03


Information

Ennél a keretformátumnál is csak az elôzô keretformátumhoz képest új, illetve más tartalmú mezôk jelentését részletezzük. Az Ethernet SNAP keretformátumban a DSAP és az SSAP mezôk tartalma mindig 0xAA. Ez jelzi, hogy a keret SNAP formátumú. A SNAP keretekben 1 byte Control mezô van, értéke mindig 0x03. Protocol Identification Field Ez az öt byte hosszúságú mezô két alrészbôl áll. Az elsô alrész három byte hosszúságú és organizációs kódnak hívják (Organization Code). NetWare IPX/SPX csomagok esetén értéke mindig 0x000000. A második alrész kettô byte hosszú és Ethernet típus a neve (Ethernet Type Field). A felsôbb szintû protokoll azonosítására szolgál. Az alábbi táblázatban az Ethernet típus mezô értékét láthatjuk néhány hálózati protokollra: Protokoll Ethernet típus mezô IP (Internet Protocol) 0x0800 ARP (Address Resolution Protocol) 0x0806 Apple Talk 0x809B NetWare IPX/SPX 0x8137 BME Számítógéphálózatok jegyzet. Csak belső használatra. Minden jog fenn tartva. Copyright 2000, BME Irányítástechnika és Informatika Tanszék

28


2.2.2.4.

Ethernet II

Az Ethernet II keretformátum alapvetôen abban különbözik a 802.3 formátumtól, hogy a Source Address mezô után nem a keret hosszát, hanem egy típus mezôt tartalmaz. DestinationAddress SourceAddress Ethernet II FrameType Data Protocol Header

Information

Frame Type Értéke az elôzô táblázat szerint a felsôbb szintû protokolloktól függ. Bár az Ethernet II keretek a hosszukra vonatkozó információt nem tartalmazzák, a keretek teljes hossza ennél a formátumnál is 64 és 1518 byte között lehet.

2.2.3. Az LLC szint Az adatkapcsolati réteg LLC szintje a hálózati réteg számára összeköttetés nélküli és összeköttetés alapú szolgálatot biztosíthat. Összeköttetésmentes szolgálat esetén az adatkapcsolati réteg a felsô szint felôl érkezô csomagot nyugtára való várakozás nélkül egyszerûen elküldi a cél felé. Összeköttetés alapú szolgálat esetén viszont elôször összeköttetést kell létesíteni a forrás és a cél között, majd ezt az összeköttetést használva a hálózati réteg csomagjai sorrendhelyesen és garantáltan átvihetôk a címzettnek.

2.2.4. A gyakorlat A gyakorlat során az adatkapcsolati rétegnél a közeghozzáférési alréteget vizsgáljuk egy hálózat monitorozó program segítségével. A program kezelési leírása a 4.1. pontnál, a gyakorlati feladat pedig a 4.2. pontnál található.



2.3.

29

Hálózati réteg a NetWare környezetben, IPX

A Netware környezetben az IPX biztosítja a hálózati réteg szintû szolgáltatásokat. A munkaállomások és a file szerver közötti kommunikáció az IPX-en keresztül történik. Az IPX ezen felül a file szervertôl függtelenül peer-to-peer jellegû (két vagy több munkaállomás közötti) kommunikációt is lehetôvé tesz, valamint broadcast üzenetek is továbbíthatók vele.

2.3.1. Csomagok, IPX címzés A csomópontok között az információ egy NetWare hálózatban adatcsomagok (packet) formájában kerül továbbításra. Egy csomag tartalmazza az átviendô adatokat és tartalmaz vezérlô információkat is (címek stb.). A NetWare hálózatokban minden egyes kommunikálni szándékozót (továbbiakban processz) egy internetwork address-nek nevezett cím azonosít. Ez a cím 12 byte hosszú és három mezôbôl áll: • 4 byte hálózatcím (network address) • 6 byte csomópontcím (node address) • 2 byte socketcím (socket address) A hálózatcím az IPX internetwork címzési rendszerének az alapja. Értékét mindig a rendszer adminisztrátora határozza meg úgy, hogy minden hálózati szegmensnek a NetWare hálózatban egyedi címe legyen. A hálózatcímet a router-ek használják a csomagoknak a cél hálózati szegmensekhez való eljuttatásához.


30


A csomópontcím a csomópont azonosítására szolgál. Minden hálózati szegmensben a csomópontoknak egyedi címmel kell rendelkezniük. (A gyakorlatban a csomópontcím a hálózati kártya címe). Egy csomóponton több olyan processz is futhat egyszerre, amely IPX csomagokat állít elô vagy IPX csomagokat vesz. Ezen processzek megkülönböztetésére szolgál a socketcím. Az IPX a socketcím alapján tudja a csomagokat a megfelelô processznek átadni. A socketcím csak a csomóponton belül egyedi, több csomópont is használhatja ugyanazokat a socketcímeket. A munkaállomásokon a felhasználói socketcímek 4000h és 8000h között lehetnek. Néhány socketcím a NetWare számára van fenntartva. Ezeket más célra nem szabad használni. Ilyenek a következôk: • File szerver socketcímek 0x0451 - NetWare Core Protocol (NCP) • Router socketcímek 0x0452 - Service Advertising Protocol (SAP) 0x0453 - Routing Information Protocol (RIP) • Munkaállomás socketcímek 0x0455 - NetBIOS 0x0456 - Diagnostics

2.3.2. IPX kommunikációk Az IPX a felette levô magasabb szintrôl érkezô csomagok végpontok közötti továbbítását teszi lehetôvé. Biztosítja, hogy egy alkalmazás közvetlenül kommunikáljon egy, a hálózat egy másik csomópontján futó alkalmazással. Az IPX összeköttetés nélküli (datagram jellegû) szolgálatot biztosít. Minden csomagot önálló egységnek tekint. Minden csomag tartalmazza mind a cél, mind pedig a forrás címet és az átviendô adatokat. Az IPX nem garantálja a csomagok biztos átvitelét és azok sorrendjének a helyességét. Mivel összeköttetés nélküli szolgálatot biztosít, a csomópontok között handshake kapcsolat nincs. Az IPX-el üzenetszórás (broadcast) egyszerûen megoldható. Az IPX a csomagok átviteléhez két fô adatstruktúrát használ. Az egyik maga az IPX csomag, a másik pedig egy ECB-nek (Event Control Block) nevezett struktúra.

2.3.3. Az IPX csomagok felépítése Minden IPX csomag két fô részbôl áll, fej (header) és adat. Méretük 30 és 576 byte között lehet (fej + adat együtt). A fejrész is több mezôbôl áll, és a csomagok célba juttatásához szükséges információkat tartalmazza. Az adatrész tartalmát teljesen a felhasználó határozza meg, az IPX nem foglalkozik annak tartalmával. BME Számítógéphálózatok jegyzet. Csak belső használatra. Minden jog fenn tartva. Copyright 2000, BME Irányítástechnika és Informatika Tanszék


31

Az IPX felhasználói programinterfésze (Application Programming Interface, API), és az IPX csomagok struktúrája azonos akár kliens (DOS, OS/2, WINDOWS), akár szerver (NLM) környezetben dolgozunk. Az IPX használatához szükséges adatstruktúrákat az nwipxspx.h header file tartalmazza. Az IPX csomag két része, a fejrész és az adatrész egymástól elkülönülô memória területen is elhelyezkedhetnek, és a felhasználói adatok több darabból is állhatnak, de a teljes adatmennyiség (fejrész + adatrészek) együttes hossza nem haladhatja meg az 576 byte-ot. Az egy IPX csomaghoz tartozó részek számát, címét és hosszát az ECB adatstruktúra végén levô fragmentCount és fragmentDescriptor[] tartalmazza. 2.3.3.1. Az IPX csomagok fejrésze (header) Az IPX csomag fejrészében több olyan mezô is van, amellyel a felhasználónak nem kell foglalkoznia. checkSum Ez a mezô régebben hibaellenôrzési funkciókra szolgált, ma már nincs jelentôsége, mert minden hibaellenôrzést a hardware szint végez. length Az IPX állítja be, és a csomagrészek (fregmentek) együttes hosszát tartalmazza. transportControl A NetWare router-ek használják, az IPX az átvitel elôtt 0 értéket ír bele. A továbbiakban csak azok a mezôk szerepelnek, amelyeket a felhasználónak kell beállítania. packetType Az elküldendô csomag típusát jelöli, IPX csomag esetén értéke 4. destination network Ez a 4 byte-os mezô a cél hálózatcímét tartalmazza. A hálózatcímet a hálózat telepítésekor a rendszer adminisztrátora határozza meg. Minden hálózati szegmensnek a NetWare hálózatban egyedi címe van. A saját hálózatunk címét a DOS promptnál a USERLIST /A paranccsal nézhetjük meg. A parancs eredményeként a képernyôre kiíródik a szerverre éppen bejelentkezett összes felhasználó neve, hálózatcíme és csomópontcíme. Ha a destination network mezô értéke 0, akkor a cél hálózatcíme ugyanaz mint a forrás hálózatcíme. destination node 6 byte-os mezô és a cél csomópontcímét tartalmazza. A destination node mezôt az NWGetInternetAddress() függvény hívással tölthetjük ki. Ez a függvény a hálózat szerverétôl kéri le az internetwork címet a cél felhasználói neve alapján. Ha a destination node mezô értéke 0xffffffffffff, akkor a csomag broadcast üzenetként a cél hálózat összes csomópontjának szól. BME Számítógéphálózatok jegyzet. Csak belső használatra. Minden jog fenn tartva. Copyright 2000, BME Irányítástechnika és Informatika Tanszék

32


destination socket 2 byte-os socket szám. A destination socket mezôt az egymással kommunikáló processzek általában egyforma értékûre állítják. 2.3.3.2.

Az ECB (Event Control Block) felépítése

Az ECB az IPX szintû csomagok adásához és vételéhez szükséges adatstruktúra. Szerkezete több csoportra osztható. Tartalmazza egyrészt minden egyes küldendô vagy vett adatcsomag rész (fregment) méretét és puffercímét, másrészt itt helyezkednek el azok az egyéb információk amelyeket egy csomag adása elôtt be kell állítani illetve csomag vétele után ki kell olvasni. Az ECB tartalmazza a completionCode-ot is, amelybôl az adás illetve vétel sikeressége állapítható meg. ECB linkAddress ESRAddress inUseflag completionCode socketNumber IPXWorkspace

00 04 08 09 10 12 16 28 34 36 40 42 46 . . .

IPX header fragment 00 checkSum 02 length 04 transportControl 05 packetType 06 dest. network 10 dest.node DriverWsp. 16 destination socket immediateAddress 18 source network fragmentCount 22 src. node fragmentDescriptor[0].address 28 source socket fragmentDescriptor[0].size User Data fragment fragmentDescriptor[1].address 0 - 546 byte fragmentDescriptor[1].size . . .

Az ECB mezôi közül a felhasználónak csak a következôket kell használnia, illetve beállítania: ESRAddress Ebben a mezôben egy olyan a felhasználó által definiált (Event Service Routine, ESR) függvény címét kell megadni, amelyet egy csomag adása vagy vétel után kell meghívni. inUSEflag Értéke nem nulla, ha az ECB végrehajtás alatt áll. Ilyenkor a felhasználó az ECB tartalmát nem változtathatja meg. Amikor az IPX befejezi az ECB feldolgozását, értékét nullára állítja.



33

completionCode Az IPX ebben a mezôben az aktuálisan végrehajtott adás vagy vétel végsô státuszát adja vissza. Amíg az inUSEflag értéke nem nulla, addig ezen mezô tartalma nem érvényes. socketNumber Az IPX szinten történô kommunikációban a csomagokat processzek küldik egymásnak. A processzeket a socketNumber azonosítja. Ez alapján lehet eldönteni, hogy egy beérkezett csomag mely processznek szól. immediateAddress Ez a 6 byte-os mezô tartalmazza annak a node-nak a címét, amelyiknek az IPX csomagot kell küldeni, vagy amelyiktôl a csomag érkezett. A mezô egy bridge címét is tartalmazhatja, ha a cél node egy másik hálózaton helyezkedik el. A mezôt az IPXGetLocalTarget() függvény hívással kell kitölteni. fragmentCount Ez a mezô az IPX csomag fregmentjeinek (darabjainak) számát tartalmazza. Értéke 1 vagy annál nagyobb. 1-es érték esetén csak a csomag fej megy, adattartalom nincs. fragmentDescriptor A fragmentDescriptor tömb minden egyes eleme egy-egy fregment címét (4 byte) és hosszát (2 byte) tartalmazza. A tömbnek mindig annyi eleme van, amennyi a fragmentCount mezô tartalma. Az nwipxspx.h header file 2 elemû tömböt használ. Az elsô elem az IPX csomag fejéhez tartozik, a második pedig az adatterülethez. Az IPX csomag adattartalma több fregmentben is elhelyezhetô a memória különbözô helyein.

2.3.4. IPX csomagok adása és vétele IPX csomagok adásához, illetve vételéhez a következô lépéseket kell végrehajtani: • • • •

• •

IPX inicializálása az IPXInitialize() függvény meghívásával. Egy socket megnyitása csomagok adására vagy vételére az IPXOpenSocket() függvény meghívásával. Az IPXHeader-ben a célcímet tartalmazó mezôk kitöltése (network, node, socket). (Vétel esetén ezt a pontot ki kell hagyni.) Az ECB struktúra létrehozása és a következô mezôk kitöltése: • ESRAddress • socketNumber • immediateAddress (csak adásnál) • fragmentCount • fragmentDescriptor IPX csomagok vétele az IPXListenForPacket() függvénnyel, vagy csomagok adása az IPXSendPacket() függvénnyel. A socket lezárása az IPXCloseSocket() függvény meghívásával. BME Számítógéphálózatok jegyzet. Csak belső használatra. Minden jog fenn tartva. Copyright 2000, BME Irányítástechnika és Informatika Tanszék

34


Csomagok vétele estén, ha a felhasználó az ECB inUseFlag-ét olvasva állapítja meg, hogy a csomag vétele mikor kész, akkor az ESRAddress mezôbe NULL értéket kell írni. Az immediateAddress mezôt csak adás esetén kell kitölteni. A cél node immediateAddressét az IPXGetLocalTarget() függvénnyel kaphatjuk meg.

3. 3.1.

A FELADATMEGOLDÁSHOZ SZÜKSÉGES SPECIÁLIS ISMERETEK Kiemelések az API dokumentációból

Az alábbi kiemelések a legfontosabbnak ítélt függvények és struktúrák, melyek ismerete nélkülözhetetlen a gyakorlati feladat megoldásához.

3.1.1. Függvények IPXInitialize BYTE IPXInitialize(void); Leírás: Ez a függvény az IPX interfész belépési pontjának címét adja vissza. Minden egyéb IPX függvény hívása elôtt ezt kell elôször meghívni. Visszatérési érték: 0: OK, !=0: Hiba. IPXGetLocalTarget int IPXGetLocalTarget( BYTE *networkAddress, BYTE *immediateAddress, int *transportTime); Leírás: Az ECB immediateAddress mezôjének kitöltéséhez ezt a függvényt kell használni. A függvény vagy a cél node címét, vagy pedig a bridge címét adja vissza ha a cél node egy másik hálózatban van. Visszatérési érték: 0: OK, !=0: Hiba. Lásd még: IPXSendPacket IPXListenForPacket IPXOpenSocket int IPXOpenSocket(BYTE *socketNumber, BYTE SocketType); Leírás: Egy IPX socket megnyitása. Visszatérési érték: 0: OK, !=0: Hiba.



35

IPXSendPacket void IPXSendPacket(ECB *eventControlBlock); Leírás: IPX csomag küldése. A függvény hívása elôtt az ECB-t és a csomag header-t létre kell hozni illetve azokban a megfelelô mezôket ki kell tölteni. Lásd még: IPXGetLocalTarget IPXListenForPacket IPXListenForPacket void IPXListenForPacket(ECB *eventControlBlock); Leírás: IPX csomag vétele. A függvény felkészíti az IPX-et a megadott socket-en csomag vételére. Hívása elôtt a felhasználónak a socket-et meg kell nyitnia, az ECB-t létre kell hoznia és annak mezôit ki kell töltenie. Lásd még: IPXSendPacket

3.1.2. Struktúrák typedef struct IPXAddress { BYTE network[4]; BYTE node[6]; BYTE socket[2]; } typedef struct IPXHeader { WORD checkSum; WORD length; BYTE transportControl; BYTE packetType; IPXAddress destination; IPXAddress source; } typedef struct ECBFragment { void far *address; WORD size; }


36


typedef struct ECB { void far *linkAddress; void (far *ESRAddress)(); BYTE inUseFlag; BYTE completionCode; WORD socketNumber; BYTE IPXWorkspace[4]; BYTE immediateAddress[6]; WORD fragmentCount; ECBFragment fragmentDescriptor[2]; }

3.2.

Összefoglalás

Az IPX a NetWare natív kommunikációs protokollja, amely az OSI referencia modell szerint hálózati réteg szintû protokoll és a kliens munkaállomások, valamint a file szerver közötti kommunikációra szolgál. Az IPX összeköttetés nélküli (datagram jellegû) szolgálatot tesz lehetôvé. Minden csomag tartalmazza mind a cél, mind pedig a forrás címet és az átviendô adatokat. Az adatcsomagokat önálló egységeknek tekinti és nem foglalkozik azok sorrendiségével. Az IPX nem garantálja a csomagok biztos átvitelét. Egy IPX csomag maximális mérete 576 byte, a header hossza 30 byte. Minden csomaghoz tartozik egy ECB struktúra. Ez tartalmazza a csomagrészek számát, címét és hosszát.

3.3.

ETHDUMP hálózat monitorozó program

Az ETHDUMP egy public-domain program. Bármilyen MS-DOS alapú PC-n képes futni, amely rendelkezik Ethernet hálózatvezérlô kártyával. A programmal a hálózaton átvitt keretek figyelhetôk meg. Használata igen egyszerû. Néhány kapcsolóval (indítási paraméter) be kell állítani a mûködési módot, majd a program egy LOG file-ba rögzíti a mûködése alatt a hálózaton megjelenô keretek tartalmát. A kapcsolók a következôk: -dx: Adatkapcsolati driver választás. (p: packet driver, n: NDIS driver, o: ODI driver, d: Dec DLL) Ha nem adjuk meg, a program maga probálja azonosítani a drivert. -sn: n: a keretenként rögzítendô byte-ok száma. -o: -fXXXX:

LOG file neve, default: ETHDUMP.TXT A rögzítendô Ehernet keretek típusa hexa formában.



-fXX:

37

A program ekkor csak a beállított típusú kereteket rögzíti, egyébként típustól föggetlenül minden keretet rögzít. A 2.2.3. pontban található táblázat szerint NetWare IPX/SPX keretek rögzítéséhez a -f8137 kapcsolót kell használni. Ha ezt a kapcsolót használjuk, akkor csak azokat a kereteket rögzíti, amelyekben a 802.2 LLC SAP az itt beállított értékû (hexa).

A program használatánál ügyelni kell arra, hogy a LOG file ne hálózati, hanem mindig egy lokális merev lemezen keletkezzen, mert különben a program a funkciójából eredôen lefagy. A LOG file tartalma és formátuma következô példából látható: ; Packet trace started at Fri Feb 11 18:39:24 1994 ; ; ETHDUMP 1.04 by [email protected] ; ; Format is: ticks_from_start size_in_bytes MAC_Destination MAC_Source Ethernet_Type Ethernet_Data ; ; 18:39:49.45 data: ...&.............Q.........+@.""........Ak-(....W. 0000000019 0064 0000C0DA714A AA000400B22B 8137 FF-FF-00-2600-11-00-00-00-80-00-00-00-00-00-01-04-51-00-00-00-01-AA-0004-00-B2-2B-40-03-22-22-81-07-03-00-18-00-00-00-41-6B-2D-2801-00-C1-05-57-00 ; ; 18:39:51.92 data: ...(.............S...........S..........PING 1re). 0000000064 0064 FFFFFFFFFFFF AA0004000A04 8137 FF-FF-00-2800-01-00-00-00-01-FF-FF-FF-FF-FF-FF-04-53-00-00-00-01-AA-0004-00-0A-04-04-53-00-02-00-01-00-01-00-01-00-01-50-49-4E-4720-31-72-65-29-1B ; ;Packet trace terminated at Fri Feb 11 18:39:32 1994


Adatkapcsolati réteg szolgálatai

Recommend Documents