On 10/22/16 13:30, bugzilla-nore...@freebsd.org wrote:
--- Comment #12 from Adrian Chadd <adr...@freebsd.org> ---
So the beacon miss / TSFOOR is the driver side. I can go take another look at
fixing that up.
The CCMP replay attack thing - that we need another NIC to sniff the air in
monitor mode and try to capture the invalid PN showing up in the air. If it's
coming over the air then sure, we can nail it down. If it's not coming over the
air, and instead it's corrupted by the AR9380 NIC, we're in trouble.
I need to go double / triple-check to see if we pass frames that fail
CRC/FCS/decrypt up to the stack for incorrect processing. I'm kinda worried
that we're processing invalid frames a little too far along the input /
Ummm... I am not familiar with this device, but I have run into similar
issues on other IO devices. Do you have a spare/replacement device you
can substitute in? It turned out that on one system one of the device
chip registers was magically 'losing' a bit. We did not discover the
cause of this problem until after much pain and effort and we replaced
the motherboard. After that experience, I always try a replacement
device first. Also, if is software related then the replacement will
continue to show the problem. If it is hardware then you will get NO
problems, or if Murphy's Law is active, DIFFERENT problems.
Good luck, Adrian, you have solved some REALLY weird problems before.
Patrick Powell Astart Technologies
papow...@astart.com 1530 Jamacha Rd, Suite X
Network and System San Diego, CA 92019
Consulting 858-874-6543 FAX 858-751-2435
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"