Debian에서 tcpdump를 통해 Wi-Fi 프로브 요청을 모니터링하고 있으며 각 프로브 요청 요소의 RSSI(신호 강도)를 캡처하려고 합니다. 현재 각 프로브 요청에 대한 tcpdump의 출력은 다음과 같습니다.
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]
신호 강도 및 기타 요소가 누락되었습니다.
동일한 버전의 tcpdump/libpcap 및 tcpdump에 대한 동일한 인수를 사용하는 다른 시스템을 사용하면 출력에 신호 강도가 포함됩니다(아래 참조).
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]
RSSI가 첫 번째 장치의 데이터 페이로드에서 누락된 이유와 이를 캡처할 수 있는 방법이 있는지 설명할 수 있는 사람이 있습니까?
@Spiff의 요청에 따라 다음은 패킷 캡처 중 하나의 16진수 덤프입니다.
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
답변1
[문제 해결을 통해 얻은 모든 결과로 업데이트되었습니다.
tcpdump/libpcap/Wireshark 관리자인 Guy Harris에게 감사드립니다.]
tcpdump"Radiotap"(일명)만 이해합니다.LINKTYPE_IEEE802_11_RADIOTAP , 일명 DLT_IEEE802_11_RADIO) 무선 메타데이터 헤더 형식 데이터 링크 유형만 이해합니다.
그만큼IEEE802_11_RADIO 는 카드/드라이버에게 수신된 각 프레임 앞에 무선 메타데이터로 가득 찬 추가 "가짜" 헤더를 추가하라고 지시합니다. 이것은 공중에서 비트로 전송되지 않고 대신 해당 프레임을 수신할 때 라디오의 상태에서 읽혀지는 것입니다. 이 정보에는 RSSI, 라디오가 튜닝된 채널, 패킷의 데이터 속도/MCS 등이 포함됩니다.
-y IEEE802_11_RADIO카드 및 드라이버가 Radiotap을 지원하는 경우 인수를 추가 하여 이 모드에서 캡처하도록 지정할 수 있습니다 tcpdump. 를 사용 하거나 를 사용하여 ra0인터페이스 에 지원되는 데이터 링크 유형 목록을 얻을 수 있습니다 . 모니터 모드를 지정하는 를 포함하지 않으면 모니터 모드 DLT가 나타나지 않을 수 있습니다 . 또한 인터페이스를 모니터 모드로 전환하기 위해 추가하면 모든 시스템에서 작동하지 않을 수 있으므로 다음을 사용해야 할 수도 있습니다.tcpdump -i ra0 -ILtcpdump -i ra0 -D-I-Iairmon-ngaircrack-ng 모니터 모드를 켜려면 오픈 소스 소프트웨어 패키지 의 스크립트를 사용해야 할 수도 있습니다.
작동하지 않는 시스템의 Ralink 드라이버/칩셋이 Radiotap 헤더를 지원하지 않는 것 같습니다. 그것은 분명히 더 이상 사용되지 않는 Prism 헤더 형식과 덜 알려진 Prism 헤더 변형만을 지원합니다.
위의 명령을 사용하여 작업 기계(모니터 모드에 있을 때)에서 인터페이스의 DLT를 확인하고 이것이 맞는지 확인함으로써 이 이론을 확인할 수 있습니다.IEEE802_11_RADIO .
확인되면 다음과 같은 옵션이 제공됩니다.
- 작동하지 않는 컴퓨터의 드라이버를 업데이트하여 작동하는 컴퓨터의 드라이버와 일치시키세요. 분명히 작업 중인 시스템의 드라이버는 Radiotap 헤더를 지원합니다. 두 컴퓨터 모두 동일한 모델의 USB Wi-Fi 어댑터를 가지고 있다고 말씀하셨기 때문에 두 어댑터 모두 내부에 실제로 동일한 Wi-Fi 칩셋이 있기를 바랍니다. 따라서 더 나은 드라이버가 작동할 것입니다.
- Wireshark(또는 포함된 명령줄 도구)를 사용하세요.
tshark)를 사용하여 문제가 있는 시스템에서 모니터 모드 패킷 캡처를 수행합니다. Wireshark와 tshark는 "나쁜" 드라이버가 지원하는 변형 Prism 헤더를 구문 분석하는 방법을 알아야 합니다. - 링크 레이어 헤더를 캡처하고
tcpdump변형 Prism 헤더의 RSSI를 직접 구문 분석합니다. 오프셋 0x44(십진수 68)에 있는 리틀 엔디안 SInt32일 가능성이 높습니다. 시퀀스를 찾은4400 0400 0000 0400다음 다음 4바이트를 가져와 이를 SInt32로 간주하는 것이 더 안정적입니다 . 캡처된 헤더 예에서 RSSI 값은 다음과 같습니다b1ff ffff.0xffffffb1이는 -79의 32비트 2의 보수 부호 있는 정수 표현인 이며, 이는 열악하지만 여전히 작동 가능한 신호 강도에 대한 유효한 RSSI입니다 . tcpdump문제가 있는 컴퓨터에서 파일을 캡처하는 데 사용 하지만 나중에 Wireshark나tshark다른 컴퓨터에서 분석합니다.- 등.