> Date: Fri, 30 Apr 2021 14:18:46 +0200
> From: Stefan Sperling <s...@stsp.name>
[ Dropping Florian from the CC ]
> 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?
It doesn't...
> 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.
This is my (redacted) /etc/hostname.athn0:
media autoselect mediaopt hostap
nwid openbsd chan 60 wpakey password
inet 192.168.32.1
and this is what ifconfig athn0 shows:
athn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 6c:71:d9:33:44:55
index 3 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect hostap (autoselect mode 11n hostap)
status: active
ieee80211: nwid humppa chan 60 bssid 6c:71:d9:33:44:55 -92dBm wpakey
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet 192.168.32.1 netmask 0xffffff00 broadcast 192.168.32.255
