tcpdump não exibe RSSI

Question

Estou monitorando as solicitações de sondagem do Wi-Fi via tcpdump no Debian e estou tentando capturar o RSSI (intensidade do sinal) de cada elemento de solicitação de sondagem. Atualmente, a saída do tcpdump para cada solicitação de teste é semelhante a:

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]

Está faltando intensidade de sinal e alguns outros elementos.

Usando outra máquina com a mesma versão do tcpdump / libpcap e os mesmos argumentos para o tcpdump, a saída inclui a força do sinal (mostrada abaixo)

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]

Alguém pode explicar por que o RSSI está ausente da carga de dados no primeiro dispositivo e existe alguma maneira de capturá-lo?

Por uma solicitação do @Spiff, aqui está um dump hexadecimal de uma das capturas de pacotes.

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

    

Answer 1

[Atualizado com todas as descobertas da nossa solução de problemas.
Obrigado ao extraordinário Guy Harris, do tcpdump / libpcap / Wireshark.]

tcpdump compreende apenas o tipo de link de dados do formato de cabeçalho de metadados de rádio "a_k.a LINKTYPE_IEEE802_11_RADIOTAP , a.k.a DLT_IEEE802_11_RADIO ) para o modo de monitor 802.11.

O IEEE802_11_RADIO DLT informa ao cartão / driver para preceder cada quadro recebido com um cabeçalho "falso" extra cheio de meta-dados de rádio. Isso é coisa que não foi transmitida como bits no ar, mas foi lida do estado do rádio no momento em que recebeu aquele quadro. Essas informações incluem o RSSI, o canal para o qual o rádio foi sintonizado, a taxa de dados / MCS do pacote e possivelmente muito mais.

Se o seu cartão & suporte ao driver Radiotap, você pode especificar que deseja capturar neste modo adicionando -y IEEE802_11_RADIO aos seus argumentos tcpdump . Você pode obter uma lista de tipos de links de dados com suporte para sua interface ra0 com tcpdump -i ra0 -IL ou possivelmente com tcpdump -i ra0 -D . Observe que os DLTs do modo de monitor podem não aparecer se você não incluir o -I para especificar o modo de monitor. Observe também que adicionar -I para colocar a interface no modo de monitor pode não funcionar em todos os sistemas, portanto, pode ser necessário usar o script airmon-ng no pacote de software de código aberto aircrack-ng para ativar o modo monitor.

Parece que o driver / chipset Ralink na máquina que não funciona não suporta cabeçalhos Radiotap. Aparentemente, ele suporta apenas o formato obsoleto de cabeçalho Prism e uma variante menos conhecida dos cabeçalhos Prism.

Você pode confirmar essa teoria verificando o DLT da interface na máquina em funcionamento (no modo monitor) usando os comandos acima e confirmando que é IEEE802_11_RADIO .

Se confirmado, isso significa que suas opções se resumem a coisas como:

• Atualize o driver da sua máquina que não funciona para que ele corresponda ao driver da sua máquina em funcionamento. Aparentemente, o motorista na máquina de trabalho suporta cabeçalhos Radiotap. Como você disse que as duas máquinas têm o mesmo adaptador USB Wi-Fi de modelo, esperamos que ambos os adaptadores tenham o mesmo chipset Wi-Fi, portanto o melhor driver funcionará.
• Use o Wireshark (ou a ferramenta de linha de comando incluída tshark ) para fazer as capturas de pacote do modo de monitoração na máquina com o problema. O Wireshark e o tshark devem saber como analisar os cabeçalhos variantes do Prism suportados pelo driver "ruim".
• Capture os cabeçalhos da camada de enlace com tcpdump e analise o RSSI do cabeçalho Prisma variante. Provavelmente será o Sintt32 little-endian no offset 0x44 (decimal 68). Seria mais confiável procurar a seqüência 4400 0400 0000 0400 e, em seguida, pegar os próximos 4 bytes e considerá-los um SInt32. Em seu exemplo de cabeçalho capturado, o valor de RSSI se parece com: b1ff ffff . Isso seria 0xffffffb1 , que é a representação de inteiro assinado de complemento de dois de 32 bits de -79, que é um RSSI válido para uma força de sinal ruim, mas ainda trabalhável.
• Use tcpdump para capturar um arquivo na máquina com problema, mas depois analise-o usando o Wireshark ou tshark em outra máquina.
• etc.