On Fri, Apr 30, 2021 at 12:36:57PM +0200, Mark Kettenis wrote: > Since booting into a kernel with this diff, I've started seeing the > following messages on my OpenBSD AP that uses athn(4): > > Apr 30 02:13:54 smetana /bsd: athn0: Michael MIC failure > Apr 30 02:14:40 smetana /bsd: athn0: Michael MIC failure > Apr 30 02:16:43 smetana /bsd: athn0: Michael MIC failure > Apr 30 02:16:43 smetana /bsd: athn0: HostAP will be disabled for 69 seconds > as a countermeasure against TKIP key cracking attempts > Apr 30 02:21:49 smetana /bsd: athn0: Michael MIC failure > Apr 30 02:21:49 smetana /bsd: athn0: HostAP will be disabled for 61 seconds > as a countermeasure against TKIP key cracking attempts > Apr 30 02:24:17 smetana /bsd: athn0: Michael MIC failure > Apr 30 02:24:17 smetana /bsd: athn0: HostAP will be disabled for 82 seconds > as a countermeasure against TKIP key cracking attempts > Apr 30 02:25:52 smetana /bsd: athn0: Michael MIC failure > > That is with: > > iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, > msix > iwm0: hw rev 0x320, fw ver 34.3125811985.0 > > This also could be related to the earlier diff, so I'm reverting back > to a snapshot kernel for now.
That's interesting. Does your athn configuration force WPA1? We are using WPA2 by default, and WPA2 is required for 11n mode. However, an access point may offer compatibility for both WPA2 and WPA1 (ifconfig athn0 wpaprotos wpa1,wpa2) and TKIP may optionally be used even with pure WPA2, as a group cipher (ifconfig athn0 wpagroupcipher tkip). Our default group cipher is CCMP which should not involve any TKIP MIC checks on the AP. Such checks occuring would be a bug in this case. On -current a /etc/hostname.athn0 file like the following should be sufficient to run an access point with sane defaults: nwid foo wpakey bar mediaopt hostap inet ... And if you would like to force a particular channel: nwid foo wpakey bar mediaopt hostap chan 36 inet ... If this is happening with TKIP enabled on purpose we'd have to look at why this condition is getting triggered. My best guess is that the AP doesn't handle legitimate retries correctly and interprets them as malicious replays. The Intel firmware may send a lot of frames redundantly if Tx aggregation is enabled, expecting the receiver to silently discard any frames that have already been recieved. In block-ack mode, the sender cannot be sure which frames in its Tx BA window have already been received correctly until the receiver sends with a block ack frame. So when the firmware has access to the medium it will try to send as many un-acked frames as possible.
