Networking the Windows way

SMB/NetBIOS/NetBEUI werd ontworpen voor heel kleine netwerken en voor evenkniecommunicatie (peer-to-peer) door IBM en later ook door Microsoft. Microsoft gebruikte het als basis om Windows-systemen met elkaar te laten netwerken.

In het vorige deel probeerden we enig licht te werpen op de juiste terminologie.
NetBIOS is een interface die een netwerkprotocol nodig heeft om zijn ding te
kunnen doen. Dat netwerkprotocol kan NetBEUI zijn (IBM noemt het geheel dan NBF,
zie verder), maar ook andere protocollen zoals tcp/ip of IPX. Het
oorspronkelijke idee achter NetBIOS was dat je geen routering nodig hebt voor
hele kleine netwerkjes en dat je geen moeilijk te onthouden netwerkaddressen
gebruikt maar makkelijke netwerknamen. NetBIOS-zenders en -ontvangers wisselen
‘service message blocks’ of kortweg SMB’s uit. Vandaar dat dit ook wel
SMB-netwerken heet, al noemt Microsoft dat tegenwoordig ‘Windows Networking’. De
term SMB heeft Microsoft ook al vervangen: dat heet tegenwoordig CIFS (Common
Internet File System). ’t Kind moet maar een naam hebben, nietwaar.

NetBIOS Protocol Stack

Als je een schema uittekent van alle protocols, interfaces en applicaties van
de NetBIOS-familie, dan noemen we dat de NetBIOS Protocol Stack. Je kunt hierbij
denken aan de lagen van het OSI-model, al heeft de NetBIOS-stack geen zeven maar
zes lagen:

6. Applicaties
5. SMP (Session Management Protocol), NMP (Name Management Protocol), UDP (User
Datagram Protocol)
4. RST (Reliable Stream Protocol), DTP (Datagram Transport Protocol)
3. PTP (Packet Transfer Protocol)
2. LAP (Link Access Protocol)
1. fysieke media

Wel of geen NetBEUI?

Zoals we in het vorige deel al aanhaalden, is NetBIOS eigenlijk geen protocol
maar wel een interface die een netwerkprotocol nodig heeft om zijn ding te doen.
Dat was oorspronkelijk het doel van NetBEUI, in 1985 door IBM ontworpen als
netwerkprotocol om NetBIOS-sessies te transporteren met behulp van de IBM LAN
Manager server. Zoals we de vorige keer al bespraken, plaatst NetBEUI de
NetBIOS-pakketten vrijwel rechtstreeks op het onderliggende netwerk, dus zonder
een OSI laag 3 dragerprotocol. De SMB-zenders werken bijgevolg via broadcasting:
ze schreeuwen hun beschikbaar uit over het netwerk en geïnteresseerde ontvangers
kunnen zo contact leggen. Dat is erg snel maar niet zo efficiënt qua
bandbreedte. Perfect voor een klein netwerk, doch dat werd natuurlijk anders
naarmate netwerken groeiden.
NetBEUI versies 3 en 4 zoals die in moderne Windows-systemen zitten, zijn strikt
genomen geen echte NetBEUI meer, maar bestaat uit het NetBIOS Frame Format (NBF)
protocol van IBM, dat communiceert met de Windows Transport Driver Interface of
TDI aan de onderkant en NetBIOS aan de bovenkant. Tegenwoordig is het gebruik
van IPX en zeker IP veel populairder dan NBF. SAMBA (de SMB-oplossing uit de
Unix/Linux-wereld) kan alleen maar IP als transportprotocol voor NetBIOS
gebruiken, al bestaan er ook SAMBA-varianten die met IPX kunnen werken. Voor
zover ons bekend bestaat er geen oplossing van derden die NBF ondersteunt: NBF
is kennelijk uitsluitend het domein van IBM en Microsoft.

NBF-formaat

NetBEUI gebruikt OSI laag 2 IEEE 802.2 LLC structuren (zie de artikels
in deze reeks over Ethernet) en in het bijzonder LLC type 1 (Datagram
Services) en LLC type 2 (Session Services). Een NBF-hoofding in LLC waar het
bestemmings- en bron-SAP gelijk zijn aan F0 ziet er zo uit:

1. 2 bytes LENGTE;
2. 2 bytes SCHEIDER;
3. 1 byte BEVEL;
4. 1 byte DATA1;
5. 2 bytes DATA2;
6. 2 bytes TCOR;
7. 2 bytes RCOR;
8. 16 bytes BESTEMMINGSNAAM;
9. 16 bytes AFZENDERNAAM;
10. UDATA

Deze velden betekenen het volgende:

1. LENGTE: 2 bytes groot veld met de NetBIOS frame-lengte, normaal
hexadecimaal 0x002C.
2. SCHEIDER: 2 bytes groot veld met de waarde 0xEFFF.
3. BEVEL: een één byte groot veld met een bevelwaarde (zie verder voor een
lijst).
4. DATA1: veld van één byte dat alleen gebruikt wordt door bepaalde frames zoals
ADD_NAME_RESPONSE (zie verder).
5. DATA2: 2 bytes groot veld dat alleen gebruikt wordt door bepaalde frames
zoals NAME_QUERY and NAME_RECOGNISED (zie verder).
6. TCOR of ‘Transmit Correlator’: een veld van 2 bytes gebruikt door bepaalde
antwoordframes om het antwoordframe te correleren aan de vraag met behulp van
een waarde die teruggegeven wordt in het antwoord.
7. RCOR of ‘Receive Correlator’: nog een veld van 2 bytes gebruikt door bepaalde
frames om het antwoordframe met een waarde in het TCOR-veld te correleren.
8. BESTEMMINGSNAAM: een ID-veld van 16 bytes met de NetBIOS-naam of -nummer van
de geadresseerde.
9. AFZENDERNAAM: een ID-veld van 16 bytes met de NetBIOS-naam of -nummer van de
afzender.
10. UDATA: ‘user data’ of data van de gebruiker die verdergegeven moet worden
aan NetBIOS.

Microsoft eist dat NetBIOS-namen hooguit 15 tekens lang zijn en in
hoofdletters; het zestiende byte is dan een speciaal karakter om een type van de
NetBIOS-naam mee aan te duiden. Een volledige lijst van deze types (bij
Microsoft heet dat NetBIOS-suffixes) vind je in het Microsoft Knowledge Base
artikel

Q163409. In principe zijn er twee groepen van NetBIOS-namen (uniek en
globaal), maar Microsoft heeft er een stel bijverzonnen.

NCB’s of Network Control Blocks (NCB)

Alle programmabevelen worden aangeboden aan NetBIOS in een formaat dat NCB
heet en dat is een afkorting voor ‘Network Control Blocks’ (netwerkbeheerblokken).
Het programma van de gebruiker is verantwoordelijk voor het in het geheugen
toewijzen van deze blokken. NetBIOS ondersteunt verbindingsgeöriënteerde
communicatie (virtuele circuits) en verbindingsloze communicatie met behulp van
broadcasts en multicasts. Het NCB is een 64 bytes grote datastructuur in het
datablok direct na de afzendernaam in het NBF-frame. Netwerkanalysatoren kunnen
hier meestal niet goed mee overweg omdat een NCB immers deel uitmaakt van de
‘user data’ van het frame. Een NCB heeft de volgende structuur:

> BEVEL
> MELDCODE – eindcode voor een asynchroon bevel, of initiatiecode voor een
asynchroon bevel.
> LOKALE SESSIE – sessienummer voor het bevel
> NAAMNUMMER – een uniek nummer voor de gebruikte naam
> BUFFERADRES – het adres van de buffer voor zend- en ontvangstbevelen
> BUFFERLENGTE
> ROEPNAAM – de naam van het andere station dat je wil contacteren of waarmee je
al contact hebt
> NAAM – de lokale naam
> RTO – ‘receive timeout’, vervaltijd voor ontvangsbevelen in veelvouden van
500ms
> STO – ‘send timeout’, vervaltijd voor zendbevelen in veelvouden van 500ms
> POST-adres – het adres van de POST-routine die aangeroepen wordt als
asynchronische bevelen afgelopen zijn
> LAN_A_NUMMER – geeft de adapter aan als er meer dan één netwerkadapter in een
station zit
> BEVELKLAAR – eindcode voor asynchrone bevelen
> GERESERVEERD – gereserveerde byte

NetBIOS-diensten

NetBIOS ondersteunt de volgende diensten (zie ook het eerste schema in dit
artikel):

1. Benamingsdiensten met behulp van het NMP (Name Management Protocol). Namen
zijn natuurlijk noodzakelijk om netwerkstations te identificeren en kunnen
specifiek naar een station wijzen (unieke namen) of naar een groep van stations
(groepnamen); ze kunnen ook gewijzigd worden.
2. Sessiediensten met behulp van het SMP (Session Management Protocol): dit
zorgt voor een verbindingsgeöriënteerde, betrouwbare en full-duplex
(gelijktijdig zenden en ontvangen) berichtendienst voor de gebruikersprocessen.
3. Datagramdiensten met behulp van het UDP (User Datagram Protocol): datagrammen
(protocolspecifieke netwerkpakketten) versturen naar een specifieke naam, naar
alle leden van een groep, of broadcasten naar het hele netwerk.
4. Diagnosediensten met behulp van DMP (Diagnostic and Monitoring Protocol):
hiermee kun je de status van netwerkstations opvragen, de functie is
vergelijkbaar met die van SNMP bij tcp/ip.

Sessies kunnen plaatsvinden tussen willekeurige NetBIOS-stations in het
netwerk: er is geen hiërarchie aangezien NetBIOS immers een evenknie-oplossing
is.