pass the encrypted frame to mac80211 for software
decryption; with this option, you could advertise MFP support even
with CCMP hwaccel enabled
--
Jouni MalinenPGP id EFC895FA
___
ath5k-devel mailin
CMAC can be done in software. Any work around on this?
Could you please describe what exactly you mean with "current secured
mesh requires the AES CMAC to be enabled" and what is that claim based
on? Any pointers to the specific standard clause(s) that say th
correctly decrypted frame
(i.e., using the pre-802.11w rules on CCMP exactly in the way the
hardware did it) and then pass that end result for masc80211 to decrypt
it correctly. I considered doing that for a while, but did not find
enough justification to work with that.
--
Joun
in the hardware key
cache) and then run a test that exchanges robust unicast management
frames (both TX and RX using the modified ath5k driver). I would also
verify that unicast data frames get processed in hardware and robust
management frames in software.
--
Jouni Malinen
ems in some cases,
but that may not be feasible with all the hardware revisions supported
by ath5k.
--
Jouni MalinenPGP id EFC895FA
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.
out the default keys from key cache if another vif is added.
When working with the key cache implementation for ath9k, the extra
effort did not seem to be justifiable for WEP and it is now couple of
years from that and surely there is even less justification now.
--
Jouni Malinen
nges in CCMP for management frames are more
recent than the hardware designs supported by ath5k..
--
Jouni MalinenPGP id EFC895FA
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/
On Wed, Mar 03, 2010 at 10:10:49AM +0900, Bruno Randolf wrote:
> On Tuesday 02 March 2010 18:42:38 Jouni Malinen wrote:
> > If we want to have an option to prevent hardware from touching the frame
> > payload, that really should be an option (a radiotap and TX control
> > flag
lags & IEEE80211_TX_CTL_INJECTED)
> + pkt_type = AR5K_PKT_TYPE_NORMAL;
This is the part I object to. IEEE80211_TX_CTL_INJECTED should not be
used for this.
--
Jouni MalinenPGP id EFC895FA
_
I did not like
the changes in ath9k and would not exactly like extending that to even
more different chips taken into account that none of this is needed for
normal use of the card.
--
Jouni MalinenPGP id EFC895FA
to
> enable it on both sides to make it work). There is no related code on
> ath5k for compression/decompression at the moment.
Even compression needs some negotiation support (i.e., mac80211/hostapd
are actually in scope) and there are some ugly corner cases showing up
issues with it.. I don't see much point in supporting this either.
--
Jouni MalinenPGP id EFC895FA
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
me as far as undocumented functionality is concerned. The
only clear case when padding is required is data frames with non-empty
frame body.
--
Jouni MalinenPGP id EFC895FA
___
ath5k-devel mailing list
12 matches
Mail list logo
