☰

tcpdump não exibindo RSSI

tag-icon • tag-icon linux wireless-networking wireshark tcpdump
tcpdump não exibindo RSSI

Estou monitorando solicitações de sondagem Wi-Fi via tcpdump no Debian e 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 investigação é semelhante a esta:

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]

Falta a intensidade do sinal e alguns outros elementos.

Usando outra máquina com a mesma versão do tcpdump/libpcap e os mesmos argumentos do tcpdump, a saída inclui a intensidade do sinal (mostrado 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á faltando na carga de dados no primeiro dispositivo e há alguma maneira de capturá-lo?

Por solicitação do @Spiff, aqui está um despejo 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

Responder1

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

tcpdumpentende apenas o tipo de link de dados de formato de cabeçalho de metadados de rádio "Radiotap" (também conhecido como LINKTYPE_IEEE802_11_RADIOTAP, também conhecido como ) para o modo de monitor 802.11.DLT_IEEE802_11_RADIO

O IEEE802_11_RADIODLT diz ao cartão/driver para anexar cada quadro recebido com um cabeçalho "falso" extra cheio de metadados de rádio. Isso é algo que não foi transmitido como bits no ar, mas sim lido do estado do rádio no momento em que recebeu o quadro. Essas informações incluem o RSSI, o canal em que o rádio foi sintonizado, a taxa de dados/MCS do pacote e possivelmente muito mais.

Se a sua placa e driver suportam Radiotap, você pode especificar que deseja capturar neste modo adicionando -y IEEE802_11_RADIOaos seus tcpdumpargumentos. Você pode obter uma lista de tipos de links de dados suportados para sua ra0interface com tcpdump -i ra0 -ILou possivelmente com tcpdump -i ra0 -D. Observe que os DLTs do modo monitor podem não aparecer se você não incluir o -Ipara especificar o modo monitor. Observe também que adicionar -Ipara colocar a interface no modo monitor pode não funcionar em todos os sistemas, portanto, pode ser necessário usar o airmon-ngscript no aircrack-ngpacote de software de código aberto 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 obsoleto formato de cabeçalho Prism e uma variante menos conhecida de cabeçalhos Prism.

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

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

  • Atualize o driver em sua máquina que não está funcionando para que ele corresponda ao driver em sua máquina em funcionamento. Aparentemente, o driver na máquina em funcionamento suporta cabeçalhos Radiotap. Como você diz que ambas as máquinas têm o mesmo modelo de adaptador USB Wi-Fi, espero que ambos os adaptadores realmente tenham o mesmo chipset Wi-Fi interno, para que o melhor driver funcione.
  • Use o Wireshark (ou a ferramenta de linha de comando incluída tshark) para fazer capturas de pacotes no modo monitor na máquina com o problema. Wireshark e tshark devem saber como analisar os cabeçalhos variantes do Prism que o driver "ruim" suporta.
  • Capture os cabeçalhos da camada de link tcpdumpe analise você mesmo o RSSI da variante do cabeçalho Prism. Provavelmente será o little-endian SInt32 no deslocamento 0x44 (decimal 68). Seria mais confiável procurar a sequência 4400 0400 0000 0400e então pegar os próximos 4 bytes e considerá-los um SInt32. No seu exemplo de cabeçalho capturado, o valor RSSI se parece com: b1ff ffff. Isso seria 0xffffffb1, que é a representação inteira com sinal de complemento de dois de 32 bits de -79, que é um RSSI válido para uma intensidade de sinal ruim, mas ainda funcional.
  • Use tcpdumppara capturar um arquivo na máquina com problema, mas analise-os posteriormente usando o Wireshark ou tsharkem outra máquina.
  • etc.

informação relacionada