| | 544 | == Formato dei frame MAC == |
| | 545 | ,,20061111-1735 gnappo,, [[BR]] |
| | 546 | Ciascun MAC ''frame'' e' composto dalle seguenti parti: |
| | 547 | 1. un ''header'' che comprende informazioni sul controllo (del ''frame'' |
| | 548 | stesso), la durata, l'indirizzo e il controllo di sequenza del ''frame''; |
| | 549 | 2. il ''frame body'' contenente informazioni dipendenti dal tipo di ''frame'' |
| | 550 | in oggetto e di lunghezza variabile; |
| | 551 | 3. un ''Frame Check Sequence'', cioe' un codice di rilevazione d'errore. |
| | 552 | |
| | 553 | ,,gnappo: ''inserire qua "screenshot" formato frame. I paragrafi sottostanti ne illustrano i campi.'',, |
| | 554 | |
| | 555 | === Frame Control === |
| | 556 | ,,20061111-1735 gnappo,, [[BR]] |
| | 557 | A seguire una disamina dei campi contenuti nel cosiddetto ''Frame Control'': |
| | 558 | * campo di versione del protocollo (i.e. 802.11{a,b,g,...}): una stazione che |
| | 559 | riceve un frame di una versione di protocollo non supportata lo potra' |
| | 560 | scartare senza informare la stazione mittente o LLC; |
| | 561 | * campi di tipo e sottotipo: identificano il tipo di frame (controllo, dato o |
| | 562 | ''management''). I sottotipi chiariscono nello specifico la funzionalita' del |
| | 563 | ''frame'' (e.g. un ''frame'' di ''management'' potrebbe essere un ''frame'' |
| | 564 | contente una richiesta di autenticazione oppure di associazione). |
| | 565 | Si rimanda alla tabella 1 per tutte le possibili combinazioni per i due |
| | 566 | campi. |
| | 567 | * Campo ''To DS'': indica se il ''frame'' e' destinato al ''Distribution |
| | 568 | System'' (e.g. tutti i ''frame'' inviati dalle STA verso gli AP hanno questo |
| | 569 | flag asserito); |
| | 570 | * campo ''from DS'': indica se il ''frame'' proviene dal ''Distribution |
| | 571 | System''; |
| | 572 | * campo ''More Fragments'': indica se il ''frame'' corrente ha altri frammenti |
| | 573 | a seguire; |
| | 574 | * campo ''Retry'': e' asserito se il ''frame'' corrente e' una ritrasmissione |
| | 575 | di uno precedente aiutando cosi' il ricevitore nel processo di eliminazione |
| | 576 | di ''frame'' duplicati; |
| | 577 | * campo ''Power Management'': indica se la stazione opera in ''active'' oppure |
| | 578 | ''power-save mode''; |
| | 579 | * campo ''More Data'': si tratta di un bit che se asserito, indica alla |
| | 580 | stazione in ''power-save'' che l'AP ha MSDU o MMPDU bufferizzati a lei |
| | 581 | diretti pronti per l'invio. Inoltre il bit puo' essere valido in una |
| | 582 | trasmissione tra STA ''CF-pollable'' e AP come risposta ad un ''CF-poll'' per |
| | 583 | indicare che la STA ha almeno un MSDU "bufferizzato" pronto per l'invio. Vale |
| | 584 | ancora 1 anche per le trasmissioni in ''broadcast'' dell'AP qualora abbia |
| | 585 | altri MSDU o MMPDU da inviare entro l'invio del prossimo ''beacon''. |
| | 586 | * Campo WEP: indica se il ''frame body'' e' stato crittografato utilizzando |
| | 587 | WEP. Il campo e' significativo solo nei ''frame'' di tipo ''Management'' |
| | 588 | sottotipo ''Authentication'' e nei ''frame'' di tipo ''Data''. |
| | 589 | * Campo ''Order'': indica se il frame e' stato spedito utilizzando la classe |
| | 590 | di servizio ''StrictlyOrder'' |
| | 591 | |
| | 592 | ,,gnappo: ''che cos'e' la classe di servizio !StrictlyOrder?'',, |
| | 593 | |
| | 594 | === Duration/ID === |
| | 595 | ,,20061111-1735 gnappo,, [[BR]] |
| | 596 | Il campo ''Duration/ID'' ha due interpretazioni a seconda della situazione: |
| | 597 | 1. in ''frame Power Save (PS)-Poll'' contiene l' ''association id'' (AID) della |
| | 598 | stazione trasmittente; |
| | 599 | 2. per tutti gli altri frame contiene un valore di durata di impiego del |
| | 600 | mezzo trasmissivo. |
| | 601 | Ad esempio in un ''frame'' RTS il valore del campo ''Duration'' e' dato |
| | 602 | dalla somma del tempo di trasmissione dei dati pendenti, di un CTS, di un |
| | 603 | frame ACK e di tre SIFS. |
| | 604 | Per frame inviati durante il CFP il valore e' fissato a 32768. |
| | 605 | |
| | 606 | Ogni volta che il contenuto del campo ''Duration/ID'' e' minore di 32768 ogni |
| | 607 | STA aggiorna il proprio NAV (Network Allocation Vector). |
| | 608 | |
| | 609 | === Address === |
| | 610 | ,,20061111-1735 gnappo,, [[BR]] |
| | 611 | Ci sono 4 campi ''address'' in un frame MAC utilizzati per identificare il |
| | 612 | BSSID, gli indirizzi della stazione sorgente, destinazione, trasmittente e |
| | 613 | ricevente. Alcuni frame potrebbero non contenere alcuni di questi sottocampi. |
| | 614 | [[BR]] |
| | 615 | Gli indirizzi si suddividono in: |
| | 616 | * indirizzi individuali; |
| | 617 | * indirizzi di gruppo: ''multicast'' oppure ''broadcast''. |
| | 618 | |
| | 619 | Il BSSID denota univocamente ogni BSS. Per quanto riguarda le IBSS questo |
| | 620 | valore e' determinato da un algoritmo che genera numeri "random" con un'elevata |
| | 621 | probabilita' di esser unici. |
| | 622 | |
| | 623 | === Sequence number === |
| | 624 | ,,20061111-1735 gnappo,, [[BR]] |
| | 625 | Questo campo e' suddiviso in due sottocampi: un campo contenente il numero di |
| | 626 | sequenza di MSDU/MMPDU (modulo 4096) ed un altro per il conteggio dei |
| | 627 | frammenti di ciascun MSDU/MMPDU (eventualmente zero). |
| | 628 | |
| | 629 | === Frame Body === |
| | 630 | ,,20061111-1735 gnappo,, [[BR]] |
| | 631 | Come gia' affermato in precedenza, questo campo contiene l'effettivo |
| | 632 | ''data-load''. |
| | 633 | |
| | 634 | === FCS === |
| | 635 | ,,20061111-1735 gnappo,, [[BR]] |
| | 636 | Campo contentente il codice di ridondanza ciclica (CRC) a 32 bit calcolato su |
| | 637 | tutti i campi del ''MAC header'' e sul ''frame body''. |
| | 638 | |
| | 639 | |
| | 640 | === Alcune note sui frame di management === |
| | 641 | ,,20061111-1735 gnappo,, [[BR]] |
| | 642 | A differenziare il formato dei diversi ''frame'' di ''management'' e' solo il |
| | 643 | loro rispettivo corpo, diversamente fissato sul numero e tipo dei campi in esso |
| | 644 | contenuti. [[BR]] |
| | 645 | A seguire un elenco dei ''frame'' di ''management'' e una sintetica descrizione |
| | 646 | del loro contenuto: |
| | 647 | * ''beacon'': timestamp, ''beacon interval'' (rappresenta il numero di TU |
| | 648 | che intercorrono tra le trasmissioni dei ''beacon''), informazioni sulle |
| | 649 | capacita' del nodo, parametri della rete (fisica) e dei servizi (se l'AP |
| | 650 | supporta PCF allora nei ''beacon'' saranno contenuti i parametri necessari |
| | 651 | alle STA); |
| | 652 | * ''disassociation'': ragione della richiesta di disassociazione; |
| | 653 | * ''association request'': informazioni sulle capacita' della STA, intervallo |
| | 654 | di ascolto (i.e. ogni quanto tempo la STA si "risveglia" per ascoltare i |
| | 655 | ''beacon'' dell'AP), SSID, ''rate'' supportati; |
| | 656 | * ''association response'': informazioni sulle capacita' dell'AP, stato |
| | 657 | dell'associazione (valida oppure errore), identificativo dell'associazione, |
| | 658 | ''rate'' supportati; |
| | 659 | * ''reassociation response'': come sopra; |
| | 660 | * ''probe request'': SSID, ''rate'' supportati; |
| | 661 | * ''probe response'': analogo al ''beacon''; |
| | 662 | * ''authentication'': numero identificante l'algoritmo di autenticazione, |
| | 663 | numero identificante lo ''step'' del processo di autenticazione, stato, |
| | 664 | ''challenge text'' (presente solo in particolari ''frame'' di |
| | 665 | autenticazione);[[BR]] |
| | 666 | ,,gnappo: ''dove e quando e' utilizzato?'',, |
| | 667 | * ''deauthentication'': ragione della richiesta di disautenticazione. |
| | 668 | |