Hey Adrian,
Just saw your email, I took a quick look and I was able to find a struct
ieee80211_key_conf which contains the key material.
I suppose that the ath_node needs to be extracted from the ieee80211_sta ->
drv_priv by looking up the source mac address in the struct ieee80211_hdr
somewhere in ath9k_rx_accept()?
The ath_node could then give the ps_key which contains the key cache index.
This function also houses decrypt_errors which could be used for detection.
I suppose that ieee80211_find_sta_by_ifaddr( ) with the destination and source
mac as arguments would nicely fit the bill.
The struct ath_node could also contain the key material, which could then be
used for the replumbing.
Any particular pattern I must follow when writing the key material? Or will
ath_key_delete( ) followed by a ath_hw_set_keycache_entry( ) suffice?
Kind regards,
Michel Stam
--- Begin Message ---
Hi,
So, there's a keycache index in the RX packet telling you which
keycache entry it matched.
See if it's matching a keycache entry but then failing to decrypt; if
this is happening then an easy check would be "hit some threshold for
crypto failures" => "replumb that keycache slot."
This means ath9k would have to keep copies itself of all keycache
entries, which isn't a /bad/ thing..
-adrian
--- End Message ---
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
