Closed helloqiua closed 3 years ago
This is likely because the device you are testing has another vulnerability: it accepts replayed broadcast/multicast frames. This is a known vulnerability in some Wi-Fi dongles. Can you post which Wi-Fi dongle the client you are testing is using?
Duplicate of #24
The WiFi device, not a dongle, is a Digi NS 9215 from about 2009, with a custom firmware load that we know has issues with ARP's. I have run your scripts on other devices and there are no issues with the other devices. This one is a custom wifi board in a corporate product. I am digging into the wpa_supplicant logs by adding "-dd" to the wpa_supplicant start up on this Linux controller ARM 9 processor.
I test with my Pixel XL, it has this problem. Thank you very much.
To people that might still see this issue: first test whether the device accepts replayed broadcast traffic (using ./krack-test-client.py --replay-broadcast
).
I have merge all the official patch and still tips vulnerable, compared to others, it is because 5 unique arp response, why deal it vulnerable when response the arp request? I have decrypt the frame, broadcast frame use correct GTK, it should be decrypted and response, what purpose to judge it?