| | 1 | [[PageOutline(1-6)]] |
| | 2 | = IEEE 802.11 - Formato dei ''frame'' MAC = |
| | 3 | |
| | 4 | ,,20061111-1735 gnappo,, [[BR]] |
| | 5 | Ciascun MAC ''frame'' e' composto dalle seguenti parti: |
| | 6 | 1. un ''header'' che comprende informazioni sul controllo (del ''frame'' |
| | 7 | stesso), la durata, l'indirizzo e il controllo di sequenza del ''frame''; |
| | 8 | 2. il ''frame body'' contenente informazioni dipendenti dal tipo di ''frame'' |
| | 9 | in oggetto e di lunghezza variabile; |
| | 10 | 3. un ''Frame Check Sequence'', cioe' un codice di rilevazione d'errore. |
| | 11 | |
| | 12 | ,,gnappo: ''inserire qua "screenshot" formato frame. I paragrafi sottostanti ne |
| | 13 | illustrano i campi.'',, |
| | 14 | |
| | 15 | == ''Frame Control'' == |
| | 16 | |
| | 17 | ,,20061111-1735 gnappo,, [[BR]] |
| | 18 | A seguire una disamina dei campi contenuti nel cosiddetto ''Frame Control'': |
| | 19 | * campo di versione del protocollo (i.e. 802.11{a,b,g,...}): una stazione che |
| | 20 | riceve un frame di una versione di protocollo non supportata lo potra' |
| | 21 | scartare senza informare la stazione mittente o LLC; |
| | 22 | * campi di tipo e sottotipo: identificano il tipo di frame (controllo, dato o |
| | 23 | ''management''). I sottotipi chiariscono nello specifico la funzionalita' del |
| | 24 | ''frame'' (e.g. un ''frame'' di ''management'' potrebbe essere un ''frame'' |
| | 25 | contente una richiesta di autenticazione oppure di associazione). |
| | 26 | Si rimanda alla tabella 1 per tutte le possibili combinazioni per i due |
| | 27 | campi. |
| | 28 | * Campo ''To DS'': indica se il ''frame'' e' destinato al ''Distribution |
| | 29 | System'' (e.g. tutti i ''frame'' inviati dalle STA verso gli AP hanno questo |
| | 30 | flag asserito); |
| | 31 | * campo ''from DS'': indica se il ''frame'' proviene dal ''Distribution |
| | 32 | System''; |
| | 33 | * campo ''More Fragments'': indica se il ''frame'' corrente ha altri frammenti |
| | 34 | a seguire; |
| | 35 | * campo ''Retry'': e' asserito se il ''frame'' corrente e' una ritrasmissione |
| | 36 | di uno precedente aiutando cosi' il ricevitore nel processo di eliminazione |
| | 37 | di ''frame'' duplicati; |
| | 38 | * campo ''Power Management'': indica se la stazione opera in ''active'' oppure |
| | 39 | ''power-save mode''; |
| | 40 | * campo ''More Data'': si tratta di un bit che se asserito, indica alla |
| | 41 | stazione in ''power-save'' che l'AP ha MSDU o MMPDU bufferizzati a lei |
| | 42 | diretti pronti per l'invio. Inoltre il bit puo' essere valido in una |
| | 43 | trasmissione tra STA ''CF-pollable'' e AP come risposta ad un ''CF-poll'' per |
| | 44 | indicare che la STA ha almeno un MSDU "bufferizzato" pronto per l'invio. Vale |
| | 45 | ancora 1 anche per le trasmissioni in ''broadcast'' dell'AP qualora abbia |
| | 46 | altri MSDU o MMPDU da inviare entro l'invio del prossimo ''beacon''. |
| | 47 | * Campo WEP: indica se il ''frame body'' e' stato crittografato utilizzando |
| | 48 | WEP. Il campo e' significativo solo nei ''frame'' di tipo ''Management'' |
| | 49 | sottotipo ''Authentication'' e nei ''frame'' di tipo ''Data''. |
| | 50 | * Campo ''Order'': indica se il frame e' stato spedito utilizzando la classe |
| | 51 | di servizio ''StrictlyOrder'' |
| | 52 | |
| | 53 | ,,gnappo: ''che cos'e' la classe di servizio !StrictlyOrder?'',, |
| | 54 | |
| | 55 | == ''Duration/ID'' == |
| | 56 | |
| | 57 | ,,20061111-1735 gnappo,, [[BR]] |
| | 58 | Il campo ''Duration/ID'' ha due interpretazioni a seconda della situazione: |
| | 59 | 1. in ''frame Power Save (PS)-Poll'' contiene l' ''association id'' (AID) della |
| | 60 | stazione trasmittente; |
| | 61 | 2. per tutti gli altri frame contiene un valore di durata di impiego del |
| | 62 | mezzo trasmissivo. |
| | 63 | Ad esempio in un ''frame'' RTS il valore del campo ''Duration'' e' dato |
| | 64 | dalla somma del tempo di trasmissione dei dati pendenti, di un CTS, di un |
| | 65 | frame ACK e di tre SIFS. |
| | 66 | Per frame inviati durante il CFP il valore e' fissato a 32768. |
| | 67 | |
| | 68 | Ogni volta che il contenuto del campo ''Duration/ID'' e' minore di 32768 ogni |
| | 69 | STA aggiorna il proprio NAV (Network Allocation Vector). |
| | 70 | |
| | 71 | == ''Address'' == |
| | 72 | |
| | 73 | ,,20061111-1735 gnappo,, [[BR]] |
| | 74 | Ci sono 4 campi ''address'' in un frame MAC utilizzati per identificare il |
| | 75 | BSSID, gli indirizzi della stazione sorgente, destinazione, trasmittente e |
| | 76 | ricevente. Alcuni ''frame'' potrebbero non contenere alcuni di questi |
| | 77 | sottocampi. |
| | 78 | [[BR]] |
| | 79 | Gli indirizzi si suddividono in: |
| | 80 | * indirizzi individuali; |
| | 81 | * indirizzi di gruppo: ''multicast'' oppure ''broadcast''. |
| | 82 | |
| | 83 | Il BSSID denota univocamente ogni BSS. Per quanto riguarda le IBSS questo |
| | 84 | valore e' determinato da un algoritmo che genera numeri "random" con un'elevata |
| | 85 | probabilita' di esser unici. |
| | 86 | |
| | 87 | == ''Sequence number'' == |
| | 88 | |
| | 89 | ,,20061111-1735 gnappo,, [[BR]] |
| | 90 | Questo campo e' suddiviso in due sottocampi: un campo contenente il numero di |
| | 91 | sequenza di MSDU/MMPDU (modulo 4096) ed un altro per il conteggio dei |
| | 92 | frammenti di ciascun MSDU/MMPDU (eventualmente zero). |
| | 93 | |
| | 94 | == ''Frame Body'' == |
| | 95 | |
| | 96 | ,,20061111-1735 gnappo,, [[BR]] |
| | 97 | Come gia' affermato in precedenza, questo campo contiene l'effettivo |
| | 98 | ''data-load''. |
| | 99 | |
| | 100 | == FCS == |
| | 101 | ,,20061111-1735 gnappo,, [[BR]] |
| | 102 | Campo contentente il codice di ridondanza ciclica (CRC) a 32 bit calcolato su |
| | 103 | tutti i campi del ''MAC header'' e sul ''frame body''. |
| | 104 | |
| | 105 | == Alcune note sui frame di controllo == |
| | 106 | |
| | 107 | ,,20061111-1735 gnappo,, [[BR]] |
| | 108 | A differenziare il formato dei diversi ''frame'' di ''management'' e' solo il |
| | 109 | loro rispettivo corpo, diversamente fissato sul numero e tipo dei campi in esso |
| | 110 | contenuti. [[BR]] |
| | 111 | A seguire un elenco dei ''frame'' di ''management'' e una sintetica descrizione |
| | 112 | del loro contenuto: |
| | 113 | * ''beacon'': timestamp, ''beacon interval'' (rappresenta il numero di TU |
| | 114 | che intercorrono tra le trasmissioni dei ''beacon''), informazioni sulle |
| | 115 | capacita' del nodo, parametri della rete (fisica) e dei servizi (se l'AP |
| | 116 | supporta PCF allora nei ''beacon'' saranno contenuti i parametri necessari |
| | 117 | alle STA); |
| | 118 | * ''disassociation'': ragione della richiesta di dissociazione; |
| | 119 | * ''association request'': informazioni sulle capacita' della STA, intervallo |
| | 120 | di ascolto (i.e. ogni quanto tempo la STA si "risveglia" per ascoltare i |
| | 121 | ''beacon'' dell'AP), SSID, ''rate'' supportati; |
| | 122 | * ''association response'': informazioni sulle capacita' dell'AP, stato |
| | 123 | dell'associazione (valida oppure errore), identificativo dell'associazione, |
| | 124 | ''rate'' supportati; |
| | 125 | * ''reassociation response'': come sopra; |
| | 126 | * ''probe request'': SSID, ''rate'' supportati; |
| | 127 | * ''probe response'': analogo al ''beacon''; |
| | 128 | * ''authentication'': numero identificante l'algoritmo di autenticazione, |
| | 129 | numero identificante lo ''step'' del processo di autenticazione, stato, |
| | 130 | ''challenge text'' (presente solo in particolari ''frame'' di |
| | 131 | autenticazione);[[BR]] |
| | 132 | ,,gnappo: ''dove e quando e' utilizzato?'',, |
| | 133 | * ''deauthentication'': ragione della richiesta di disautenticazione. |
