¿Qué tarjetas de red inalámbrica USB admiten la inyección de fotogramas?

Primero, introduzcamos brevemente la estructura del hardware. El plan de implementación del hardware se muestra en la Figura 1-1. La tarjeta de red funciona en estado semidúplex. La interfaz USB cumple con USB 2.0 y utiliza el chip IC9211 de ICSI. El chip de la capa física utiliza el chip de la empresa Intersil. El motor de control de la capa MAC debe programarse con microcódigo o incrustarse en el núcleo de la CPU.

Como proyecto nuevo, primero debe enumerar la carga de trabajo de desarrollo, formular un plan de desarrollo razonable, subdividir todo el proyecto en varios proyectos pequeños y avanzar paso a paso. A continuación se presenta el contenido del trabajo.

Entre estos contenidos, lo primero que hay que solucionar es el problema de comunicación USB. Dado que la interfaz del hardware es una interfaz de bus USB, se debe abrir el canal USB. Hay una interfaz de programación especial en el sistema Microsoft Windows. Solo necesitamos encapsular las funciones requeridas en un paquete de solicitud URB (Bloque de solicitud USB) y enviar el paquete URB a la siguiente capa llamando a la interfaz del controlador de clase USBD. Al final, el conductor del autobús interactúa con el dispositivo.

El segundo paso es desarrollar el marco del controlador del minipuerto NDIS. NDIS es la biblioteca de desarrollo de dispositivos de red de Microsoft, que proporciona muchas funciones de interfaz relacionadas con dispositivos de red para realizar llamadas. Según el diseño, este controlador es de tipo minipuerto, por lo que es necesario desarrollar una interfaz de minipuerto estándar para las llamadas al sistema. Al igual que los controladores tradicionales, también encapsula una serie de funciones de devolución de llamada al sistema. La forma de estas interfaces de llamada ha sido definida por la especificación NDIS de Microsoft.

El siguiente paso es mejorar estas interfaces. Agregue contenido del protocolo 802.11 como entidad controladora. Dado que el chip de intersil no integra la función del protocolo 802.11, necesitamos desarrollar el contenido especificado por la capa MAC en el protocolo en el software. Esta parte es también el contenido principal de nuestro controlador.

El protocolo 802.11 tiene tres estados principales. Según la especificación del protocolo, la comunicación de datos sólo es posible en el estado asociado. La autenticación y el cifrado están relacionados con la seguridad y, en teoría, no tienen ninguna relación necesaria con el protocolo. Por motivos de seguridad, el protocolo inalámbrico 802.11 también incluye cifrado y autenticación como parte del protocolo, por lo que tiene el mismo nivel de seguridad que uno cableado. red. Al mismo tiempo, el protocolo 802.11 define muchos comandos, como solicitud/respuesta de sonda, baliza, autenticación, desautenticación, asociación, desasociación, etc. El cuerpo principal del programa es una máquina de estado, siempre que se envíe el comando correspondiente. , el estado se puede cambiar y se puede completar la función correspondiente.

La búsqueda de la lista de AP, el proceso de autenticación, el proceso de asociación, el cambio de canal, etc. involucrados en el protocolo deben implementarse por separado, cada uno de los cuales es una máquina de estado más detallada. Para obtener detalles sobre el protocolo 802.11, consulte los documentos pertinentes. No hay mucho que decir aquí. La Figura 1-2 a continuación es el diagrama de estado del protocolo 802.11.

Dividido según función: se puede dividir en tres tipos diferentes de marcos: de gestión, de control y de datos. Para conocer la definición de estructura Clase 1, Clase 2 y 3, consulte 802.11-1999.

1. Introducción al bus USB

USB es una arquitectura de bus serie universal desarrollada por Intel. Ha sido muy bien recibida por su diseño simple, facilidad de uso y funciones intercambiables en caliente. Muchos dispositivos están empezando a admitir la especificación USB.

Un sistema USB se define principalmente como tres partes: interconexión USB; dispositivo USB;

En cualquier sistema USB, sólo hay un host. La interfaz entre el USB y el sistema host se denomina controlador host. El controlador host se puede implementar de manera integral mediante hardware, firmware y software. Los concentradores raíz están integrados en el sistema host para proporcionar más puntos de conexión.

Figura 2-1 Topología del bus

La Figura 2-1 muestra la topología del bus USB.

La especificación USB estándar tiene cuatro cables, es decir, los polos de voltaje positivo y negativo y dos cables de datos. La apariencia es una interfaz cuadrada y plana. USB transmite señales y energía a través de un cable de cuatro hilos. Los dos cables de la Figura 2-2 se utilizan para enviar señales.

El cable incluye dos líneas: VBUS? y GND, que suministran energía al dispositivo. ¿VBUS? Utiliza fuente de alimentación de +5V.

El bus USB es un bus de sondeo y el puerto de control del host inicializa toda la transmisión de datos. Una vez instalado el dispositivo USB, el host activa el puerto a través del canal de control del dispositivo y le proporciona al dispositivo USB un valor de dirección preestablecido. El host asigna una dirección USB única a cada dispositivo.

USB define algunos comandos de solicitud y todos los dispositivos USB responden a las solicitudes del host en el canal de control predeterminado del dispositivo (canal de control predeterminado). Estas solicitudes se logran mediante la transferencia de control. La solicitud y los parámetros solicitados se envían al dispositivo a través del paquete de configuración. El host es responsable de establecer el valor de cada campo en el paquete de configuración. Cada paquete de configuración tiene 8 bytes. Consulte la Tabla 2-1.

campo bmRequestType

Este campo indica las características de esta solicitud. En particular, este campo indica la dirección de la transferencia de control de la segunda fase. Si el campo wLength se establece en 0, lo que indica que no hay fase de transferencia de datos, se ignorará el bit de dirección.

La especificación USB define una serie de solicitudes estándar que todos los dispositivos deben soportar. Estas solicitudes se ejemplifican en la Tabla 8-3. Además, una clase de dispositivo puede definir más solicitudes. Los proveedores de dispositivos también pueden definir solicitudes de soporte para dispositivos.

Las solicitudes se pueden dirigir a un dispositivo, a una interfaz de dispositivo o a un punto final de dispositivo. Este campo de solicitud también especifica el destinatario. Al especificar una interfaz o punto final, el campo wIndex indica esa interfaz o punto final.

bCampo de solicitud

Este campo identifica la solicitud específica. El Tipo del campo bmRequestType puede modificar el significado de este campo. Esta descripción solo define el significado del valor del campo bRequest cuando el bit de tipo es 0, que es una solicitud de dispositivo estándar.

campo wValue

Este campo se utiliza para transmitir los parámetros de la solicitud actual, que cambia con la solicitud.

campo wIndex

El campo wIndex se utiliza para indicar qué interfaz o nodo final es. La Figura 2-3 muestra el formato de wIndex (al identificar el nodo final). Cuando el bit de dirección se establece en 0, indica el nodo saliente, cuando se establece en 1, indica el nodo entrante y el número de punto final es el número de nodo. La Figura 2-4 muestra el formato cuando se utiliza wIndex para identificar una interfaz.

campo wLength

Este campo indica la duración de la segunda fase de transmisión de datos. La dirección de transmisión se indica mediante el bit de dirección del campo bmRequstType. Un campo wLength de 0 indica que no hay transmisión de datos. En una solicitud de entrada, la longitud de los datos devueltos por el dispositivo no debe ser mayor que wLength, pero puede ser menor. En una solicitud de salida, wLength indica la cantidad exacta de datos enviados por el host. Si el host envía más datos que wLength, la respuesta del dispositivo no está definida.

La Tabla 2-2 describe las solicitudes de dispositivos estándar que se definen para todos los dispositivos USB y las enumera. Independientemente de si a los dispositivos se les ha asignado una dirección no predeterminada o si el dispositivo está configurado actualmente, deben responder a las solicitudes estándar. Consulte las especificaciones USB para obtener más detalles.

Cuando hablamos del bus USB, tenemos que hablar del método de transmisión del bus USB.

Un canal USB es la conexión entre un punto final del dispositivo y el software del host. El diseñador de un dispositivo USB puede determinar las capacidades de cada punto final del dispositivo. Una vez que se establece un canal para este punto final, la mayoría de las características de transmisión del canal quedan fijas hasta que se cancela el canal.

USB define 4 tipos de transmisión:

Transmisión de control: transmisión confiable, aperiódica, de solicitud o respuesta iniciada por el software del host, generalmente utilizada para transacciones de comando y transacciones de estado.

·Transmisión síncrona: Comunicación periódica y continua entre el host y el dispositivo, generalmente utilizada para transmitir información relacionada con el tiempo. Este tipo conserva la capacidad de incluir el concepto de tiempo en los datos. Pero esto no significa que el momento de transmisión de dichos datos sea siempre importante, es decir, que la transmisión no sea necesariamente urgente.

·Transmisión interrumpida: transmisión de datos a pequeña escala, baja velocidad y retardo fijo.

·Transmisión por lotes: transmisión fiable y no periódica de paquetes de gran tamaño. Normalmente se utiliza para transmitir datos que pueden utilizar cualquier ancho de banda y pueden tolerar esperas cuando no hay ancho de banda disponible.

Cada punto final tiene su propio método de transmisión Al configurar el descriptor, el host puede conocer el método de transmisión de cada punto final y comunicarse en este método.

1. Introducción al marco WDM

WDM (modelo de controlador de Windows) es un conjunto de especificaciones definidas por Microsoft para el desarrollo de controladores. En comparación con el controlador Vxd original, WDM es más completo y puede ser compatible binariamente con varias versiones de Windows. Se completa en un sistema y se puede trasplantar fácilmente a otros sistemas Windows. Tuve la suerte de trasplantar el controlador desarrollado en Windows XP a Windows 2000, Windows Me y Windows 98. Esta es mi buena experiencia.

Según Walter Oney, un controlador de dispositivo es un contenedor que contiene muchas rutinas invocables del sistema operativo que permiten a los dispositivos de hardware realizar las acciones correspondientes.

El modelo WDM utiliza una estructura jerárquica, como se muestra en la Figura 3-1. A la izquierda hay una pila de objetos de dispositivo. Los objetos de dispositivo son estructuras de datos creadas por el sistema para ayudar al software a administrar el hardware. Una pieza física de hardware puede tener varias estructuras de datos de este tipo. El objeto de dispositivo en la parte inferior de la pila se denomina objeto de dispositivo físico o PDO para abreviar. En el medio de la pila de objetos del dispositivo, hay un objeto llamado objeto de dispositivo de función (FDO para abreviar). También habrá un objeto de dispositivo de filtro encima y debajo de FDO, denominado FiDO.

Bus es una definición amplia que incluye PCI, tarjeta SCSI, puerto paralelo, puerto serie, concentrador USB, etc. En realidad, puede ser cualquier dispositivo de hardware que pueda conectarse a varios dispositivos. Una de las tareas del conductor del autobús es enumerar los dispositivos en el autobús y crear un PDO para cada dispositivo.

Nuestro minipuerto es en realidad un controlador de funciones.

1. Introducción al entorno de desarrollo

La siguiente es una introducción al entorno de desarrollo. El desarrollo de controladores de Windows utiliza herramientas VC. para configurar las variables de entorno y la ruta a la biblioteca DDK. Hay dos tipos de controladores compilados: verificados y gratuitos. Verificado corresponde a la versión de depuración y gratuito corresponde a la versión de lanzamiento.

La herramienta de depuración utiliza Softice. Estoy usando la versión 2.7. Esta herramienta es muy poderosa. Puede ver variables, memoria y llamadas de pila.

O, en general, puede depurar a través de la herramienta debugview y simplemente imprimir las variables en la ruta crítica del programa requerido. Cuando el programa es relativamente estable, puede usar debugview para observar problemas lógicos, de modo que pueda localizarlos más rápido y luego usar softice para una depuración detallada.

2. Implementación del modelo WDM y la capa inferior de USB

Microsoft Windows implementa el controlador de bus USB y algunos controladores de clase USB. Después de encapsularlo a través de URB, el paquete URB se envía al. siguiente Una capa de conductores finalmente se comunica con el dispositivo a través del conductor del autobús.

El modelo WDM proporciona la arquitectura de programación USB. Esta arquitectura abarca múltiples conceptos, incluido un enfoque jerárquico para integrar dispositivos en computadoras, un enfoque común para la administración de energía y estándares de autoidentificación para descriptores de hardware de múltiples niveles. El estándar USB descompone cuadros de tiempo (cuadros) en paquetes de datos (paquetes) para lograr la transmisión de datos entre el dispositivo y el host. Finalmente, USB admite cuatro modos de transferencia de datos entre el host y el punto final del dispositivo. Un modo, llamado isócrono, transmite una cantidad fija de datos cada milisegundo sin verificación de errores.

Otros modos son: transferencia de control, transferencia masiva y transferencia de rango medio, que solo pueden transferir pequeñas cantidades (64 bytes o menos) de datos con verificación de errores.

El controlador USB depende en gran medida del controlador del bus (USBD.sys) y no utiliza directamente funciones HAL para comunicarse con el hardware. Puede completar operaciones de hardware simplemente creando una URB (bloque de solicitud USB) y enviándola al conductor del autobús. USBD.sys puede entenderse como una entidad que acepta URB. La llamada a USBD se convierte en un IRP con el código de función principal IRP_MJ_INTERNAL_DEVICE_CONTROL. Luego, la USBD programa el horario del autobús y emite la operación especificada en la URB.

Generalmente podemos crear y enviar una URB al controlador USBD de la siguiente manera.

Por ejemplo, al responder al mensaje IRP_START_DEVICE, primero se debe leer el descriptor del dispositivo y luego

URB urb;

USB_DEVICE_DESCRIPTOR deviceDesc;

UsbBuildGetDescriptorRequest

(

&urb,

(USHORT) tamaño de (struct _URB_CONTROL_DESCRIPTOR_REQUEST),

USB_DEVICE_DESCRIPTOR_TYPE,

0,

0,

&deviceDesc,

NULL,

tamaño de(USB_DEVICE_DESCRIPTOR),

NULL

);

UsbBuildGetDescriptorRequest es en realidad una macro, declarada en USBDLIB.H, que se utiliza para generar varios campos de la subestructura de solicitud de descriptor de lectura.

Después de crear la URB, debe enviar una solicitud de control IO interno (IOCTL) al controlador USBD. El controlador USBD está ubicado en el extremo inferior de la jerarquía de controladores y generalmente necesita esperar una respuesta. desde el dispositivo.

NTSTATUS MPUSB_CallUSBD

(

EN PDEVICE_OBJECT DeviceObject,

EN PURB Urb

)

{

Evento KEVENT;

IO_STATUS_BLOCK ioStatus;

PDEVICE_EXTENSION pDevExt;

pDevExt = DeviceObject->DeviceExtension; p>

// emitir una solicitud sincrónica para leer el UTB

KeInitializeEvent(&event, NotificationEvent, FALSE);

PIRP irp = IoBuildDeviceIoControlRequest

(

IOCTL_INTERNAL_USB_SUBMIT_URB,

pDevExt -> StackDeviceObject,

NULL,

0,

NULL,

p>

0,

VERDADERO, /* INTERNO */

&evento,

&ioStatus

);

// Llame al controlador de clase para realizar la operación. Si el estado devuelto

// es PENDIENTE, espere a que se complete la solicitud.

PIO_STACK_LOCATION nextStack = IoGetNextIrpStackLocation( irp );

nextStack->Parameters.Others.Argument1 = Urb;

NTSTATUS ntStatus = IoCallDriver( pDevExt -> StackDeviceObject, irp );

if ( ntStatus == STATUS_PENDING)

{

ntStatus = KeWaitForSingleObject

(

&evento,

Ejecutivo,

KernelMode,

FALSE,

NULL

);

}

/ /Mapas USBD

e código de error para nosotros

ntStatus = ioStatus.Status;

return ntStatus;

}

De esta manera podemos pasar el USB bus Comunicado con el dispositivo.

Por supuesto, este proceso es más complicado y requiere leer y configurar descriptores de dispositivo, descriptores de configuración, descriptores de interfaz y descriptores de punto final. Estos descriptores se describen en la especificación del protocolo USB y en la clase USB correspondiente. También hay una descripción detallada en la especificación.

El formato del descriptor de configuración general es el siguiente:

Este ejemplo muestra que este dispositivo tiene dos interfaces, una interfaz tiene dos puntos finales y la segunda interfaz también tiene dos puntos finales. Cada interfaz puede ser una función independiente. En este caso, el dispositivo es un dispositivo compuesto y debe declararse en el descriptor de configuración que es un dispositivo compuesto. Cada interfaz también necesita declarar su tipo por separado.

Por ejemplo, una vez tuve un proyecto con tres interfaces: módem, puerto serie normal y almacenamiento masivo USB. Estas tres interfaces deben declarar sus tipos por separado, y estos tipos se definen en detalle en la especificación de clase USB.

Generalmente, dado que la longitud del descriptor de configuración es variable, primero debemos obtener los primeros 9 bytes de esta larga cadena, que es el descriptor de configuración (ver especificación). El formato es el siguiente,

typedef struct

{

longitud del byte; // bLongitud: tamaño en bytes

byte descriptor_type; // bDescriptorType

palabra total_length; // wTotalLength: en bytes

byte num_interfaces; // bNumInterfaces

configuración de bytes; p> byte config_index; // iConfiguration

byte atributos; // bmAttributes

byte max_power; // MaxPower: en unidades de 2 mA

} usbdc_configuration_descriptor_type;

De esta manera, el tercer y cuarto byte de esta cadena indicarán la longitud de toda la cadena y luego leerán la longitud nuevamente para obtener la cadena de configuración completa.

1. Modelo NDIS y controlador de minipuerto con capa inferior WDM

NDIS (Especificación de interfaz de dispositivo de red) es la biblioteca de desarrollo de Microsoft para dispositivos de red. Sin embargo, dado que este dispositivo es un dispositivo USB, es necesario acceder a él a través del modelo WDM. Por lo tanto, al diseñarlo, consideramos que se trataba de una interfaz de capa superior de minipuerto NDIS con un controlador de interfaz de acceso WDM. Afortunadamente, Microsoft admite dicho diseño.

Según el diseño, este controlador es de tipo minipuerto, por lo que es necesario desarrollar una interfaz de minipuerto estándar para llamadas al sistema.

Al igual que los controladores tradicionales, también encapsula una serie de funciones de llamada al sistema. La forma de estas interfaces de llamada ha sido definida por la especificación NDIS de Microsoft. La función de entrada es DriverEntry.

La función de la función de entrada es la primera función del controlador de llamada al sistema. Es responsable de inicializar el controlador y registrar la función de devolución de llamada. Estas funciones incluyen las siguientes, completadas a través de una estructura.

Primero, se debe llamar a la siguiente función para asociar el controlador del minipuerto con NDIS. Al llamar a esta función, se almacena la información del controlador del minipuerto. El identificador devuelto NdisWrapperHandle se utiliza para el registro posterior de la función de devolución de llamada. NDIS también usa NdisWrapperHandle para distinguir entre diferentes controladores.

NdisMInitializeWrapper(

&NdisWrapperHandle,

DriverObject,

RegistryPath,

NULL

);

El método para registrar la función de devolución de llamada es el siguiente y el tipo de estructura de registro es NDIS_MINIPORT_CHARACTERISTICS.

// y los puntos de entrada para MiniportXxx proporcionado por el controlador

NdisZeroMemory(&MPChar, sizeof(MPChar));

//

// El número de versión de NDIS, además de incluirse en

// NDIS_MINIPORT_CHARACTERISTICS, también debe especificarse cuando

// se compila el código fuente del controlador de minipuerto.

//

MPChar.MajorNdisVersion = MP_NDIS_MAJOR_VERSION;

MPChar.MinorNdisVersion = MP_NDIS_MINOR_VERSION;

MPChar.InitializeHandler = MPInitialize;

MPChar.HaltHandler = MPHalt;

MPChar.SetInformationHandler = MPSetInformation;

MPChar.QueryInformationHandler = MPQueryInformation;

MPChar.SendPacketsHandler = MiniportTxPackets;

MPChar.ReturnPacketHandler = MiniportReturnPacket;

MPChar.ResetHandler = MPReset;

MPChar.CheckForHangHandler = MPCheckForHang //opcional

#ifdef NDIS51_MINIPORT<; /p>

// MPChar.CancelSendPacketsHandler = MPCancelSendPackets;

MPChar.PnPEventNotifyHandler = MPPnPEventNotify;

MPChar.AdapterShutdownHandler = MPShutdown;

#endif

NdisMRegisterMiniport(

NdisWrapperHandle,

&MPChar,

sizeof(NDIS_MINIPORT_CHARACTERISTICS));

Cuando se registra después, el sistema detectará el número de versión de NDIS y luego llamará a la interfaz de inicialización, MPChar.InitializeHandler = MPInitialize para inicializar otros contenidos del controlador.

Como inicialización de variables, lectura y escritura de registros, inicialización de semáforos de eventos/mutex, etc.

Si se completa la inicialización, el controlador puede funcionar normalmente. Generalmente, se utiliza la siguiente interfaz:

MPChar.SetInformationHandler = MPSetInformation;

MPChar.QueryInformationHandler = MPQueryInformation;

Se obtienen y configuran los atributos. A través de la siguiente interfaz:

MPChar.SendPacketsHandler = MiniportTxPackets;

MPChar.ReturnPacketHandler = MiniportReturnPacket;

Enviar y recibir datos.

Ahora puede ver que NDIS no es diferente de los controladores tradicionales, pero como interfaz de red, es más estable, más estandarizado y más fácil de desarrollar.

1. Implementación del protocolo 802.11

En 1996, ETSI propuso el protocolo LAN inalámbrico HiperLAN y HomeRFSWAP apareció en Japón en 1998. Bluetooth, que se ha vuelto popular en los últimos años (estrictamente hablando, Bluetooth no pertenece a la LAN inalámbrica, sino a la PAN inalámbrica (Personal Area Network-work)), debe contarse como un subconjunto de la LAN inalámbrica IEEE 802.11 aprobada en 1997. primera conexión inalámbrica El estándar Ethernet se ha convertido en sinónimo de LAN inalámbrica. La revisión de 1999 es la principal referencia del estándar actual.

802.11 incluye tres capas físicas diferentes: capa MAC (Media Access Control) y capa física:

–DSSS o Direct Sequence Spread Spectrum

–FHSS o Frecuencia Hopping Spread Spetrum

–Línea roja (IR o Infrarroja) para que la capa MAC pueda soportar 3 capas físicas diferentes al mismo tiempo

Conjunto de servicios básicos (conjunto de servicios básicos o BSS) El unidad LAN inalámbrica mínima, que consta de 2 o más estaciones móviles (estación inalámbrica o STA), que forman un conjunto de servicios básicos (BSS). Las estaciones móviles (STA) en un conjunto de servicios básicos (BSS) pueden comunicarse directamente entre sí; El conjunto de servicios básicos (BSS) es en realidad una red autoorganizada (ad hoc), llamada IBSS (BSS independiente) en 802.11. La conexión entre STA y BSS es dinámica y espontánea (no planificada previamente).

Extendida. conjunto de servicios (conjunto de servicios extendidos o ESS)

AP+BSS puede formar una LAN inalámbrica arbitrariamente grande, que se denomina red de conjunto de servicios extendidos, y todos sus componentes se denominan colectivamente conjunto de servicios extendidos (ESS)

BSS de Infraestructura: Los no IBSS se denominan BSS de Infraestructura 802.11 define 9 tipos de servicios:

Existen cuatro tipos de servicio de estación móvil (Servicio de Estación o SS):

1. Autenticación (Authentication)=¿quién eres?

2. Desautenticación = Estoy a punto de irme, deja de comunicarte conmigo por favor

3. ¿Se pueden escuchar los datos (Eavesdrop)

4.Entrega de MSDU (entrega de MSDU)

(¿Qué es MSDU? Unidad de datos de servicio MAC; SDU es una unidad de datos de protocolo PDU de (OSI ) capa superior, que define el protocolo para la solicitud de servicio de protocolo de capa inferior y la unidad de datos de protocolo PDU (Unidad de datos de protocolo) se refiere a la unidad de datos transmitida horizontalmente por la capa par)

Servicio del sistema de distribución ( Station Service o DSS)

Para proporcionar los 9 tipos de servicios: Los primeros 4 tipos: autenticación, desidentificación, cifrado y los últimos 5 tipos después del envío de MSDU:

5 Asociación: Es un DSS (servicio del sistema de distribución). Si STA quiere enviar el mensaje, las STA que transmiten a otros BSS deben primero asociarse con el AP del BSS donde se encuentran.

6. Disociación: el proceso inverso de asociación

7. Distribución: transmitir los datos (o mensajes) de STA1 de BSS1 a STA2 de BSS2 es la función de transmisión de datos entre DS.

8. Integración: Interoperabilidad completa con la red cableada

9. Reasociación: Cuando la STA cambia de Cuando BSS1 se mueve a BSS2, se debe volver a asociar con el BSS AP. admite transmisión de mensajes entre BSS

Dividido según la función: se puede dividir en tres tipos diferentes de tramas: gestión, control y datos

Todas las tramas MAC se componen de los siguientes tres partes: Encabezado de trama (encabezado MAC) Cuerpo de trama de longitud variable (Cuerpo de trama): secuencia de verificación de trama o FCS (frame check secuencia o FCS) relacionado con el tipo de trama: CRC-32

SSID es simplemente un 32 -identificador de bytes de IBSS o ESS Un byte corresponde a un carácter. Todos los caracteres inferiores a 32 se pueden utilizar para representar la red inalámbrica de una determinada empresa u otra organización, similar a la red cableada, por ejemplo. , nuestro grupo se llama Eda (los demás bytes son 0)

El servicio de autenticación se divide en dos tipos:

Sistema Abierto y ***Clave Compartida Secreta Compartida

Sistema abierto: si dot11AuthenticationType se establece en 1, es "autenticación de sistema abierto". Para establecer la autenticación, se necesitan 2 fotogramas para completar la tarea: solicitud de autenticación, respuesta de autenticación

***Clave compartida. : ***La autenticación de clave compartida requiere 4 fotogramas. Primero, el solicitante envía una trama de solicitud y luego el respondedor envía un texto de desafío, que es un número aleatorio de 128 bytes producido por WEP PRNG. Luego, el solicitante cifra el texto de desafío recibido con el algoritmo WEP y el respondedor descifra el texto devuelto. Obtenga el texto de desafío correspondiente. Si las claves utilizadas por ambas partes (respondedor y solicitante) son las mismas, el respondedor descifrará el texto devuelto para obtener el texto de desafío original y la autenticación será exitosa.

< El cifrado p>WEP se ha considerado un algoritmo inseguro. Por ello, WiFi ha propuesto algoritmos con mayores niveles de seguridad, como es el caso de WAP.

Funciones de la capa MAC:

1. Función de coordinación de puntos (PCF)

2. Función de coordinación de distribución (DCF)

3. Fragmentación

4. Desfragmentación

5. Reordenación y descarte de MSDU

Longitud de MSDU mayor que un umbral de fragmentación

MMPDU (Protocolo de administración MAC) Unidad de datos) debe estar segmentado.

Para mejorar la tasa de éxito de la transmisión, la longitud de los datos segmentados es un número par fijo

(sin incluir el último párrafo).

Los datos segmentados se pueden transmitir en ráfagas. El extremo receptor

se basa en los campos Sequence y MoreFragments para dessegmentar los datos. Método de control distribuido (DCF): varias STA compiten por el canal inalámbrico, el llamado método CSMA/CA (diferente del método CSMA/CA). CSMA/CD) Método de control de puntos (PCF): el AP sirve como centro de control y controla el uso de canales por parte de todas las STA. AP es el llamado coordinador de puntos y PCF se basa en DCF. Se utiliza principalmente para servicios en tiempo real y es opcional en 802.11.

Tiempo de espera aleatorio

BackoffTime = Random()×aSlotTime

Random()——Devuelve un número entero distribuido uniformemente entre [0, CW]

aSlotTime——La unidad más pequeña de CW determinada por las características de la capa física o la porción de CW

CW——ventana de contención.

Toma un valor entre [aCMin, aCMax]. El valor es aCMin cuando se envía por primera vez, se duplica cada vez que se retransmite y se mantiene aCMax después de alcanzar aCMax. Restablezca a aCMin después de una transmisión exitosa.

Si se detecta que el canal está ocupado, aplazar (aplazar)

Si se detecta inactivo y después de un IFS, entonces se realiza (Backoff)

. Después del tiempo de espera, si

el canal está inactivo, se enviarán tramas

Beacons