hcxtools - solution for capturing wlan traffic and conversion to hashcat formats

[ZerBea]

No, because Planar has an AR9271 chipset - as far as I know.
I have several WiFi adapters for testing purpose (different chipsets and of course, different drivers). Most of all I was impressed by mt76 chipset family and driver followed by rt2800usb chipset family and driver. Both are very sensitive and working "out of the box". This devices are cheap and the tx power is more than enough. Keep in mind: we are packet oriented and don't need high tx power devices. Instead of running high tx power, it is a good idea to use high gain directed antennas, because they gain in both directions (rx and tx). In other words:
It's almost always better to achieve gain with the antenna instead of increasing the transmitter power.
https://metis.fi/en/2017/10/txpower/
It is a fairytale that increasing tx power will lead to more results!
https://en.wikipedia.org/wiki/DBm
"A power level of 0 dBm corresponds to a power of 1 milliwatt. A 10 dB increase in level is equivalent to a 10-fold increase in power. A 3 dB increase in level is approximately equivalent to doubling the power, which means that a level of 3 dBm corresponds roughly to a power of 2 mW. Similarly, for each 3 dB decrease in level, the power is reduced by about one half, making −3 dBm correspond to a power of about 0.5 mW. "

A good antenna is the best hf amplifier:
https://www.arrl.org/files/file/Technolo...811054.pdf

Increasing tx power will make the signal crappy! A spectrum analyzer will show you this.

[WPA_Catcher]

Hi ZerBea

I am making a suggestion/feature request whilst thinking about your philosophy and that of Linux.

I suggest you remove all code from the new builds of hcxtools and hcxdumptool relating to creating hccap and hccapx files.

Then please consider taking the conversion code already written and create a separate converter tool "hcx2oldcap"!!!

hcx2oldcap would be able to convert the new text output from hcxpcapngtool into hccap and hccapx files.

The benefits of doing this are to keep your new code compact and simple whilst allowing those of us who cannot afford new hardware to continue using their current systems.

hcx2oldcap will "do one thing well", allow the user to input a text list provided by hcxpcapngtool and convert each line to a separate hccap or hccapx named by ESSID, AP_MAC or Client_MAC (specified by the user)  It does not do anything else.

I hope you like this suggestion and consider it.

[strike1953]

No, because Planar has an  AR9271 chipset - as far as I know.
I have several WiFi adapters for testing purpose (different chipsets and of course, different drivers).  Most of all I was impressed by mt76 chipset family and driver followed by rt2800usb chipset family and driver. Both are very sensitive and working "out of the box". This devices are cheap and the tx power is more than enough. Keep in mind: we are packet oriented and don't need high tx power devices. Instead of running high tx power, it is a good idea to use high gain directed antennas, because they gain in both directions (rx and tx). In other words:
It's almost always better to achieve gain with the antenna instead of increasing the transmitter power.
https://metis.fi/en/2017/10/txpower/
It is a fairytale that increasing tx power will lead to more results!
https://en.wikipedia.org/wiki/DBm
"A power level of 0 dBm corresponds to a power of 1 milliwatt. A 10 dB increase in level is equivalent to a 10-fold increase in power. A 3 dB increase in level is approximately equivalent to doubling the power, which means that a level of 3 dBm corresponds roughly to a power of 2 mW. Similarly, for each 3 dB decrease in level, the power is reduced by about one half, making −3 dBm correspond to a power of about 0.5 mW. "

A good antenna is the best hf amplifier:
https://www.arrl.org/files/file/Technolo...811054.pdf

Increasing tx power will make the signal crappy! A spectrum analyzer will show you this.

My experience with the Wifistation Planar Ubiquiti with Atheros 9271 chip has been the best antenna I've tried; The reach capacity is superior to any other I have used (Ralink, Realtek, among others). Doing a wardriving comparing the Wifistation with any other, has doubled the amount of hashes captured.

That is my experience.

[ZerBea]

Oh, I think that's a misunderstanding. I'm not talking about wardriving. I'm talking about "normal" laboratory conditions, running different WiFi adapters, router types, antennas and electronic measuring devices (R&S®FSV40) inside.
I'm coding penetration testing tools. Therefore, for me, it is mandatory to have a defined working environment.

[taxil]

@ZerBea what is the fastest channel switching speed you recommend for capturing PMKID with hcxdumptool? Looking for a fast capture method with moving 20+ MPH.

[strike1953]

Oh, I think that's a misunderstanding. I'm not talking about wardriving. I'm talking about "normal" laboratory conditions, running different WiFi adapters, router types, antennas and electronic measuring devices (R&S®FSV40) inside.
I'm coding penetration testing tools. Therefore, for me, it is mandatory to have a defined working environment.

Two totally different environments. My apologies. Mine (Wardriving) is a hobby.

[ZerBea]

@ZerBea what is the fastest channel switching speed you recommend for capturing PMKID with hcxdumptool? Looking for a fast capture method with moving 20+ MPH.

Take a look at the measured EAPOLTIMEs . This values give you some clues about the stay time.
In automatic mode, hcxdumptool check traffic on a channel every 250000 usec. If the channel is empty, it moves to the next entry from the scan list. Targets in the near field are attacked channel overlapped. In case of traffic on the channel, it stays up to the default stay time (5 seconds) on the busy channel.
If you want to override the automatic, 2 seconds should be ok. In that case hcxdumptool will move to the next channel after 2 seconds, regardless of the traffic on the current channel. Good if you expect much traffic on a channel. The check interval of 250000 usec remains untouched. That means hcxdumptool will leave an empty channel after 250000 usec.
Please keep in mind:
The stay time on a channel doesn't depend on your driving speed. It depend on the (expected/real) traffic volume on a channel.

[ZerBea]

@strike1953:
Looks like we can expect another fix for that (kernel) issue (ath9k_htc), soon:
[56147.938929] ath: phy0: Short RX data len, dropping (dlen: 2)
[56260.431703] ath: phy0: Short RX data len, dropping (dlen: 7)

Sometimes the hardware will push small packets that trigger a WARN_ON
in mac80211. Discard them early to avoid this issue.

This patch ports 2 patches from ath9k to ath9k_htc:
https://lkml.org/lkml/2020/1/7/1334

commit 3c0efb745a172bfe96459e20cbd37b0c945d5f8d "ath9k: discard undersized packets".
commit df5c4150501ee7e86383be88f6490d970adcf157 "ath9k: correctly handle short radar pulses".

[strike1953]

@strike1953:
Looks like we can expect another fix for that (kernel) issue (ath9k_htc), soon:
[56147.938929] ath: phy0: Short RX data len, dropping (dlen: 2)
[56260.431703] ath: phy0: Short RX data len, dropping (dlen: 7)

Sometimes the hardware will push small packets that trigger a WARN_ON
in mac80211. Discard them early to avoid this issue.

This patch ports 2 patches from ath9k to ath9k_htc:
https://lkml.org/lkml/2020/1/7/1334

commit 3c0efb745a172bfe96459e20cbd37b0c945d5f8d "ath9k: discard undersized packets".
commit df5c4150501ee7e86383be88f6490d970adcf157 "ath9k: correctly handle short radar pulses".

I'm glad, but escapes my rudimentary knowledge of Linux

[ZerBea]

Well, not easy to explain:
https://www.kernel.org/doc/html/v4.17/pr...tches.html
But in simple words, it works like this procedure:
First step is to report an issue (if it is related to the kernel and not not to your distribution) here:
https://bugzilla.kernel.org
Next step is to wait for a fix/patch and to test it.
Third step is to wait until the fix reach the mainline kernel.
Last step is to wait until the (fixed) mainline kernel reach your distribution.