Hi hulley.
The main difference between wlandump-ng an hcxdumptool is libpcap.
wlandump-ng use libpcap and hcxdumptool use raw sockets. Using raw sockets is extreme hardware near.
We open three raw sockets: one for read, one for write and one for control (channel switch) and receive a filedescriptor for each socket. Now we can use a simple
write(fd_out, packet, packetsize) to send a packet,
read(fd_in, packet, packetsize) to receive a packet and
ioctl(fd_main, SIOCSIWFREQ, &pwrq) to control (in this case switch channel).
Right now this code supports this drivers in combination with a kernel >= 4.9:
USB ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
USB ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
USB ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
USB ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter
USB ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
USB ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
PCIe RTL8821AE 802.11ac PCIe Wireless Network Adapter
Furthermore hcxdumptool needs full access to the interface.
Maybe we can find a solution:
Which kernel do you use (uname -r)?
Which driver (usb devices: lsusb or lsusb -t or pci devices: lspci) is used?
How many packets are captured in test.cap
Do we have malformed packets inside?
The following devices don't work:
Bus 005 Device 006: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 005 Device 007: ID 7392:a812 Edimax AC600 (and every RTL88xxAU based device)
and some of the newer ALFAs (https://github.com/derv82/wifite/issues/112) and intel iwlagn.
Please try some other options:
hcxdumptool -i wlanX -s -T 100000 -t 15 -D -C 1,6,11 -o test.pcap
-s = we want status out
-T = we increase the maximum error value (and hope hcxdumptool will not stop after a few seconds, so we retrieve some more informations)
-C = we use a scan list (in this case only channels 1,6 and 11 - maybe the driver failed to set/get channel 14 and/or 5GHz channels - if no errors appeared you can use this scanlist -C 1,3,5,7,9,11,2,4,6,8,10,12)
instead of the build in scanlist:
1,36,3,40,5,44,7,48,9,52,11,56,13,60,2,64,4,100,6,104,8,108,10,112,12,116,14,120,1,124,3,128,5,132,7,136,9,140,11,149,13,153,2,157,4,161,6,165,1,11,8,6,10,12,
-D = we run deauthentications, too (stress test for the driver)
-t 60 = we stay a little bit longer on a channel (maybe driver doesn't like ioctl SIOCSIWFREQ to switch channel)
and let's see what happens....
BTW:
we use channelsteps of 2 channels because if we are in the near field of an AP or a client the neighbour channel is under attack, too)
The same difference is between wlancap2hcx (libpcap) and hcxpcaptool (no libpcap).
In addition, hcxpcaptool detects more WLAN/LAN protocols (mainly hash based authentications) than wlancap2hcx. To get benefit of this, use wlandump-ng/hcxpcaptool option -l to capture IP based traffic.
The main difference between wlandump-ng an hcxdumptool is libpcap.
wlandump-ng use libpcap and hcxdumptool use raw sockets. Using raw sockets is extreme hardware near.
We open three raw sockets: one for read, one for write and one for control (channel switch) and receive a filedescriptor for each socket. Now we can use a simple
write(fd_out, packet, packetsize) to send a packet,
read(fd_in, packet, packetsize) to receive a packet and
ioctl(fd_main, SIOCSIWFREQ, &pwrq) to control (in this case switch channel).
Right now this code supports this drivers in combination with a kernel >= 4.9:
USB ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
USB ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
USB ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
USB ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter
USB ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
USB ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
PCIe RTL8821AE 802.11ac PCIe Wireless Network Adapter
Furthermore hcxdumptool needs full access to the interface.
Maybe we can find a solution:
Which kernel do you use (uname -r)?
Which driver (usb devices: lsusb or lsusb -t or pci devices: lspci) is used?
How many packets are captured in test.cap
Do we have malformed packets inside?
The following devices don't work:
Bus 005 Device 006: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 005 Device 007: ID 7392:a812 Edimax AC600 (and every RTL88xxAU based device)
and some of the newer ALFAs (https://github.com/derv82/wifite/issues/112) and intel iwlagn.
Please try some other options:
hcxdumptool -i wlanX -s -T 100000 -t 15 -D -C 1,6,11 -o test.pcap
-s = we want status out
-T = we increase the maximum error value (and hope hcxdumptool will not stop after a few seconds, so we retrieve some more informations)
-C = we use a scan list (in this case only channels 1,6 and 11 - maybe the driver failed to set/get channel 14 and/or 5GHz channels - if no errors appeared you can use this scanlist -C 1,3,5,7,9,11,2,4,6,8,10,12)
instead of the build in scanlist:
1,36,3,40,5,44,7,48,9,52,11,56,13,60,2,64,4,100,6,104,8,108,10,112,12,116,14,120,1,124,3,128,5,132,7,136,9,140,11,149,13,153,2,157,4,161,6,165,1,11,8,6,10,12,
-D = we run deauthentications, too (stress test for the driver)
-t 60 = we stay a little bit longer on a channel (maybe driver doesn't like ioctl SIOCSIWFREQ to switch channel)
and let's see what happens....
BTW:
we use channelsteps of 2 channels because if we are in the near field of an AP or a client the neighbour channel is under attack, too)
The same difference is between wlancap2hcx (libpcap) and hcxpcaptool (no libpcap).
In addition, hcxpcaptool detects more WLAN/LAN protocols (mainly hash based authentications) than wlancap2hcx. To get benefit of this, use wlandump-ng/hcxpcaptool option -l to capture IP based traffic.