On Tue, Jul 07, 2020 at 11:31:08AM -0500, Tim Chase wrote:
> On 2020-07-07 08:50, Stefan Sperling wrote:
> > The diff has since been committed. Could you try a snapshot just
> > to see if that works?
>
> I pulled down the latest snap (#290 Jul 6 15:31:39 according to
> dmesg), rebooted into it and grabbed a shell, then issued
>
> # ifconfig athn0 debug nwid "$MYSSID" wpakey "$MYKEY" up
>
> and got largely the same output as before, eventually hitting
>
> athn: associated with {MAC} ssid "{MYSSID}" channel 3 start 1Mb short
> preamble short slot time
>
> and getting through all 4/4 of the 4-way handshake, and doing 1/2
> and 2/2 fo the group key handshake, stopping at the
>
> athn0: sending msg 2/2 of the group key handshake to {MAC}
>
> This is further than 6.7 was getting (6.6 got this far). However,
> the output stops there. An ifconfig says (hand transcribed)
>
> athn0: flags=8847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr {mymac}
> llprio 3
> groups: wlan
> media: IEEE802.11 autoselect (DS1 mode 11g)
> status: active
> ieee80211: nwid {myssid} chan 3 bssid {routermac} -43dBm wpakey wpaprotos
> wpa2 wpaakms psk wpaciphers ccmp wpacgroupcipher ccmp
>
> About hourly(?) since issuing those, my console has given me another
> pair of
>
> athn0: received msg 1/2 of the group key handshake from {router MAC}
> athn0: sending msg 2/2 of the group key handshake to {router MAC}
>
> if that matters, though it seems successful.
That is looking good. The AP is supposed to rotate the group key hourly.
Since you are able to receive group key updates it follows that the
pairwise WPA2 crypto for regular data traffic is now working, too.
Group key updates are encrypted with the pairwise key and sent to
each client individually. Back when your athn client didn't see group
key updates it implied that pairwise crypto wasn't working.
Are CCMP decryption error counters in netstat -W athn0 close to zero now?
If so, then I have successfully reproduced and fixed one bug. But some other
problem remains which we need to diagnose next.
Are you able to run tcpdump on the AP itself or on the network behind the AP?
Do you see DHCP requests from the athn client arriving there?