Estoy monitoreando las solicitudes de sonda Wi-Fi a través de tcpdump en Debian y estoy tratando de capturar el RSSI (intensidad de la señal) de cada elemento de solicitud de sonda. Actualmente, el resultado de tcpdump para cada solicitud de sondeo tiene este aspecto:
09:13:17.663057 BSSID:Broadcast DA:Broadcast SA:04:fe:31:67:32:a0 (oui Unknown) Probe Request () [1.0 2.0 5.5 11.0 Mbit]
Le falta intensidad de señal y algunos otros elementos.
Usando otra máquina con la misma versión de tcpdump/libpcap y los mismos argumentos para tcpdump, la salida incluye la intensidad de la señal (como se muestra a continuación)
09:14:51.673753 6.0 Mb/s 2412 MHz 11g -71dB signal antenna 1 BSSID:Broadcast DA:Broadcast SA:b2:b2:b2:b2:b2:b2 (oui Unknown) Probe Request (11n-AP) [1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 Mbit]
¿Alguien puede explicar por qué falta el RSSI en la carga útil de datos del primer dispositivo y hay alguna forma de capturarlo?
Según una solicitud de @Spiff, aquí hay un volcado hexadecimal de una de las capturas de paquetes.
12:44:40.226564 BSSID:Broadcast DA:Broadcast SA:00:1e:8f:93:3f:60 (oui Unknown) Probe Request (pagefarm) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
0x0000: 4400 0000 9000 0000 7261 3000 0000 0000 D.......ra0.....
0x0010: 0000 0000 0000 0000 4400 0100 0000 0400 ........D.......
0x0020: c79d 0300 4400 0200 0000 0000 0000 0000 ....D...........
0x0030: 4400 0300 0000 0400 0300 0000 4400 0400 D...........D...
0x0040: 0000 0400 b1ff ffff 0000 0000 0000 0000 ................
0x0050: 0000 0000 4400 0600 0000 0400 0000 0000 ....D...........
0x0060: 4400 0700 0000 0400 0000 0000 4400 0800 D...........D...
0x0070: 0000 0400 0200 0000 4400 0900 0000 0000 ........D.......
0x0080: 0000 0000 4400 0a00 0000 0400 3500 0000 ....D.......5...
0x0090: 4000 0000 ffff ffff ffff 001e 8f93 3f60 @.............?`
0x00a0: ffff ffff ffff 4022 0008 7061 6765 6661 ......@"..pagefa
0x00b0: 726d 0108 0204 0b16 0c12 1824 0301 0332 rm.........$...2
0x00c0: 0430 4860 6c .0H`l
Respuesta1
[Actualizado con todos los hallazgos de nuestra solución de problemas.
Gracias al extraordinario mantenedor de tcpdump/libpcap/Wireshark, Guy Harris.]
tcpdumpsolo comprende el tipo de enlace de datos con formato de encabezado de metadatos de radio "Radiotap" (también conocido como LINKTYPE_IEEE802_11_RADIOTAP, también conocido como ) para el modo de monitor 802.11.DLT_IEEE802_11_RADIO
El IEEE802_11_RADIODLT le dice a la tarjeta/controlador que anteponga a cada cuadro recibido un encabezado "falso" adicional lleno de metadatos de radio. Esto es material que no se transmitió como bits al aire, sino que se leyó desde el estado de la radio en el momento en que recibió esa trama. Esta información incluye el RSSI, el canal al que se sintonizó la radio, la velocidad de datos/MCS del paquete y posiblemente mucho más.
Si su tarjeta y controlador admiten Radiotap, puede especificar que desea capturar en este modo agregando -y IEEE802_11_RADIOa sus tcpdumpargumentos. Puede obtener una lista de los tipos de enlaces de datos admitidos para su ra0interfaz con tcpdump -i ra0 -ILo posiblemente con tcpdump -i ra0 -D. Tenga en cuenta que es posible que las DLT del modo monitor no aparezcan si no incluye -Ipara especificar el modo monitor. Tenga en cuenta también que agregar -Ipara poner la interfaz en modo monitor podría no funcionar en todos los sistemas, por lo que es posible que necesite usar el airmon-ngscript en el aircrack-ngpaquete de software de código abierto para activar el modo monitor.
Parece que el controlador/chipset Ralink de la máquina que no funciona no admite encabezados Radiotap. Aparentemente solo admite el formato de encabezado obsoleto de Prism y, además, una variante menos conocida de los encabezados de Prism.
Puede confirmar esta teoría verificando el DLT de la interfaz en la máquina en funcionamiento (cuando está en modo monitor) usando los comandos anteriores y confirmando que es IEEE802_11_RADIO.
Si se confirma, esto significa que sus opciones se reducen a cosas como:
- Actualice el controlador en su máquina que no funciona para que coincida con el controlador de su máquina en funcionamiento. Aparentemente, el controlador de la máquina en funcionamiento admite encabezados Radiotap. Dado que usted dice que ambas máquinas tienen el mismo modelo de adaptador USB Wi-Fi, es de esperar que ambos adaptadores realmente tengan el mismo chipset Wi-Fi en su interior, por lo que el mejor controlador funcionará.
- Utilice Wireshark (o la herramienta de línea de comandos incluida
tshark) para realizar sus capturas de paquetes en modo monitor en la máquina con el problema. Wireshark y tshark deberían saber cómo analizar las variantes de encabezados de Prism que admite el controlador "malo". - Capture los encabezados de la capa de enlace
tcpdumpy analice usted mismo el RSSI del encabezado variante de Prism. Lo más probable es que sea el SInt32 little-endian con desplazamiento 0x44 (68 decimal). Sería más confiable buscar la secuencia4400 0400 0000 0400y luego tomar los siguientes 4 bytes y considerarlos SInt32. En el encabezado capturado de su ejemplo, el valor RSSI se ve así:b1ff ffff. Eso sería0xffffffb1, que es la representación entera con signo en complemento a dos de 32 bits de -79, que es un RSSI válido para una intensidad de señal pobre pero aún viable. - Úselo
tcpdumppara capturar un archivo en la máquina con problemas, pero analícelos luego usando Wireshark otsharken otra máquina. - etc.